Nate Barbettini: So, now it's time for me to take off my speaker hat and put on my organizer hat because I'm also the organizer and the host for the rest of the Build track with you all this afternoon.
Cory House: I get nice intro music, I like that. Thank you, Nate. That was a wonderful intro.
Now, some pessimists might say, "Yeah, but that Tesla doesn't run on magic. It runs on power, and that power was generated potentially by dirty coal. So how clean is that Tesla?" Well, there's other good pieces of the future that are already here. If you're lucky enough to have an arrangement from Solar City, then you can have these tiles installed on your house that are pulling in power. You can be completely off the grid. This can be your life. And this is a pretty awesome future. I'm really excited about this. But again, this is a very small portion of people that are yet getting to experience this right now.
Finally, if you go to the grocery store, this is our life. We stand on line. We wait to be able to check out. And for the vast majority of us, this is something that we'll continue to live with for a little while. But, in fact, if you are lucky enough to live up in Seattle, then you can just run into the store, grab a bunch of things off the shelf and run out as fast as you can because they will magically charge you for anything that's in your hands when you walk out the door. This is amazing stuff. And that is the Amazon Go store in Seattle. This is really another sign of things to come.
Okay. So we're going to talk about three revolutions. The first one that I want to talk about started on January 12, 2010. What happened on this date? Anybody?
At this point I typically realized it didn't work and I would wonder why. So I try to fix it. Often my DOM query was wrong because again, in the jQuery days, I was trying to attach it to a certain DOM element. And even after fixing that, it still wouldn't work. So then I'd realize maybe the script order is wrong. Remember all those scripts I showed you? You had to put them in a certain order, maybe this one below this one, get out this one up here because I need this dependency for this. So I'd fix that and it still would not work. I would wonder why and then realize I should maybe read the docs some more, and I realized, oh, I was using an older version of jQuery. I need to use apparently the new one because it says it way down here in the docs. So I would fix that and repeat again all these steps to go update jQuery. It wasn't a simple little command. I'd have to go pull down the file and go through all this work. At this point I would probably drink heavily. That was most commonly the way it went. It was a painful process.
And then ask yourself, "Oh, what if I want to keep this updated? What if later I want to update these dependencies that I brought down?" I would have to repeat all this again. Rather painful. And what if I wanted to minify bundle, test this code, maybe transpile it? Not going happen. Not a chance. Painful world in 2008.
So we have come a very long way. Let me show you how far we have come. Tell you about life today on my team and life for anybody in here that wants to take this on. npm install lip, choose whatever library you want. You want to put it to use? Put an import statement up at the top. You want to update it later? Type npm update. That's something to celebrate. Life has gotten much, much better. This is a huge contrast.
And I have to make a bold statement here and make you all squint. Man, this screen is bright. JS doesn't have a base class library, so npm packages come in and they fill this gap. And npm is the world's fastest growing package manager by a long shot and in fact, this chart is way behind because npm has crusted a half million packages as of a few weeks ago, if not months ago. It's staggering how fast. And you look at, I mean, .NET is a big ecosystem, Java is a big ecosystem, and they're way down here and their lines look almost flat relative to the growth of npm. So npm is huge. You're looking at 66 per day, 139 per day. Those are the numbers for Java and for.NET, whereas, last I checked, 450 packages every single day. So Nate's little joke before my talk, it's fairly accurate. Every single day, 460 new packages. Little caveat there.
You could celebrate the growth, but it is true, anytime you have this much new stuff going into a package manager, yeah, there's some problems there with that. And now also Sturgeon, he wasn't exactly the world's greatest optimist. This was the happiest picture I could find of him. So take it for what it's worth. I would also argue with Sturgeon that if truly 90% of everything is crap, a bigger pile is still better because there's 10% in there that's really good. So give me the bigger pile, we'll find the 10%, and we're still in a better spot. And this concludes the crap section of my metaphors. We'll move ahead.
I do feel like we have to look at this glass half full because this really is a first world problem type of thing. Yes, yes, life is awful with all these free things that people keep creating. It's so hard to keep up. I try not to complain.
It's a bit like, do not go to a family reunion and complain about all the recruiter emails you get, "Oh, it's so annoying. All these people wanting to offer me a job." Well, I resonate well. Okay, back on track.
So this is where I say the future is here, it's just not evenly distributed, because I can imagine that almost all of you are working on a team where you'd like to reuse code later, so I would encourage you, publishing an npm package is crazy easy. You go watch a quick little video, you throw it out there. It's super slick. It really is very painless to do so. So as far as publishing a package, I want to show you a video of a package that my team has published, which is called Fusion. Now given this is actually a closed source project right now that may be changing here soon. But what I want to show you is a single package that we have used to do development at Cox Automotive, so full time. I'm a software architect there. And what I'm showing you is the page for Fusion, and what we've done is taken a large number of packages and then bundled them all together.
Now you can see, I'm going to click over here and go over to our GitHub file, and I'm going to pull up package.json. The most interesting thing about this package is, it's really an npm package that's full of npm packages. That may sound a little confusing, but what I'm showing you here in line 27, is where our dependencies begin, and then I'm going to scroll down about a hundred lines to show you all the different dependencies that we have.
So let's shift gears and take a breath, talk about revolution number two, which is starter kits, or what I also like to call Part Deux. Now, back quite a few years ago there was a project called Vanilla JS, and some of you are already laughing at the joke here. Well, Vanilla JS was interesting because you could come out here and build your own download and select all the features that you want, maybe AJAX, event system, some functions as first-class objects, ooh, closures. I like closures. That sounds impressive. And then once I've selected my features, I come down here and I click download. Now, you can see it downloaded. I'm going to go ahead and open this up in my editor and, oh, there's the file, and that is the punchline. That is Vanilla JS. There's nothing to download. Vanilla JS is using the platform.
Today, this is what your app is often expected to look like. You're expected to have a single bundle.js that encapsulates all your apps code, and that's not trivial. This is a hard thing to actually do because these are all the things that you're expecting as part of that. You want to be explicit about what your application’s dependencies are. You want your code to be modular, as in each one of these files stands on their own and encapsulates its own code. You want to minify, transpile, lint your code so that it's consistent. You want automated tests on your code, and you want automated builds and updates over time.
Yes, of course, you've got to choose an editor. I really like VS Code. That's what I'd recommend. You got to pick a package manager, a pretty easy decision today, npm, but you might not be aware there are alternatives out there. You need to pick a development web server, lots of options, Express is very popular. You might not have heard of Browsersync. Browsersync is super cool. So imagine that you had a need to test all sorts of different mobile devices. You could create a wall of mobile devices, and then you could pull up your laptop and navigate through your application, and all of the devices on the wall would move in lock steps. You'd be able to see, oh, that ancient android phone isn't rendering properly. And you find that out right away just visually looking at the wall. Really cool, and it's a free tool. So lots of options here.
You have to choose an automation approach, Gulp and Grunt used to be very, very popular. Today, npm scripts are largely replacing these and that's what I would recommend. Simple, no extra abstraction layer needed.
You need to pick a transpiler. I'm a fan of Babel. TypeScript is great as well. Elm is super cool.
So these are other decisions that need to be made. And I emphasize this, it'd be nice if your team or your company said, "You know what, we have decided to standardize on one of these, so that every new project you're not having these same sorts of religious conversations." Because to some degree here, this is a tabs versus spaces conversation. TypeScript gives you some power, and TypeScript also impedes you in some ways because anytime you had a types system, there is some cost to it. So it's a tough call.
You need to pick a bundler today. I think that's becoming an increasingly easier decision. Webpack is wildly popular, but there are a number of other interesting options out here.
You need to pick a linter. I'm a big fan of ESLint. In fact, I can't think of a single good reason to reach for JSHint or JSLint. ESLint is wildly configurable, has a very robust ecosystem, lots of people are excited about it. If you have found yourself in code reviews saying, "Hey, please don't do this anymore," if you found yourself saying that a second or a third time, it's time to write a linting rule for it in automated way. I will say, our code reviews go so fast now because now, when somebody does something that's outside of our coding standards, it is told to that developer immediately. Line 21, this is a problem. Don't do this.
You need to choose a CI server as well, Continuous Integration, many approaches.
You want to make HTTP calls with your app. Okay, which library would you like? I'm a fan of Axios, but other good options up here, maybe plain old Fetch will work for you.
I want to share a book that I found really useful. The Checklist Manifesto is a book that I recommend to all sorts of people, even if you're not a software developer. And it was very interesting because in The Checklist Manifesto, what they did was mandated checklists within hospitals. What they found was when doctors have to follow a checklist, they consistently do everything that they're supposed to do. But even for simple things like prepping before you end up making an incision on someone's body, it's really easy for a doctor to forget one of the six simple steps: You've got to wash your hands accordingly, you've got to put clean sutures over an area, all sorts of little things like this. Well, what they found was doctors, although they have the head knowledge, they don't consistently do what they know they need to do. And as developers, we're making the same sorts of mistakes.
So here's what they found when they fall around doctors and just use checklists. The doctors ended up going from 11% infection rate, down to zero percent infection rates on their patients. And this is huge because in an ICU, if you get an infection, a large portion of the time, you get very, very sick and often die. These are people that are already in bad shape. So the checklist ended up preventing 43 infections, eight deaths, and over two million dollars, all just by having a nurse there saying, "Have you done this? Have you done this? Have you done this? All right, now let's move forward."
Now, of course as developers, we don't like the whole idea of a manual checklist. I think it makes us feel ... It just feels too manual. We want something more automated and that's precisely why I recommend creating a list. But I do also think part of it is just ego. Doctors didn't like the checklist. They fought against it because they said, "I went to medical school. I don't need somebody asking me these questions ad nauseam, multiple times a day." But they had the same problem that we do. We know what we need to do, but it is just really easy for us to overlook a step in the heat of the moment. We're trying to fix a bug. We're trying to get out to production.
So one thing that we do, we do follow a checklist model to some degree on my team, and the way we get that done is if you create a file called "PULL_REQUEST_TEMPLATE.md" in GitHub, every single time a pull request is created, this is what you'll get, whatever's put within that file. So we create a checklist right here. So we go through, check each of the boxes. Once they're all checked, we know that that code review can be merged.
Now of course, as much as you can, it's useful to automate these things, but there are some things that we've found useful to put in a checklist. So again, best to automate. And the reason that I suggest automating if you can is the more things that we can automate, really, the more that a society can advance. The fact that we could take for granted that these lights were going to work, that the laptop would start up that would show these slides, that we would have clean water when we went over to the water fountain, all of those are the baseline things that we take for granted so that we can be in this room just talking about programming.
But I want to summarize what I would suggest for you to do when you get back into the office and that's this. Just schedule a meeting. Just start the conversation. Get some people in the room and start talking tech. Have a nice civil conversation about the issues at hand and I think you'll really find it enjoyable. It's always entertaining. And this slide is loosely based on an actual interaction in our office. This will happen because there are some rather strong opinions in these areas, and that's precisely why this is useful too.
So let me share a demo of our starter kit and how it works. So I've come out here to our GitHub repo and I want to show you the experience that people have when they're going to start a new project right now. What they do is they clone the project, they pull it down, and then they run a single command a to set it up. I'm saying npm run setup, and that's going to set up the project on my machine. So you see, down at the bottom it's going to install some projects. It's going to prompt with some basic information about the project. It's going to ask me, "Hey, what do you want to call your project?" It's going to ask who the author is, what is the version that you want to start with? What's the production URL for your project? Any sorts of things that make each one of your project's unique, and of course I would recommend, look at your previous projects on your team and ask yourself, how do each one of these differ?
And here I am entering a base URL, entering a license for this project, entering a description. And these sorts of things also help generate a readme. So often I see projects stood up that don't even have a readme, which would be useful. So once I did that, you can see that it created a populated package.json with answers for the questions that I just asked, helps emphasize that these are important fields for our team.
And then you notice down here there's one single dependency. Remember how I showed you earlier. We have one npm package that contains all the dependencies that we recommend using for our projects. And this also gives us a nice stable baseline because that means we know exactly what version of React every application will be running.
And then we show people how to lazy load components and how to lazy load libraries as well. So on this tab I was actually pulling down Moment, but I didn't download Moment until I clicked on that tab. So that's another useful way to make sure that people are saving bandwidth along the way.
Now I've come back down to the console and I said npm run-removed demo. And I did that just to get rid of that demo application and put the application in this state. So now I'm really ready to start coding. I got all the craft of the demo out of the way, I've got a clean project here. And what's great about this is when somebody joins our team, this is just the process. And if at any given point a new person joins the team and says, "Well, I was confused by this," or, "I found this clunky," or, "It seems like we need this other tool," we have one npm package that we can go tweak and update.
One example, React 16 is coming out in the next ... Actually, it just came out a few weeks ago, and we are going to upgrade our npm package to have that built in and also are handling some potential breaking changes behind the scenes for people so they don't have to feel that pain. And then anyone using our packages will be enjoying that new version.
Now, what I just showed you is unfortunately, not open source, but I do show something rather similar. If you go out to my GitHub repo, just look at a react-slingshot. This is an open source React starter kit that I created a few years ago. I'd also recommend looking at Create React App. It's a great option.
So over 40 decisions that you really have to make here to make a starter kit. It's an automated checklist and it's a way to codify your opinions. So my suggestion is start automating the pain that you're feeling away.
Now, you might think that components are really a software sort of idea, but no, not at all. Components in the automotive industry for instance, look at this Mercedes, it looks so special, so unique, very expensive car. But if you start looking around in here, you realize, well, the seatbelt, the airbag controller, the transmission, even massive things like the engine are components. And I say that because one Mercedes, that transmission inside of it, or that engine inside of it may be used in multiple models.
Now how mature of an industry do you have to get to the point that an engine is a component? In fact, in the automotive industry, entire platforms or chassis, you could say, are components. This is where we're headed. This is awesome.
Software development is going to move so much faster when we have the power of reusable components at a big scale. Now we're in a bit of a tough spot right now because some of us are in Angular, some are in React, some are in Vue. We're very separated in the way that we're getting things done, but I do believe this, the modern dev shop is increasingly becoming an assembler of reusable components. We're putting pieces together. And I will tell you, our teams now, more and more that's what they're doing. We have a reusable component library, I'll show you here in a second, and that has helped.
So final quiz question. What was released on August 20 26, 2006?
Well, that's a pretty good guess. I think you're in the ballpark. That's got to be really close. It does have a "J" in it.
Now, I'm going to share an opinion with you, but I want to share a quote from Derek Sivers. Sivers says, "Strong opinions are very useful to others. Those who undecided or ambivalent can just adopt your stance. But those who disagree can solidify their stance by arguing against yours." So there's my little caveat. But really, I'm just up here sharing all sorts of opinions and I don't expect you to agree with everything, but I do expect that me sharing them will help you solidify your stance.
If the question is, will this play out well? And I'm going to say, the developer ergonomics are also a bit of a challenge here. The thing is web components don't actually enable anything new because you can get the same things done with Angular, Vue, Ember, react, whatever you like. The thing is JS libraries just keep on innovating, keep on making things better.
Key features to look for. This is what I suggest. Look for stability, broad adoption, low boilerplate, and lightweight. So let's see how my preference, React, stacks up here. Stability. If things change in React, if you hit a breaking change, Facebook actually publishes code mods, so you can change your code base without actually going in line by line. Now Facebook has to do that because of this number right here. This is actually outdated. The last count there are over 40,000 React components in the Facebook code base. This means that Facebook can't afford to make broad breaking changes to React's API because if they did, they'd have to go update 40,000 different spots. They have to rely on code mods that can be easily accomplished in an automated fashion.
You also want something that is low boilerplate, and really with React, it couldn't get much simpler. It's a function that returns HTML. I'll show you a React component. It's really easy to figure out. It also should be lightweight. I need to update this slide, but it's 35k today for React and if you choose Preact, it's a whopping 3k. It's amazing. And Preact, if you aren't familiar, is just a lightweight version of React, effectively a project that was heavily inspired by React that took out just a few minor features to make it a lot lighter.
Now, that said, I may change my mind tomorrow. Today I'm a React fanboy, but if you knew me couple of years ago, I was a big fan of Angular, before that, I was a big fan of Knockout, before that, I was a big fan of jQuery. Really, I'm just a big fan of whatever at the moment is solving problems the best for me, so take my excitement for what it's worth. I expect, here soon, I'll be here in this situation going, oh-oh, there's something really exciting coming. What do I do with all the code that I wrote before? Well, the thing I think about is, if you have a low boilerplate library, moving to something else isn't the end of the world. If you told my team, for instance, that we had to move from React to Vue, we could do it. It's really not that hard of a problem to solve.
Now, given most existing projects, you just say if it ain't broke, don't fix it, but you can always shift to something else in the future. But when I say low boilerplate, I mean, here's a React component. The only real thing here that is interesting is, okay, I've got some angle brackets in here that looked like HTML. Well, that's JSX, but there's really no boilerplate to discuss here. Could this get any leaner? So my take is it's the design of the component that is the hardest part. Component coding is increasingly becoming pretty easy in these modern libraries because of the APIs are just really slick.
So choosing a framework is just the first of many decisions though. If I let this slide go buy, it will take way too long. There are over 50 decisions that you have to make if you're creating a component library today. So I put together a comprehensive course on this on Pluralsight. It's about six hours long. It blew my mind that it took this much time to go through. But when you talk about 50 decisions for your team, that's precisely why you need a component library for your team. So let me quickly show you how this looks for us. This is our component library and this looks a lot like any other one.
Now, the most interesting thing about ours that I'll just share briefly, I have that code over there on the right. See the comment up there on the top right hand side on line nine? If I go over there and I changed that comment, it changes what displays right here on the application because our documentation is generated from our code. We just put some JSDoc style comments in there, and it displays it. It also reads our codes. So we have code examples that you can just copy and paste, put into your application. So I'd encouraged you to spend the time thinking about what reusable components would be useful for your team.
So question, how many of you have a reusable component library on your team? Oh, quite a few. All right. That's probably 20% or so. That's good to see.
So let's quickly wrap up. This is a chance for a good gift. I don't know what was here before, but ... Oh yeah, it was a house icon. This is the joy of moving your slides to a different machine. I don't recommend doing that, everyone. That's why you've been seeing this weird envelope, things along the way. My point was just that, if you're going to build a component library, you need a foundation and that foundation is a starter kit. So you can think of that like the house. And now we have random texts appearing on the screen. Don't worry. This was all planned. Yeah, just like I want to. Yeah. Oh, it's getting worse. Let's just move on.
Question: The code review checklist, is it online?
Cory House: The code review checklist, is it online? No, it's not, although it can be. I'll tweet it out. So I'm HouseCor on Twitter. Oh, I guess they aren't showing the slides anymore. Housecor on Twitter, H-O-U-S-E-C-0-R. I'll post that up there. Good question. Others?
Question: What's your take on Yeoman generators? Because they can act as startup kits.
Cory House: On human generators?
Question: Yeoman, Yeoman generators.
Cory House: Oh, Yeoman generators. So Yeoman generators can operate. But here's the thing with a Yeoman generator, that's one way to get it done. Increasingly though, it seems like people aren't using Yeoman and they're just using plain npm, because npm itself, if you put it in a package, I mean, you saw what we did there, it gives the same sort of experience. I don't think there's anything wrong with doing it, it's just I seem to see the industry moving away from Yeoman and toward just using plain npm packages.
Look at examples, look at Angular CLI, look at Create React App, look at Vue CLI. None of those are dependent on Yeoman in any way. I think we just realized we didn't need that project to get that problem solved. So potentially if you like it, from my experience, Yeoman, it adds a bit of friction to the process. So I didn't feel like it was worth it. A good question.
Well, I guess I shouldn't point at people because, Nate, you get to decide. Get your hand up higher and Nate will get you a ... Did everybody like Nate's talk? Wasn't that awesome? I really enjoyed that one.
Question: Hey, you mentioned a lot of boilerplate code. What are your thoughts on like Redux or MobX versus other ...
Cory House: So your question was about Redux and MobX?
Question: Yeah, like just comparison. Would you guys prefer-
Cory House: Oh, you're asking, which has more issues with boilerplate?
Question: What is your preference?
Cory House: Oh, what is my preference? So there's no denying that there more boilerplate in Redux than MobX. Some would say that that's precisely a feature of MobX, and others would say that Redux was designed that way. I think when Dan Abrams put a Redux together, he was saying, "I'm going to choose being explicit over optimizing for the amount of typing that you do." And of course, there's a slide that I, or I should say there's a tweet that I love where people say, "Hey, pick your poison." Do you want to complain about too much boilerplate or too much magic? Because developers do this all the time, but pay attention when you're seeing somebody complain, what they're complaining about, there's another side of the coin there. So me personally, I have far more experience with Redux than I do MobX right now, but what little I've worked with MobX, I find it interesting as well. Honestly, I think in the short term in React, I'm expecting to see a lot of people using the new context API, which is coming out in 16.3 or ... Yeah, I think it's 16.3.-something. Anyway, it's going to be a feature release here soon. So yeah, that's a longer conversation. We should chat afterward.
Question: What are your thoughts on building other company using like web components first, and then how a React on an Angular on top of it as opposed to building that out using React or Angular?
Cory House: Okay. So your question is ... Yeah, this idea of mixing plain web components with React. So one thing that I've heard a lot of people advocating here lately is make the leaf nodes in your application web components because then those leaf nodes aren't tied to a given library, then they're not tied to React or Angular or whatever. I can see the argument there, but I also feel like the ... I personally feel like you make a decision on your library and you're already going to make a heavy, heavy investment in it. So that's okay. So like we, for instance, have just said, we're going all in on React because if we add in web components, then suddenly everything that we're doing, we have to have two different mindsets for it. We have to understand the web component specification and React. And then that also means we need the polyfills for the web components and we need the React library. And again, I'm saying React, but the same story is here for Angular, or Vue, or whatever.
So my take is for the moment, I just recommend picking one of the popular libraries and going with it. At some point if the web components specification is broadly adopted and offers the same level of developer experience and to some degree, even user experience that we get right now with these libraries, than great. But right now, personally, I don't see the win. Yeah.
Question: So I'm sure when you were making your starter kit, multiple people on your team had different opinions and inputs and stuff like that. How do you reconcile those sort of opinions of people? And how do you enforce that in a new app? They don't just like installing other version of the dependency because it has like a bug fix or something like that. Do make sure they come back, like the main fusion code base and update that? Or like just ...
Cory House: So those are great questions. As far as people disagreeing, there has to be somebody ultimately in charge. I'm a principal engineer, so effectively it came down to me. People disagreed, I will tell you. So I'm in .NET shop and lots of C# developers wanted to see us choose TypeScript. But I got up, I did a tech talk and I told everybody why I recommended us choosing Babel, and I gave them a number of reasons why. And I also talked about the good things of TypeScript and I said, "Look, if we as a team in this room can come to an agreement that TypeScript is still the win after I've made my piece and other people have come in, then that's fine. But I think it's really important to have a dialogue to make it clear that this is a decision that we all make together."
Yeah, you're going to have some people that are disappointed with the technical decisions made, but you're still at a better point if everybody is standardized on something, even if that wasn't necessarily everybody's first choice.
Now, as far as updating later, again, that comes down to Fusion itself. We have to ... Basically, my team now spends most of our time trying to keep a hundred and some-odd packages still working well together and updated, running the latest because remember those hundred and some-odd packages, those teams aren't talking to each other. When Babel releases something and webpack releases something, we've got to figure out how to glue them together. So that keeps us very busy and people can choose to update when they want.
I've got two minutes left.
Question: Hey, what tools and strategies do you use to maintain your component library?
Cory House: What tools and strategies do we use to maintain our component library? Well, that's a broad question. So as far as the documentation approach, we're using react-docgen, which actually reads the code and then generates those docs that I showed you there. In my course I actually showed how I built that thing because there's not an open source library that does it. You could use open source tools for that. I don't know if there was a more specific question you have in there? That's big enough and I'm not sure how to cover it quickly for you.
Question: Yeah, maybe like versioning. I assume every component is like in separate npm package like-
Cory House: No, it's not.
Question: It's not? Okay.
Cory House: It's not. So we have a single ... This is the thing, our versions moved rapidly over the last year. We're launching 13 this week. And in one year we've had 12 major releases. Think about, if you have a hundred and some-odd packages in there, anytime one of those makes a breaking change that we can't obstruct away, We have to do a breaking change too.
So I'm sure you're familiar with semantic versioning. Semantic versioning says if you make a breaking change, it is a major release, even if it's a one line code change. So it's not about was it a big important exciting thing? It's we follow semantic versioning. So everybody can look at the version numbers and they know what they're getting out of it. So that's really the key for people, is they can decide when they're moving to that. Also, writing really clear release notes. You read our release notes, you know exactly what you're getting in each release. So it takes a lot of time to put those together.
I'm at a time. Tons of good questions. Thank you all for listening. See ya.