Looking for Okta Logos?

You can find all the media assets you need as part of our press room.

Download Media Assets

Cory House – The Reusable JavaScript Revolution, Iterate 2018

  • Transcript
  • Details
  • Related Content

Share:

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. 

I think we can all agree that JavaScript is one of the most important languages on the web today. If you're in the JavaScript world, or you are even near the JavaScript world, you've probably noticed that the JavaScript community and the JavaScript ecosystem can move really fast. Just in the time that I've been up here, right now, talking to you guys, four new libraries went live on GitHub. I wish I was kidding about that.

Our next speaker is someone who's on the cutting edge, on the forefront on how the JavaScript world is changing. Cory House is an author, software architect, and a fantastic speaker who also runs a JavaScript consulting shop in the spare time. He has been instrumental in helping me understand how the JavaScript world is evolving, and he's also made me a better developer through his talks. So I'm super excited to welcome to the stage, Mr. Cory House.

Cory House: I get nice intro music, I like that. Thank you, Nate. That was a wonderful intro. 

So I come up here with good news to begin my session. The good news is that we are living in the future. The future is here, there's just this minor wrinkle that is not evenly distributed. The whole point of my talk today to share with you the future of JavaScript and to help point out to you that this future is not evenly distributed. So some examples of exactly what I'm talking about here. Most of you probably drove a car that uses plain old gasoline to get here today, but we know that in the future, increasingly, the story is going to be driving a Tesla, driving some kind of an electric vehicle to get where you're going. And this is awesome. This is a cleaner future. Seems like a big win. 

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. 

So what I'm up here saying is that the future is here and it's not evenly distributed. And it’s the same story with JavaScript. 

What I'm going to share today are a few different things that are going on in the JavaScript space and in fact, nothing that I'm sharing today is completely new and in fact a lot of it has been around for quite a few years, available right there at hand if you wanted to leverage it. So what you're going to find is the majority of this room isn't doing things that they could be doing now. So really my goal is to get you excited about picking some of this stuff up now. And what I want to talk about is three specific revolutions that have been happening in the land of JavaScript over the last decade. 

Now, of course I’ve got to start this off by mentioning Jeff Atwood. I think it's interesting that just about 10 years ago, Jeff coined Atwood's Law, which says that, "Any application that can be written in JavaScript will be written in JavaScript." And when Jeff said this, this sounded pretty silly. It really ... We thought, "No, I mean, maybe. Maybe." But that really has come to fruition. I mean, I look at the fact my favorite editor today is VS Code. Anybody know what VS Code is written in?

Typescript, yeah. Which is pretty much JavaScript, it's close enough, and HTML and CSS, because it is just an app that is run via Electron. It's built via Electron. My favorite way to waste time and send gifts to my coworkers is Slack, again, it's an Electron app. It's really just JavaScript behind the scenes. 

So JavaScript today is everywhere. We think about ... Yeah, JavaScript got started on the web. That was a great start and this is still what we mostly associated with. But for years now we've had the ability to write JavaScript on the server using Node. And we've all got so many interesting options to write JavaScript for mobile apps now too. We have React Native, we have NativeScript, we have PhoneGap, lots of options. And then as I just alluded to, you have projects like Electron that allow you to write desktop apps. And I will tell you, I know people that have solid desktop chops. They could use something like WPF to write their Windows apps for instance, but who actually prefer the Electron experience. So we're increasingly seeing people actually choose JavaScript even though there are dedicated platforms that they could be choosing instead. 

So I like to say that JavaScript is a lot like Visa. It's everywhere that you want to be. And really is an interesting world that we live in. So I’ve got to give credit to Jeff Atwood. He was right about the direction we were going. 

Now that said, if you're like me, you probably have to recognize JavaScript is not the world's greatest language. We didn't choose JavaScript because of its technical chops. We chose JavaScript because of where it is. And there's recognition today that so many people are using JavaScript because they can build pretty much anything anywhere. It doesn't matter if you're a Mac guy, or a Linux guy, or a web guy, or a Native, all of your interests allow you to still use this technology.

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? 

Something. That was helpful, yes. What was the guess? All I hear is low mumbles. Okay, I will just tell you. It was npm. npm has been around since 2010. I heard the ... what? Did you actually say npm just not loud enough? This was your chance to be the winner. Okay. So this was huge for me, massive for me. That's why I went to the work of getting these firework videos. I had to emphasize how important this was. Because in 2008, I'd been writing code since before 2000, but in 2008, this was what my JavaScript looked like. It was painful. It was script tag, after script tag, after script tag. This is really another homage to Jeff here. It is true. There's a lot of copying and pasting going on.

