 The future is here. It's just not evenly distributed. Look around the world and we know this to be true. You're all here in this room. Chances are the vast majority of you got in a regular gasoline powered vehicle and drove here to the venue today. However, we know that in the future, many of us will be driving electric vehicles, clean electric vehicles. Those electric vehicles may be using power that came from dirty coal. So how clean is that electric vehicle? Well, that's also becoming a solved problem. In California today, you could use a company like Solar City to go install solar panels on your roof that look like legitimate roofing. This isn't an eyesore. It's just your entire roof is a solar panel. Pretty amazing future that's already here. If you're in California today, completely off the grid. We know that today, if you go to the grocery store, the vast majority of us have this as our reality. We wait in line to check out. However, if you're lucky enough to be in Seattle near the very first Amazon Go store, there's no such thing as a line. There's no such thing as a checkout. You grab what you need and you walk out the door and sensors charge you accordingly. The future is already here. It's just not evenly distributed. And this principle, of course, applies to JavaScript as well. The future of JavaScript is here. It's not evenly distributed and I'm going to ask you a few questions during this session that's going to make that clear with your fellow audience members. So let's get started. What I'm going to talk about is the last decade in JavaScript and three revolutions that began in the last decade and all three of these are still in progress. Now you might think this is a real talk through history, but in fact what you're going to see is these three revolutions, many of you have not embraced them yet despite the fact that they've been around for a while. I find it pretty cool that today is exactly 10 years since Jeff Atwood coined Atwood's Law which says any application that can be written in JavaScript will be written in JavaScript. Now when Atwood said this, I thought it sounded pretty crazy. Despite being a guy that's really big into JavaScript, this sounded nuts. But today we live in a world where that really is a reality. Think about the web was the beginning of JavaScript. We all know that that's where it started. So yes, I can write web applications using JS. But today I can write server-side apps using Node.js. I can write native mobile apps using React Native, using native script, using PhoneGap. And I can even write desktop apps using things like Electron. It's crazy to me that my favorite editor today is VS Code and that is written in HTML, JavaScript and CSS because it uses Electron. My favorite way to communicate and share gifts with my coworkers is Slack. Again, written, there's some Slack fans here, there we go. Again, that is written in plain old JavaScript using Electron. Pretty amazing. So Atwood's Law has come to fruition. JavaScript I like to say, it's a lot like Visa. It's everywhere you want to be. But it's interesting. A lot of us are JavaScript developers not because we believe that JavaScript is the best language in the world. We are in JavaScript because of where it is, not what it is. And JavaScript continues to get better and I love seeing the fact that now every year, right around June, we get a new release of JavaScript with goodness. But I'm certainly a JavaScript developer because I can write for any platform and that's pretty amazing. So it's a really awesome future that we have ahead with our skill sets. So anybody know what happened, January 12th, 2010? This was the beginning of a key phase of the JavaScript revolution. The reusable JavaScript revolution. Any guesses? JQuery. Nope, JQuery was not then. It was actually earlier. No? It was drum roll, drum roll, drum roll, NPM. NPM was announced on 2010. That was the first release of NPM. Pretty big deal. Now at the time, it didn't even make that big of a splash because we already had things like Bower that a lot of people were using. It was unclear whether who and when people would be using NPM. But today NPM has swallowed the world as JavaScript's de facto package manager. And this is a key piece of the reusable JavaScript revolution. If you haven't embraced NPM yet, then you're missing out on a lot of power. Now the thing is, if you rewind just two years, this was life as a developer. This was how I was spending my time. If I, yeah, I read some of the script tags as part of the fun. But think about the pain that we went through in 2008. Just 2008, it wasn't that long ago. I was dealing with all of this pain. Look at what would happen. Oh, I wanna go use someone else's work in JavaScript. Well, what steps would I go through? Well, I'd do something like this. I would search the web. I'd read the docs and go install the relevant install steps. I'd download any relevant JavaScript and CSS. I'd set up my script tags, my style references, and then I'd write some JavaScript that targets that HTML. Then I'd realize it wouldn't work. Man, I'd wonder why. Didn't get a lot of help at that part. Then I'd realize that the DOM query that I wrote was wrong. That was a common mistake that I'd make in this era. And it still wouldn't work. I'd fix it, still wouldn't work. I'd realize that the script order was wrong. So I'd reorder them a script tag because this needs to load before this, which loads before this. So I'd fix that and it still wouldn't work. Then I'd read the docs some more and realize, oh, okay, I'm running the wrong version of jQuery. I found that buried down in here. I need to run at least this version. So I'd go ahead and update that. And I would repeat all of these steps to go update jQuery. There was no easy way for me to upgrade my dependencies. Once this finally worked, I would typically drink heavily. And that was my 14-step process for working with JavaScript in 2008. Now, if you wanna stay updated, imagine this. I just went through all that work to get this going. If I want to stay updated, what would I do in that case? I would repeat a lot of those steps again. Very, very painful. And what if I wanted to minify or bundle or test this code? Nope, not gonna happen. Not practical, in that era, hardly any of us were because it was just too hard. Contrast that with today. NPM install lib, import the library, NPM update. That's pretty cool. That is vastly, vastly simpler. That is worth celebrating. JavaScript doesn't have a base class library. And because of that, we're seeing NPM grow at an amazing rate. NPM effectively has filled in this gap. And NPM's growth has been unprecedented. Unprecedented, you look at these lines here. You wanna guess which one is NPM? Come on, y'all. You're supposed to be the one on the top. It's kind of baiting you there. Look at this. So this number down here, this green line down here, that is .NETs package manager, which is NuGet. They add 66 packages per day. How about Java's, 139 per day? NPM, almost 500 packages are added every single day to NPM. By the end of the day, another 500 things are out there. I mean, that is amazing. That's amazing unless you factor in Sturgeon's Law. It's always a caveat with growth. I don't wanna pick on anybody, but now I will say, I think Sturgeon was a bit of a pessimist because my take is even if Sturgeon's Law is true, this is also true. I mean, more is better. 10% of that crap is good. So that's a win. Yes, I know I'm a child, but this is my justification. Now, I really think this is a glass half full mentality when you have that sort of view. It's a bit of a first world problem kind of complaint. Oh no, I can't keep up with all this awesome free stuff that people keep building for me. I mean, life as a JavaScript developer, when we talk about JavaScript fatigue, we sound a little, it's hard to have a lot of sympathy for us. It's a bit like going to a family reunion and complaining about how your inbox is full of recruiter emails. Oh, another recruiter wanting me to interview. It's hard being a developer. Your family will, do not say this at a family reunion. You'll think you're crazy. So we're in a great place as JavaScript developers and my point is this, that NPM allows us to write our code once and then reuse it. That's a very simple idea. So a question for the audience. We're gonna go through this cadence through this talk. Question for you. How many of you are using NPM packages today? So that is probably 70% of the room. Very good, but I have a more interesting question. I was expecting the majority of you to say that you do. How about this? How many of you will say my team has published in NPM packages? My team or my company? That's about 10, 15% of the room, although a noisy one. Woo, yes. We're excited about this. So look at this. Everybody put your hands back up if you have published an NPM package. Then Zach, your party in back, that's cool. So look around the room guys. The future is here. It's just not evenly distributed. I believe that if I came back here in a couple years we would see the vast majority of hands up. So ask yourself, do I wanna join the revolution? Because it is here. Now what I wanna share is a demo that shows how my team works with NPM packages. My team maintains an NPM package called Fusion. Fusion's a framework that we use for doing react development at Cox Automotive. It adds many opinions in on exactly how we want to do react development. So if I click over here I can go to our GitHub repository and you can see that this NPM package of course has a package.json and what makes this package interesting is all the dependencies that it holds inside. Our applications have a single dependency which is Fusion but behind the scenes starting here at line 27 and scrolling down these are all the dependencies that we're actually using to put our applications to work. So developers don't have to make decisions on Webpack or Babel or what react dependencies they should be pulling in. They just leverage all of these packages which are built in to Fusion. We also include some build scripts that start the application, that configure our tests and that perform the production build. We've also added some interesting extensions. Now behind the scenes we're actually using create react app but we've added a number of opinions on top to get this done. But through the power of this single NPM package when we deploy applications this is the dependency that our applications take on and in that way when we change directions when we need to do bug fixes or enhancements to our build process or deployments upgrade dependencies people have a single NPM package that they can update as necessary. So that is the key point at the end. We have at this point published at least a half dozen applications using a single NPM package that we call Fusion. So those applications you go into the package.json you know what you find there? One dependency because we've decided as a company that will bundle up all of our dependencies. Behind the scenes about 75 NPM packages a number of build scripts all of that is contained through the power of NPM. So I'd encourage you to consider that pattern. So that was the first revolution which is the package revolution. This is the very foundation of the reusable JavaScript revolution that I'm talking about today. So you need to have accepted that before you move on to phase two. Phase two of the reusable JavaScript revolution I call starter kits or I also like to call this part do. So if you were coding back in the day jQuery versus Moo Tools versus prototype JS which I did there was a funny site called vanilla JS and you would go out to vanilla JS and build your own custom download you could select things like Ajax event system functions as first class objects ooh regular expressions I want those and an array library that sounds handy and then I could build a custom download of all these features in this vanilla JS library and when I opened it in my editor what I would see is an empty file. You get the punch line vanilla JS is using the platform and if you went through the vanilla JS website what they would do is contrast the performance of plain vanilla JS versus using jQuery or Moo Tools and they would point out vanilla JS was not surprisingly faster because it removed a layer of abstraction and this was funny at the time and caught some level of attention however I believe that vanilla JS is malpractice and I believe that because today as developers if we're not leveraging each other's work we are wasting time we are reinventing the wheel we should be standing on the shoulders of giants and so many of us in here have done good work see today here's the story so many of us are expecting to publish an application to the web with a single minified bundle maybe tree shaken maybe that bundle is split in ways so that it loads from page to page that's not trivial you want things like explicit dependencies you want it to be modular, minified, transpiled linted, tested you want an automated build and you want automated updates I believe that File New Project is malpractice and in my organization we do not do File New Project when we start from scratch we are starting from a foundation with literally over 75 different opinions baked into it it is a huge number of opinions that we have think about some of the decisions that you make if you're going to File New Project right now as a JavaScript developer you as a team need to decide what editor are we going to use and how will we standardize that configuration of tabs versus spaces line endings and the such what NPM package or I should say what package manager are we going to use because NPM isn't the only one but it's a pretty logical choice what development web server will we use what automation approach what transpiler what bundler what linter how about automated testing we need to choose a framework an assertion library, helper libraries where to run our tests when to run them and where to place these files we need to choose a CI server if we're making HTTP calls Ajax that sort of thing we need to choose an HTTP call approach in fact if I lay all this out on a slide it's very difficult to fit it all and here's what's interesting you're going to watch all these decisions fly by you here but ask yourself this if you did a File New Project would you remember to ask yourself these questions would you remember all of these concerns because as a group in here we know that testing is important we know that minification and bundling and transpiling are all important as JavaScript developers but it's really easy for a lot of these decisions to hit the floor it's easy to accidentally end up in production in a bad state if you don't automate it away so again I say vanilla JavaScript today is malpractice File New Project is malpractice start from something more opinionated and so what I'm driven by is a level of dissatisfaction with the current state of affairs in JavaScript I can't get no satisfaction so here's what I'm dissatisfied with rework I don't want to start from scratch when I'm starting a new project I don't want a tedious setup just so I can get to a hello world wiring up transpiling and bundling and minification all of these things is really tricky and I end up repeating mistakes how about this you read a blog post and this blog post goes oh man this is something I have to remember to do on my next project but how do you remember to do that later the way that you do that is to codify your opinions the solution that I am suggesting here is to codify your opinions now one way that you can codify your opinions is through a checklist if you've ever read the book Checklist Manifesto I highly recommend this to developers it's not a technical book but what it drives home is the benefits of writing down what you need to do see the checklist manifesto tells an interesting story about doctors we as developers we don't like checklist because we feel like I'm a professional I don't need a checklist I know what to do off the top of my head but doctors have been found to need a checklist there was a study that found this you go in you have the nurses ask the doctors the steps that they need to perform before they cut a hole in your body and run a tube into it they're going to run a line into you they have to make sure that they sit down they wash their hands properly that they make the incision properly that they cover their hands and gloves it's not very many steps but as a doctor in the heat of the moment it's really easy to forget a step and what they found was a percentage of the time that happened and what happens in that case is people die people die when you miss a step now thankfully lives generally aren't in our hands but increasingly that is happening in software too they saw dramatic results by creating checklists what they saw was the 10 day line infection rate fell from 11% to zero because how could you miss it if you do the proper steps people don't get infections because you have protected yourself from it the checklist prevented 43 infections 8 deaths and $2 million in costs so in summary doctors know what to do but it's easy to overlook a step and in the same way we as developers also know what to do but I showed you that slide deck there were probably everything on that slide deck you thought yeah I'm generally familiar with that but do you ask yourself those 40 questions every time you start a new JavaScript project have you asked yourself that about your existing project today probably not so on my team we have honored this checklist idea we've created a file called pull request template.md here's a little pro tip if you use github create a file with this name and every time somebody creates a pull request it will generate this within the pull request so that way all of our pull requests have our code review checklist right there inside of it automatically that's us embracing the checklist manifesto so that we make sure we don't skip a step however, you're a developer so an even better idea than this is to automate it strive to automate and I think this is a really important principle that the more things that you can take for granted the better off you are society advances as we can take things for granted the fact that we came here today and we can take for granted that these lights would be on that my computer would be charged up that I could get in a car and drive here that's really important in the same way as developers we need to increase the list of things that we can take for granted see on my team there's a long list of things that we just don't think about anymore my team knows that they can use the latest version of JavaScript they know that it will just magically get transpiled they don't have to think about it in any way they know that every time that they hit save the test will run automatically and when we push code it will end up running on the CI server and we'll know if any tests have failed we know in our code reviews that our code reviews go really fast now because most of the things that we look for are caught by linters instead of manually on a case-by-case basis we know that when we get to production we'll be able to use source maps to debug our code even though we're transpiling we'll be able to see our original code in production we can start our application with one command when somebody joins my team you clone the repository you say npm start and magic happens and you're seeing your code there's no special work there we know that we can run a build that's minified, bundled, ready for production by just saying npm run build and we know that to get to production you say npm run deploy all of this is taken for granted and when you can take all of this stuff for granted it's awesome because then you can focus on the hard problems and programming see this basics this plumbing that we're talking about here should not be burning your cycles it should be a solved problem for your team and I assert this that the more that we can take for granted the faster we will move and the higher the quality will be on our projects so I think of a starter kit as a living, automated and interactive checklist it increases the number of things that you can take for granted now, a lot of you may feel like well, I kind of have a starter kit I went out and I used Create React app from Facebook or I used the Angular CLI or I used Ember CLI, whatever it may be well, I believe that that's not enough my recommendation to you go find a project like that fork it, make it your own and then add your opinions in because I guarantee you your team has a number of other opinions on top of those tools and that's precisely what my team has done we use Create React app behind the scenes but we have added many, many more opinions on top of it now, this is a really big conversation I published a five-hour course on Pluralsight called Building a JavaScript Development Environment where I talk through all of those 40 decisions and how you reason about those but my recommendation to you is really simple when you get back to your office on Monday I would suggest this to you just schedule a meeting schedule a meeting with your team and say I want to have an adult conversation about the issues let's just sit together and talk this through and we'll come to an agreement on how we do JavaScript here at our company and I think it'll go well now often these conversations can get heated because TypeScript versus Babel is a big, big deal people feel very, very strongly we've been through this as well but I don't believe this I believe if you're having those kinds of tabs versus spaces conversations on every JavaScript project you're spending a lot of time in the wrong place as a team come together and agree and then you can move forward so I want to share another demo I want to show you our starter kit that we use at Cox Automotive this is my team starter kit which we call Fusion the way that it works is you clone the repository just like you would any other GitHub repo I already have it cloned over here after you have cloned it you run npm run setup and setup helps you first install all the packages automatically and after those packages are installed then it will prompt you for the settings it will ask you if you want to delete the Git repository I'm just going to leave it as is here and then it will prompt you for your project name as you can see it enforces a logical name for a package.json it'll ask you for whatever version you'd like to assign for the author of the project it will ask you for your production URL I'll just put myurl.com ask you for your license the project description just a demo and now that we're done our setup is complete if I come over to package.json then I can see that it added this information into the repository and we have a few scripts in here to get started the other thing that's interesting is that our starter kit has a single npm package dependency so we can make changes over time and all any deployed applications need to do is pull a new version of Fusion and they get all those bug fixes or new enhancements in the future now when you run our starter kit what you will see what you see is it starts up a demo application that says welcome to Fusion gives you links to important information like our list of reusable components, our style guide and some basic steps that you can run once you're done looking at this demo you can run this script to remove the demo but we also show people how to work with the Redux app so you can go behind the scenes and see how this simple demo application works that just calculates miles per gallon we show how our form validation story works in an interactive way and again you can see that many of our opinions on forms are all encapsulated within our reusable components we show how our mock API works so you can actually come into here and save your changes and when you save those changes you'll see that they're reflected even when you reload the page we show out a dynamically import libraries and we also show how to lazy load heavy react components you can see that this loaded after the fact now once I'm done and comfortable with this demo I can go ahead and remove it and get started coding to do that I come over here and say NPM run remove demo and when I do we can see that there's a lot fewer files over here now and if I rerun the application now it's simply a hello world so we have a simple starting point that is ready to run the app that's how we do development on my team the nice thing is everybody knows that they start with fusion starters what we've called it one thing I will recommend is choose a brand name for whatever you do I was recently out in San Jose consulting a team that went for the same model and they chose their own special name they called there's pre-amp because they have a model where they're tied to videos and they like that idea of a pre-amp it went well with their branding had their own logo and everything unfortunately what I just showed you isn't open source so you can't go out there and dig through it for more but a very very similar project that I published about a year and a half ago was react slingshot so if you want to dig through the code and see how all this works check out react slingshot just yesterday it hit seven thousand stars so I was pretty excited about that it's gotten a lot of usage so I'm excited about this this is an opinionated way to work with react that said I'm a big fan of create react app too it's it's an awesome solution so question how many of you will say that my team or company has its own JavaScript starter kit wow so that is four percent not five four I'm that exact with my counting so that is a very very small number so again look around the room the future is here it's just not evenly distributed I believe that this is the future because starting with file new project is just too much work and your team has a large set of opinions there over forty decisions that you need to make when you file new project on JavaScript today and a starter kit operates as an automated checklist for your team so that you can codify your opinions and automate all the fatigue that people talk about away my team is not fatigued anymore we know when we start a project that's what it looks like and it just works we don't have conversations about the basics anymore all right so we have talked about two of the three reusable solutions packages and starter kits and going to close out this talk with the final revolution which is reusable components all of these build upon one another now for those that aren't familiar with reusable components it's a reusable piece of html javascript and css and we know that these are the big reasons that we want consistency less code faster development fewer bugs the component model gives us these obvious benefits at face book they are heavily invested in the component model using react and they find that components help hundreds of engineers work on the same code base move between teams quickly ramp up and focus on products now this has happened all over the world i'm an i'm a car guy i work for an automotive software company in fact back in kansas city and you look at this mercedes is a beautiful car and you think okay these are a bunch of special parts inside but in actuality there's all sorts of reusable pieces reusable components inside here the seat belt the button on the seat belt the airbag systems the transmissions the but the engines themselves in many cases are used across vehicles really large complicated components and this cuts their costs speeds development increases economies of scale as developers we have all this same power now we should be working with higher and higher level abstractions with better components as time goes on that's precisely what's happening on my team now we've created our basic components now we're starting to build on top of those basic building blocks i will tell you this i believe that the future of development is going to be assembling finished components taking those components putting them together in novel ways will be thinking of ourselves more like working with lego pieces rather than having to build the legos ourselves leverage higher pieces higher levels of abstraction now i wish i could claim this slide but i love how this slide encapsulates the mindset shift that you need to make today is a javascript developer for the longest time we've talked about separation of concerns as a separation of javascript html and css i don't believe that's a valid way to think about separation of concerns anymore because separation of concerns today is a matter of components so i want to separate my concern of this button from my concern of a date picker from my concern of this modal dialogue the component is the concern we're separating it's a powerful idea because you recognize that html and javascript were never separated concerns we thought they were back in the jQuery days i would write unobtrusive javascript here's my html here's my javascript the problem was if i ever changed my html i broke my application if i didn't also update my javascript because my javascript was hard coded expecting a certain dom to be there this is the important future for javascript developers is thinking about concerns in terms of reusable components and those components may be composed of multiple technologies but separating technologies doesn't necessarily separate concerns html and javascript are fundamentally intertwined there's an interesting question someone might ask you though if i asked you hey can you share this html with me that's a surprisingly hard question to answer i don't know quite how i'd respond to it i love i will tell you this is the hardest thing about writing talks is getting distracted by stock photography and all the silliness that you see you guys couldn't turn the monitor on before he pointed at it but this is a hard question can you share this html with me and the really the answer is we don't share raw html what we share instead is javascript that embeds html so if i want to share this div with you the way that i'm going to get it done is with javascript and this has been the case throughout history over the years we've seen a lot of ways to get this done this brings us to the third and final revolution which actually occurred earlier but i'm introducing it last for specific reason that i'll explain in a moment now what happened on this date in two thousand six no guesses web components nope that was later gmail web app that's an interesting guess no although that's that's close that was that was in the ballpark jQuery there we go yes jQuery was launched in two thousand six this is a very big deal this this is what kept me from rage quitting web development i was just about done with it because cross browser was so painful and jQuery wasn't really about components jQuery was about paving over inconsistencies in the DOM and giving you a really elegant API very shortly after jQuery came about we saw this jQuery plugins and jQuery plugins were really the first popular way to build reusable components for the web however today you're likely not going to reach for jQuery plugins to get this done today we're all asking ourselves how should i build components now i obviously have an opinion on this matter in fact i'm going to go ahead and share it but i want caveat why i believe the strong opinions are useful for others those who are undecided or ambivalent can just adopt your stance but those who disagree can solidify their stance by arguing against yours so i would totally encourage you tonight we're gonna have an after party i'd love for you to come up and say how i'm a dummy head and you feel like this other thing is better that's absolutely fine i'll share my opinion on the story right now because there is no really clear answer web components the web components standard is a compelling option to consider here now i'm a big fan of standardization if you're not familiar with web components this idea of four core technologies inert templates put some markup in there and it just works custom elements where you can define your own html elements shadow DOM which encapsulates your styles so they don't leak out and imports being able to bundle html javascript and css now i'm a big fan of standards and i even created a course on html five web components on plural site because i was really amped about the standard now the sad news is i can't stand up here and push you might think that that's what i'm going to tell you right now is go ahead go use web components but the story really isn't that simple there's a few reasons that i'm not reaching for web components and many of you how many of you are using native web components one hand one hand out of i don't know how many that's that's definitely a less than one percent here's why spotty browser support so you have to pull in polyfills in those polyfills way a substantial amount uh... yesterday i just learned uh... i believe it was twenty seven k minified for the polyfills that you need for i-e eleven for instance uh... to be able to run the standard and that's because of browser support see the template tag is pretty well supported cross browser except for i-e you'll need a polyfill there but the other three core technologies not so html imports lot of red custom elements shadow dawn and we've been waiting i've literally been waiting for years for browsers to implement these standards and we're still waiting so the question is when there are two other issues here this at the time i was really excited about web components because it enabled some new things the idea of the shadow dawn was really novel that i could write simple css selectors and not worry about leaking onto other components today javascript libraries they keep on innovating so in fact i compare to react for instance react has answers to all these things jsx for templates react components are effectively your custom element you can use css modules or css in js to keep your styles tied to that one component and we're all using bundlers and npm anyway so we don't really need html import specification so my take on it is this don't wait around for the web standard to catch on instead just embrace modern javascript the real question is which framework so these are the four most popular although there are many more options out there that i'm not going to try to fit on a slide here's what i think you should be asking yourself though four things how stable is it how broadly is it adopted how much boilerplate am i putting in here that's specific to this library that's gonna make it hard to shift to something else later and how much does it weigh so i'm a big fan of react i'll be completely honest about that let's see how it scores here when react you do code mods when there's a code change a major release i just run a code mod that automates it for me and that's because face book has to do that they are dog-fooding in a way that no one else can compare to face book dot com one of the biggest sites in the world uses thirty thousand react components so face book can afford to make a big breaking change that requires manual changes that have to update thirty thousand components fundamentally react is a function that returns html is very low boilerplate and finally it's quite lightweight forty three k now i may change my mind tomorrow and if you go see me talking at conferences and videos from previous years you'll find i've had different stickers on my laptop from year to year this is how my trajectory has been through history i was using angular not that long ago but now i'm enjoying react at the moment next year i may be somewhere else so you do have to ask yourself this what if i choose x and everybody moves to why whether regardless of where you are chances are there's going to be some other new hotness coming soon my take on it is this if you choose a low boilerplate a low boilerplate library then you can get started safely today migration really is practical see for instance here's react there's really very little boilerplate i've got an import at the top i have a function with a name that takes parameters and it returns html if you told my team hey cori your team needs to go rewrite everything in view we totally do that that's not a big deal it's mostly a syntactic change i don't burn the world to the ground because really this is what's hard component design is hard coding isn't that big of a deal i'm convinced that my team it would be relatively straightforward for us to move to a new technology later when react is no longer the new hotness whatever that may be and it may very well be us moving to standardized web components once all of the browsers have really embraced the standard but i don't believe that you should sit around and wait because centralized and consistent is most certainly preferable to decentralized and inconsistent now that's not always true but in the aggregate repeating yourself through copy and paste is not a design pattern that scales very well now choosing a framework is just one of many decisions that you have to consider here i showed you something like this when you were thinking about building a starter kit there is a similarly ridiculously long list here and i'm just going to jump ahead so you don't have to watch it all go fifty decisions fifty decisions that you need to consider when you're going to create a reusable component library so that is huge again i went through the same thing i just published a course if you happen to be interested in react called creating reusable react components this is a six-hour course i thought that i could get it done in two but it is a complicated conversation because there are this many decisions to consider fifty different ones so i want to show you quickly how we do reusable components at cox automotive this is our documentation for fusion ui components along the left-hand side we have the alphabetized list of components i'm looking at the text input component right now which is an abstraction over a label a text input an error message and add some opinions around that uh... down here we have a list of examples for each of these examples you can click on the examples header and see a snippet of code that you could copy and paste into an application down at the bottom we also have a list of props which you can change to oh i apologize i i hit the uh... trackpad so i will narrate this anyway just to save us some time the thing i want to emphasize is one of the harder parts is setting up your documentation setting it up in a way that is uh... leveraging all your code and what we have is all the documentation that i'm showing you here is generated from the code we have these comments to the comments over there on the left is kind of a js doc style comment that's what generates our documentation so every time we hit save in the code we see our documentation change in that way we don't have to worry about the two getting out of sync i show how to get this done in uh... the plural set course on react components really the patterns that i follow would apply just as well as an angular developer view developer don't build your docs by hand automate that process final question how many of you have your own reusable component library more hands than i expected this is great that's probably fifteen percent of the room that's pretty cool excellent how many of you are working in angular for that reusable component library okay how many in react okay how many in view wow a lot so view and react are neck and neck here that's very different thing can well i'll find out kansas city next month kcdc we'll see how much that is shifted i know views getting a lot of attention okay so very very interesting so we just saw that again everybody with their hands raised that's an interesting take as we've gone through this progression fewer and fewer people are through these three revolutions because one revolution builds on another so let's go ahead and wrap up i want to clarify why i laid all of this talk out in order that i did when you're gonna build a house with components you're gonna go out and get a chimney component a door a window these sorts of things you know you wanna you don't want to start from scratch and build your own window your own door and this should be the story now today with your uh... development story on your team but to be able to do this you need a foundation a house can't float in the air the foundation that i'm suggesting for you is a starter kit that starter kit encapsulates all the dependencies that your team needs and of course that starter kit gets hosted on npm that's precisely why i laid out the reusable revolution in the order that i did so if you're one of those people that likes to take pictures of slides at conferences here's your big chance just make sure your camera's not pointed at your face first was the npm packages so the reusable revolution of packages my call to you is create your first package we just saw about uh... thirty percent of the room has not created an npm package before so that's a big first step in fact no i take that back it was more like sixty percent of the room but not starter kits my call to you is codify your decision set up a meeting on monday to say let's come to an agreement as a team here's how we do lending here's how we do bundling here's how we do transpiling et cetera automate the pain away and finally with comes to reusable components go pick a library and start sharing set up a centralized site and start documenting your work so if you're gonna take a picture here's your big chance right here so hopefully i've shared a vision that gets you as excited as i am i come into work each day and i'm just awesome i'm ready to go i am amped to be a javascript developer i really life is pretty good for us right now there's this reusable revolution is taking off i am house core on twitter uh... i'd love a tweet of feedback thank you all for listening