So this looks painful just at a glance, but let me tell you what it was like working in this era. What I would do, I'd begin by searching the web, imagine that I want to go find some new library. So I'm going to search the web, see if I can find what I'm looking for. Once I find it, I'm going to read the docs to figure out how to install that library that I found, and then I'm going to download the relevant JavaScript, CSS, to put that to work, and then write some necessary script tags within my app so that I can use it. Then it's time to target some sort of HTML using often jQuery. I would end up writing a JavaScript selector of some sort. 

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. 

My point is this, we all write code and npm allows us to reuse it. If you have ever written a line of JavaScript and thought, "I'd like to use this on another project," that's what npm is for, simple as that. So question, how many of you are using npm packages today? I expect to see lots of hands. There we go. Vast majority of the audience. But I have a more interesting question to ask you, which is this. How many of you have ever published an npm package? That's much, much fewer hands. That's more like 20% of the room instead of 70% of the room. 

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 I'm a big believer that opinions are valuable and this is what we're saying. We're saying at Cox Automotive, if you want to do software development in JavaScript using React, here's a bunch of packages that we think are useful. Now you can see me, I'm navigating over. I'm showing you some build scripts that we have built in as well. Now, we happen to be working in our React app's code and then we pulled it over, we made a fork of it, and then just made some tweaks for our team. And we did that because just like you, we have some opinions that are unique to us. So in that way, we've been able to tweak this React app to do what we want. And you can see this one package, when we launch a project, you have a single line in package.json, just one dependency. And this is super valuable because it means we have, at this point, published over a dozen different applications and they all reference this one package. So later when we realized we want to upgrade React, we want to change the way we're transpiling Babel, we want to change the way that we're linting code, whatever may be, we have one single spot for people to touch. So this is a really powerful approach.

Okay. So I said I'm talking about three revolutions up here. The first revolution, I just discussed. That was npm packages. And we just saw that although 70-something percent of us are using npm, only about 20% of us have actually published a package. So I would encourage you to think about what on your team is reusable and what on your team should be standardized, because npm will allow you to do that. And you can see, we took a hundred and some odd open source projects, put them together and said, "Here's how we do JavaScript development at Cox Automotive." 

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.

Now, this was a funny joke back in the day because everybody felt like they had to use jQuery or MooTools at the time, so the idea of using plain Vanilla JS seemed to have fallen out of favor. And I would say, at the time there were people using those libraries when they really didn't necessarily need them. But I would argue that today Vanilla JavaScript is malpractice. Now, that seems like a pretty bold statement. Let me see if I can back it up for a moment. 

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. 

So the question is, if you're going to do all of that and you're starting with Vanilla JavaScript, then you're gonna have a bad time. You don't want to do that. You really do want to leverage a long list of npm packages that are already out there. And that's why I say that "File -> New Project" today is malpractice because there is so much inertia that you could be offering your team by having a clear starter kit. Some would call this a framework, some call this a boilerplate, lots of names for the same thing. But right now, if your teams, each time they start a new project, are really going in with a blank slate and an editor and starting to write JavaScript, that's doing it the hard way. Let me emphasize this problem by showing you just a few of the decisions that you're making today that you might not have even realized.

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. 

Unit testing. Lots of people talk about unit testing, but in my experience going around to a lot of different companies and consulting, most people are talking about unit testing and an unfortunate minority in JavaScript are actually running tests. This is why. Because people are overwhelmed with the number of decisions that they need to make here; where to put their test, when to run them, what library. There are six different popular testing approaches out there, or I shouldn't say testing frameworks. I'm a big fan of Jest, myself, and I also really like Mocha. Those are the two that I'd probably recommend, but lots of other decisions here I can't get into in our short time. 

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. 

It's crazy. I mean, I can sit here and just let these decisions roll on and roll on. There's about 50 different decisions that you need to make here on starting a new JavaScript app. So I stand by my statement that File -> New Project is malpractice. Your team needs to have opinions on these things. And this is the thing, I show you this slide deck, you all know that these are important decisions to make, but I guarantee, if you start from scratch, you're going to forget 20 or more of these because you're just busy. You've got to ship something to production, you've got a timeline. 

So the question is, if these things are malpractice, what do we do instead? Well, I am driven by my dissatisfaction of the current state, of the fatigue that I feel, a feeling like setting up a project in JavaScript is a lot of work to get everything that I talked about there. So my suggestion is rework. I'm suggesting avoiding the tedious setup by actually creating a starter kit and eliminating all this pain that people feel of trying to keep up with all the best practices. So what I would argue is the real solution here is to codify your opinions, put them into a boilerplate, a starter kit, a framework. And this is useful because it takes a whole lot of weight off of people's heads. 

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. 

So let me share some of the things that my team takes for granted today because of our starter kit. We know that we can use the latest JS. In fact, we can even use cutting edge features that aren't yet part of JavaScript because we have transpiling configured. We know that every single time we hit save, our tests will rerun automatically and we'll get output right there in the bottom in our terminal. We use the terminal just built into VS Code, but any terminal will do just fine. We know that when we go outside of our coding standards, linting will tell us on what line we made that mistake. We know if we need to do any kind of debugging in production, yes it happens, we will have source maps there to back us up. If we want to start the app, we say npm start. If you want to build the app, we say npm run build, and if we wanted to deploy the app, we say npm run deploy. All of these are decisions and manual processes that so many teams are going through today and they need not, because the more that we can take for granted, the faster that we can move. So I'm constantly looking for what else can my team stop thinking about so that they can focus on just the business problem.

A starter kit is useful because it gives us this automated interactive checklist. It increases the number of things that you can take for granted. And I want to emphasize that the starter kit that your team creates is going to be different than the company next door because your team is solving different problems. You're building different applications in a different industry. Your team has its own unique preferences. Maybe your team works in C# or Java on a server and that means that you really love types, so you should probably embrace Typescript on your team, but other teams are going to have different opinions. Now, of course, I've had to gloss over all sorts of things here. I have a five hour course on Pluralsight that goes through all of this in detail and shows how to build a JavaScript development environment and all the decisions that you need to make because I've only been able to hand wave over a lot of this.

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. 

Now, when you say npm start, it fires up an example application and this is useful as well because it lets us show people how the code works. So again, since we've embraced React on our team, this is showing people how we build React applications that's using React Router, that's using Redux. People can see how the data is moved around. We show people where we put our action creators, where we put our reducers, lots of technical minutia that's useful for people so that they can see the unique ways that we write JavaScript on our team. So this is powerful, things like a Mock API. You probably had this before, where you have a user interface that you need to build but the API isn't ready yet. Well, we have a Mock API built in and it actually saves your data. It simulates a full credit experience. 

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 question, how many of you out here have your own boilerplates, starter kit, that sort of thing for your team? That's about five percent of the room. Very, very few. So I emphasize this again, the future is here, it's just not evenly distributed. I'm convinced that this is a pattern that more and more people will be embracing. And I'm already starting to see it at some conferences, more people picking this up. At JavaScript specific conferences, I'm seeing more hands go up in this area. So I feel like this is a trend that's going ... And it really has to because without the starter kit, without this clear framework for your team, what you'll find is a lot of people reinventing the wheel in different ways. You'll find this project uses Mocha, and this one uses Jasmine, and this one uses Jest, and you go, "Well, those are all testing frameworks. Why haven't we standardized on a single testing framework so that people can move between teams and we can learn lessons as we go?" 

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. 

Okay. So those were two of the revolutions. I want to close with the third and final revolution, which is components, reusable components. A reusable component is really this mix of HTML, JavaScript, and CSS that you can put to use in multiple places. And there's all sorts of reasons that this is useful: consistency, having less code. You think about each time I use a component, that was code that somebody didn't have to download again if I put it in two different places in the app. This helps you move faster and also, less code equals less bugs, so that's another big one. Facebook of course is heavily invested in reusable components and they found that it lets people quickly ramp up as they move between projects. And also, when people are working in the same code base, it's easy to find the things that are already created. 

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. 

One thing to think about, if you're going into reusable component design, the world has changed. The old world was this. We thought about separation of concerns in terms of JavaScript, CSS and HTML. Those weren't separation of concerns. Those were separation of technologies. 

The real concerns that we're worried about today in the component world, I want to separate my button for my time picker. I want to separate my time picker from my date picker. Those are separate components. I want to separate my navigation from my footer. Those are truly our concerns and the fact that they happen to use HTML, JavaScript, and CSS, that's really not that important because I really just want to think about this thing in isolation. 

And there's a weird question. If you today came to me and said, "Hey, can you share this HTML with me?" I'm not sure how I answer that. There's not enough context. Not to mention this monitor isn't even on, like what ... This is the most distracting thing as I am creating talks is I come across stock photography and I just find myself laughing. "Oh, that one's going too. I could make a meme out of this." Now, keeping in mind the reason that I would squint at you funny if you said, can you share this HTML with me, is I don't really know how to do that other than copy and paste it into an email because there's no mechanism for me to do so. Today, for me to share that HTML with you, I really have to use some JavaScript. So for me to share this (<div>Hello World</div>), I need this (JS). And the question then becomes, how do we get this done? And over the years we've seen all sorts of ways to get this done. 

So final quiz question. What was released on August 20 26, 2006? 

JSFiddle. 

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. 

It was jQuery, yes. I got to put this video to use again. So jQuery was huge and I was so excited about jQuery when it came out because I was writing JavaScript back before jQuery existed and stumbling through cross-browser issues. It was very, very painful. So this was huge when this came out. But the other thing to keep in mind was jQuery was the first time that we had reusable components. jQuery had this idea of plugins and jQuery plugins were really the first popular reusable component idea, and you could go out there and pull down plugins on all sorts of things. But of course, you know jQuery is not the cool kid on the block anymore. We have matured into newer libraries. So the real question you have to ask yourself is, what should I use today? Which tech? 

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. 

One approach you could consider is web components, and I will tell you when the web components standard came out, I was really excited about it. For those that don't know, this is a built in to the platform standard and it has been around for a little while. It just hasn't quite taken off. It's composed of four technologies: templates, which are really a place to put reusable markup, custom elements, which is a way to extend HTML by declaring your own elements, the Shadow DOM, which encapsulates styling, and finally imports, which bundle HTML, JavaScript, and CSS. So that's the core idea. And you think about, if I'm going to create reusable components, these are the sorts of things I need. And in fact I created a whole course on Pluralsight on this topic and I was really excited about it, and now I'm just not. And I'm not because of some rather particular reasons. 

One is this, the browser support remains quite spotty. Let me show you exactly what I mean. So the template tag has fairly good support except for lacking an IE and Opera Mini. But the story on the other three features here, HTML imports, Custom Elements, Shadow DOM, lots and lots of red. So this means that today, if you want to use the standard, you have to pull in polyfills. Those polyfills are not free. The weight of those polyfills is often as much as the weight of some modern JavaScript libraries like Preact or like React itself even. So you have to ask yourself, why choose the standard if I have to pull in polyfills? 

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.

Let's look at this. In React, I don't need templates because I have JSX. I don't need Custom Elements because that's exactly what a React component does. It effectively extends HTML. I don't need to Shadow DOM because we have other ways to encapsulate our styling now, like CSS modules or CSS and JavaScript. And I don't need Imports because I use npm and my bundler already to handle imports. So these are all solved problems already. 

So my take is don't wait for the web standard to catch on. Modern JavaScript already has this problem solved today. The question is, which framework should you use? So let me just give you, these are the big four right now that are pretty popular. There are lots of others out there, but these are probably the four most popular at the moment. 

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. 

Okay, if you're one of those people that likes to take a picture of a summary slide then get ready. Here we go. So three revolutions I just talked about: npm. The revolution here is create your first package. Starter kits. My suggestion here is codify your decisions, automate the pain away. And third, components. It might take awhile. Pick a library and start sharing. When you do those ... Oh, I'm sorry. Can you go back a slide? I actually hit one too far. When you do these three things ... Here you go. If you want to take a picture, this is really the summary slide for the talk. When you do these three things, life is awesome. I have really been enjoying software development and in particular JavaScript. So I have a lot of experience, for instance, on C# and .NET. I have found myself having more fun and feeling like I have a better development experience today in JavaScript than I do in Visual Studio and C# on the server. It's really a wild contrast. So my hope too is that you will embrace the future because the future is pretty awesome. It will get you all fired up.

So I also have up here, if you come up and see me afterwards, I have some free trials for Pluralsight. I author courses for Pluralsight. I have courses out there on JavaScript, on .NET, on web components, career talk as well. And so if you come up and see me, I'll be glad to give you a free trial. Also, I have, it looks like my timer says eight minutes and 40 seconds to take some questions. So I'd love to chat with everybody, if you can bring up the lights, that's what I got. But if you want you can clap now though because claps are good. There we go. Cool. Thank you. Any-

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.

 

Cory House
Author, Software Architect, Speaker

Share: