John Lindquist, co-founder of egghead.io, interviews Michael Jackson, co-creator of the react-router library, and co-founder of React Training. Michael discusses his experiences with running a massively popular repo with a relatively small code-base, pioneering of new features, and the future of CDN based importing.
Michael gets into the early days of the react-router repo, and what he had to do to steward the library. "In open-source, you are not just coding all day." It's mostly management, with it being a relatively small code-base that had a lot of users created a situation where you had to have excellent communication and a lot of deliberateness with what you change.
Michael is extremely excited about the future of the CDN and unpkg. He says that it would be awesome if Facebook or Pinterest only needed to load the package once, or even if individual modules were loaded instead of entire libraries. unpkg is excellent and predictable. No need to read the documentation on how to include the library in your app. No need to worry about builds, webpack, bundling. It brings back a fresh perspective and lets you just use the web!
John Lindquist: All right. Michael, why don't you go ahead and introduce yourself for everyone.
John Lindquist: Nice. Two boys and two girls. That's a good balance.
Michael Jackson: Yeah, it is. 11 and nine are the boys and then six and two are the girls. So, it's a good spread.
John Lindquist: Yeah, my kids are real close to your kids' ages. We'll have to hang out sometime. Hey, so I got the React Router site open in the GitHub page. I just want to run a couple of numbers by you and get your reaction here. Right now you have 25 open issues and 4,268 closed issues. How does that make you feel?
Michael Jackson: You know what's funny? React Router was like one of the very first popular opensource projects around React.
John Lindquist: Yeah, for sure.
John Lindquist: But how does that feel for you managing such a largely dependent on opensource product? That's a ton of people asking you a ton questions, probably feedback, both wanted and unwanted.
Michael Jackson: Absolutely.
John Lindquist: What's that like for people who've never done open source or had success or, I don't know if you'd call it success, but a popular opensource.
Michael Jackson: Yeah, absolutely. First of all, I'm still learning about it. I'm still learning the best ways to be a good steward of this project. I've had a lot of great help along the way. It's kind of funny that the Router has kind of now gotten to this point where it's such an integral part of the ecosystem and a lot of people depend on it, a lot of people use it and you can't really do anything without a lot of people in favor and a lot of people against it, right?
John Lindquist: Yeah.
Michael Jackson: There's hardly any issue that comes up where everybody is all on the same side. In fact, there was an API change that we wanted to make just recently. We got one of the ... it's just a prop. We got the default value of one of the props wrong on one of the components. Well, it's a Boolean props. So, in order to change that is gonna be a breaking change. It's not like we can just introduce some other prop and change it. And so, but it was wrong and so we got to move it forward. We gotta we gotta fix it and make a new release and move the library forward. We'll do our best along the way to provide an upgrade path or anything and everything and deprecation notices and to be good stewards of the library. But the very, very first comment ... So, one of our contributors open a PR to get the ball rolling. The very first comment was, "Please don't do this." I thought, if you put that in context, what this person is asking is ... essentially, I know what he's saying. He's saying, "Please don't make this breaking change." But at the same time he's saying, "Please don't fix your mistakes. Please don't move this library forward." Right?
John Lindquist: Right.
Michael Jackson: In the end, we have to sort of own up when we make mistakes, we have to move the library forward. We're going to do so in the friendliest way that we possibly can for consumers of the library as it is depended on.
John Lindquist: Yeah, it's so hard.
Michael Jackson: We're gonna fix it. We're not just going to sort of leave things out there forever. But yeah, you do have to take comments like that with a grain of salt. There's empathy that has to be there. You have to say, "Okay, I realize that this person ..." They're saying that because they've felt some pain in the past when we've made changes. I get it. But on the other hand, the future is always brighter than the past, and we just keep learning more, we keep getting better. Software in particular, I don't think is ever really done, is it? There's always something that you can make better, faster, more efficient or some feature that you can add. So, that's just kind of the nature of software and we're doing our best to be good stewards of the software. But yeah, when it does get you to this kind of scale, it does get controversial sometimes, just because it is so widely used.
John Lindquist: Yeah, I imagine the whole process of opensource, you don't think you're gonna ... or you think you're just gonna be coding all day and working on the product itself, but then you realize, wait, I'm setting up some sort of CI build, now I have to ask people to submit tests, I have to manage all these pull requests and do all these things that are just ... well, you probably just want to work on the product itself. Right? And it turns into its own living thing.
Michael Jackson: You know what's funny about the Router code is, it's only a couple of hundred lines. People think like React Router is big. It's not a big code base. It's really not crosstalk 00:07:29.
John Lindquist: So, here's a number for you. You have 505 contributors. Do you think you have more contributors in lines of code?
Michael Jackson: Oh, I'd say probably about the same. Probably about the same. If you took our actual-
John Lindquist: So, you pull one like of code, Ryan's inaudible 00:07:43 one line.
Michael Jackson: Yeah, exactly. We'll just put every inaudible 00:07:46 on one line. I got this if statement.
John Lindquist: That's pretty cool.
Michael Jackson: It's not a ton of code. The vast majority of the work is people work, is communicating with people with the community, with the core React team. The core react team is they're trying to move React forward as well. I was talking about moving the Router forward. They're trying to move React forward. They're trying to introduce some really cool things like async mode, which is something that they actually shipped in fiber, but they haven't been able to turn it on yet. By default, because for fear that everybody's apps are going to break. We're communicating with them. We're communicating with a lot of people. And just trying to kind of set expectations and organize things, and honestly times that I actually get to get into the code of the Router, that's such a small percentage of actually running the Router project. It's kinda funny.
Michael Jackson: It is. I think the difficult part, it's totally understandable, but the difficult part is that, let's say somebody is new to React today. They just want to learn about it. In fact, I was on the phone with someone the other day. He was an engineering manager at a very large company here in the U.S. He has 30 developers on his team that he wants to train. He's trying to get a feel for what this even is. And so, you go out and you Google and you find, oh, React. Well, okay. Maybe React as a good thing. Oh, well, I hear about the Router. And there's also Redux and we should probably be doing our build with webpack. Oh look, you can do a hot reloading with webpack and code splitting. Should we be code splitting? And you get this sort of laundry list of stuff that you want to do it all. So, he was on the phone with me, and you'll go and reach out to a trainer and say, "Can you train us on all of this? Can you tell us about Redux? Can you tell us about webpack and the router and everything else?" My response is always, let's just start with React because React, even without anything else that that comes with it, is actually really, really cool. Like the technology, just the paradigm of React and the way that they did functional programming and the component model and encapsulation and how do we put multiple components together? Sometimes people will say something like, "Oh, well React doesn't have state management built in. And it kind of blows my mind because I'm like, "That was the thing that got me excited about React. It absolutely does. I think the fact that there is so much stuff out there causes people sometimes to overlook just how great React really is. There really is a lot there to know and understand. I feel like if you get really proficient with it, then you can evaluate all of the other pieces a little bit better. Because you'll have a sense of what you've already got and what your missing instead of buying into everything up front and then not really ever knowing what you have. You know what I'm saying? Does that make sense?
John Lindquist: I do, yeah. I think you guys on the Router team have been pioneers for a lot of these newer concepts as far as render props or using components for routing or components for everything. I think it goes along with the pushback that React saw with JSX in the beginning. Like you come up with these new ideas and you get really passionate about it and it's ... I think what you keep on landing on is an amazing developer experience, which by the way, kudos to you guys for innovating in that space. Have you found that that pushback? Do you feel like you need to be an advocate or like, that you're arguing for these approaches or that people have a hard time? Yeah, go ahead.
Michael Jackson: Yeah, as I was going to say, sometimes I do. Sometimes I feel like I need to speak up about it. I feel like the React community is a pretty awesome community. There are a lot of people in the community who either work at Facebook or who are working on other kind of high profile projects in the community. I feel like we've got a pretty healthy respect for one another. And so, even if, like for example, Kent did something the other day with Babel. He had like a babble macro thing that he was doing, a macro plugin. I saw it and I was like, "I don't get it. It looks like ..." I'm programming with strings and he's like, "No, you misunderstood me. What I meant was this, it's cooler than you think. It was like, as soon as he explained that to me, it was like, "Oh yeah, that is cool. You're right." And I was able to, to sort of expand my mind a little bit and learn from him. I feel like everybody in the community, for the most part, tries to do that with each other. Mainly I'm talking about like, you know, people who are leading the community. I feel like we do have a pretty good dialogue and a pretty healthy respectful for another. Where it's difficult, and where I tend to see a lot of the arguments happen is, whenever, 'cause React is so huge that when the broader community gets involved and that's when you get random people showing up sometimes saying like, "Well, I don't agree with this, and I hate this." Most of the time, it's just because they haven't given it five minutes and they haven't really taken some time to let it simmer and figure out why that's a cool approach. The render props thing was actually a really ... it was actually just indicative of this question that you just asked me. We saw a lot of people were using higher order components. Higher order components were very well documented in both the React docs and also in the things like the flow docs and big popular libraries like Redux use higher order components. It was something that my business partner, Ryan and I kind of looked at. And we were just like, "This higher order components thing, it's ..." The first red flag for us was that it was difficult to teach. It was difficult to teach people about that pattern and how to use it and what's going on exactly. And then, there were also just some technical drawbacks, some technical limitations of that pattern. When we saw the render props pattern, which by the way, it wasn't something that I invented. It was something that was ... the first time I ever saw it was in the react-emotion API. When we saw that, I thought, and we just connected the dots and we said, "You know, this is a pattern that really can do ... It can solve all of the same problems that people are solving with the higher order components. So, couldn't we just use this?" And it was like, as soon as we put it out there, I feel like a lot of the people who I really respect and admire in the React community, there wasn't like a backlash, but it was like, "Huh, that's interesting." And then, once it started getting adopted more, I started hearing lots of feedback from people where they're like, "This is actually gonna make typing things a lot easier. If I'm using flow type or typescript, this is actually gonna make typing things a lot easier." I was just talking to Sebastian the other day. He's one of the core committers on React. He's like, "Render props are actually ... We're starting to see some nice downstream effects from that." I was talking to Dominic who's working on a part of the core React team as well. When you're just using these functions, I think it's going to be a little bit easier for them to sort of optimize some things in React core. And now, in fact, there was a proposal by Andrew Clark again on the core React team. The first core proposal that I've ever seen for a core React API that actually used a render prop, which was the new context RFC. That was exciting to see. I feel like we went from a place where hardly anybody was using it to now, a place where, even the core team themselves are like, "This is great. We're seeing good downstream effects from this. Here, let's incorporate this into the core React API." Without too much friction from any of those sort of people, it was more sort of from a community standpoint. It was more like, "What is going on? What is this? Why can't we ...?" I've kind of got like this list of people whose opinions I'm like, "Okay, if this person says something, I really need to listen. I really need to listen really, really carefully because that is very high signal." It's mostly people who have ... they've just proven in the past that they're willing to listen to me and they're willing to be thoughtful about the things that I say. Again, there's a healthy respect there and I think a pretty good dialogue that's happening in the React community, which I personally really appreciate and really have benefited from being somebody who tries to contribute ideas.
Michael Jackson: yeah, like a callback. I feel like that's the equivalent, like in your node code, you say fs read file, and then you give it a callback. What do you want me to do with the contents of the file? Right?
John Lindquist: Yeah, that's another conversation for another day.
John Lindquist: Yeah. So, I would like to talk about unpkg. It's one of your range on projects, which I absolutely love. unpkg is basically a CDN for npm. Now, the presentation you gave at React rally talked about how unpkg can serve up, not just the libraries, but modules and how you showed you could do a React project with, I'm going to use the term zero-config, which has been a term floating around with webpack and parcel and all these things. Do you have like an ultimate vision of what zero-config means and what something like unpkg can do to enable it? Is that ...?
John Lindquist: Better than I would.
John Lindquist: Sure.
Michael Jackson: You know what I mean? That the applications and anything you've ever built on the web was made for an environment where there's a client and there's a server and there's a network and there's some latency. Right now, the way that we deploy our applications, the state of the art is, npm install everything to my local machine, webpack it up, bundle it up, deploy those codes to a CDN. And then, hopefully, they've got some kind of a hash and the file name or something so that the next time somebody hits our server, they can reuse a lot of the stuff ... sorry, the next time we deploy, they can reuse a lot of this stuff from our previous deploy, assuming we've done our code splitting correctly and that we don't have new bundles. I think that there could be some kind of a future where we all just get our dependencies, at least from the network, from unpkg, where we've got a globally shared CDN. So, we can say, anybody who needs react, anybody in the world who needs the React Library to run it on a webpage, whether that pages pinterest.com or netflix.com or twitter.com, they're only going to have to load at once.
John Lindquist: Yeah, totally agree.
Michael Jackson: Maybe even we can go further than loading the entire library. Maybe even we can go and just load individual modules. So, I can say, "Hey." Who was doing this the other day? Oh, the Hyperapp. I think I saw you tweeting about that John. Were you using Hyperapp?
John Lindquist: Yes. Yeah, I was thinking HyperTerminal, Hyperapp.
Michael Jackson: It's like the npm package crosstalk 00:26:55.
John Lindquist: Yeah, Hyperapp. Yeah, the one kilobyte library.
Michael Jackson: Yeah, it's like a one kilobyte vidom thing.
John Lindquist: Yeah, it's cool.
Michael Jackson: Well, I think they say it's vidom, but anyway, I haven't used it a ton. But anyway, I saw that they were ... you literally just put a script tag on your page and then boom, off you go. You're developing, and you're Hyperapp. I actually have a few demos in a repo on the unpkg called unpkg demos. You can go in there, and actually I did a lot of these at the React rally conference as well. There are a lot of different ways that we could possibly use this. You could use a SystemJS, you could use ESM modules in the browser, script type module. You could use, I think I saw a couple of months ago from ... the StackBlitz people released a basically a fully in browser npm client that works on top of unpkg.
John Lindquist: Yeah, I saw that.
Michael Jackson: Which was amazing, right?
John Lindquist: Yeah.
Michael Jackson: The Polymer folks I know are experimenting with pulling things down from unpkg. I've had quite a few conversations with them talking about, oh, how we're gonna load polymer. Polymer I think is actually a really interesting project. They've always been one step ahead of the game, I feel like when ... just with everything that they're trying, the HTML imports and the custom elements and things. I've been really impressed with just kind of that project for a long time. I've been a distant admirer. I think I want to get to know it better this year though. If I was going to pick one project that I would want to get to know better, I think it'd be polymer. But those people, they're already like experimenting with ways to load all of polymer from the network, and that's possible if you ship modules all the way down. First of all, what needs to happen is people who are publishing to npm need to start publishing ECMAScript modules, ES modules. So, CommonJS has traditionally been the bread and butter of npm. That's fine. You can ship a CommonJS built for people who are gonna use your stuff and node, which by the way, I think CommonJS is still the right approach for node. But I think if you're doing stuff for the browser, I think you should be shipping ES modules. Browsers are getting script type module. Once more people actually start shipping modules, then I think tools like unpkg are really going to start to shine in that kind of a situation because it's just a module server, you know?
John Lindquist: Yeah. It's funny to me because if I stop and think about how recent the development it is that client side packages are even available on npm, like when Browserify, I think they were first, I'm not sure. Like Browserify coming out and saying, "Hey, you can actually grab client side stuff off of npm. Have you considered using npm install to install a library?" It was like, "Whoa, that's crazy. Let's do that now." They like, well, maybe that wasn't right. Maybe we should have focused our efforts on the traditional way of just loading off the network. It's one of those Jurassic Park, we never stopped to think if we should sort of things, right?
Michael Jackson: Yeah, no, sorry, I interrupted you there. I was just going to say, I still remember the first time I NMP installed jQuery, and I was like, "What am I doing? npm installed jQuery, what does that even mean?" But yeah, I know what you're saying. We just sort of went down this path, or at least I think I know what you're saying. We just sort of went down this path, well, we're gonna npm install this stuff and then Browserify was like, "Well, what if we built these bundles and I'll give you a couple of shims for node modules that you can use in the browser?" And then, webpack took that to the logical conclusion, which is, you can literally customize anything about your build but we're gonna use a bundler. I think that script tags are cool, man. I think that Command-R to refresh your page. I think that's pretty cool too. I think it's really cool to just have this kind of like nice lightweight way to develop apps. unpkg, the domain name is so short and the URL scheme is so predictable that I don't have to open anybody's documentation or anything to find out what I need to type there. I just say unpkg.com/react or unpk.com/reactdom or React Router or whatever. And I can just really quickly in a development environment type out that stuff and hammer it out. I can put the Babel standalone up there. And now, I've even got Babel and React and React Router and everything right in a page and I can develop something really, really quickly like that without having to worry at all about going and npm installing things and get my build set up and bundling and stuff. So, it brings back this fresh perspective. It's just a way of using the web in a way of sort of being fluent with it that I feel like we got disconnected from with the bundlers and stuff. I'm not trying to dig on webpack. I love me some webpack, is an amazing tool. But I look at the webpack bundles and they're just sort of shores 00:32:38. I'm like, "What's in there?" I'm not sure. Which is, again, that's totally fine, but I do think there's a little bit of a disconnect there. It's a machine. It's generating stuff for machines. When it's time for humans to interact with this stuff, I feel like ... I think maybe that's why I like script tags. I just like to be able to just manipulate my code with my own hands. It feels a little bit more like it's my product instead of ... I don't know. I'm just rambling at this point. You I know what I mean?
John Lindquist: No, I agree. There's-
Michael Jackson: I feel like we kind of lost something when we went away from that.
John Lindquist: I think we're at the point, there's so many loaders and so many variations of configuration options that there's a certain amount of trust that I just put into other people's hands. Taking that confidence and that trust and putting it back into myself where I'm writing the script tags and I know what module I'm expected to load and how it's gonna load and all those things, there's a certain foreign language 00:33:48, there's a certain ownership of that, that I think is kind of lost.
Michael Jackson: Yeah, I agree. I totally agree. I'm not the only one who feels this way. It might be hard to explain, but a lot of the people that I talk to, that's precisely the reason that they're excited about unpkg because it's like, "This feels like the way that the web kind of should have been. Maybe writing your own script tags, maybe that was the right API." Maybe the Bundler API is ... obviously, it's good. It's nice. I'm not trying to say anything bad about it, but what if we could just write script tags and it would do as efficient a job as what the bundlers are doing or maybe even more efficient of a job? Because it's-
John Lindquist: Those browsers, they're pretty powerful these days. I mean, Chrome's an entire operating system known.
Michael Jackson: Yeah.
John Lindquist: They have some features in there that I think we haven't quite fully understood yet.
Michael Jackson: Yeah. Well, and couple that with the power of a truly global CDN. Cloudflare's network is absolutely amazing. I saw a stat the other day, so Cloudflare is the CDN that hosts unpkg. They run 10% of the Internet's traffic, runs through Cloudflare's servers. That number just blows my mind when you think about how much stuff that they're sending. They've gotten so good at it and they are so fast at it. And of course, I can take advantage of that as an individual, right. I'll put my application code in a bundle or whatever and I'll put it on Cloudflare or whatever other CDN I'm using. But if we had a shared place, just one place where we're all going to get our dependencies. Right now, it is the npm registry. That's the single place where we all publish our code and just like GitHub is the single place that we all develop our code. But if we had a single place to actually get the code from when we deploy our apps, I think that would be really cool. I think our apps could get ... man, they could get so fast. I think they could get ... we talk a lot about native versus web. If we were able to deploy these things instantly, just like booting a native app on your desktop, I think that's where we get really competitive.
John Lindquist: Yeah. Bundles can get so big if you don't know what you're doing. And then, if you just take that concern out of that completely, where only your project code is being loaded and everything else is cached, that's pretty fast.
Michael Jackson: I totally agree. You John, you were like one of the very first people using unpkg. I was saying that before we started recording the show. So, thank you. Thank you for your influence. I think you actually took the server down one day, didn't you? Like really early on?
John Lindquist: You're welcome. You are very welcome.
Michael Jackson: It was like the second or third month I think that ... it's been running now for about two and a half years. But I think I remember ...
John Lindquist: You give me something shiny and new and I will break it. I guarantee.
Michael Jackson: I think I remember just seeing this sort of massive spike in the traffic and I was like, "John, is that you?" And you're like, "Oh yeah, I was playing around with it." It's fun to have people like you who kick the tires. So, thank you, I appreciate that. It's hard to break it now, but in those days, I think it was pretty easy.
John Lindquist: Yeah, it's fantastic. Thank you for making it.
Michael Jackson: Yeah, no worries.
John Lindquist: Okay. Let's go ahead and wrap this up. Is there anything you want to want to pitch? Any upcoming trainings or anything?
Michael Jackson: Yeah, sure. So, let's see. So, React Training, again, is my company. That's how I make a living and pay for all the work that I do. We have a few trainings coming up, so go ahead and check out reacttraining.com. In particular, we are going to be in the Bay Area at Nvidia next month in February doing a workshop at their brand new campus, so that should be really cool to go and check that out. They just moved into a brand new building last year, and it's a super big campus. Anyway, go ahead and check that out and a hope to see you there at one of our other workshops this year.
John Lindquist: Cool. Thanks so much, Michael.
Michael Jackson: Awesome. Thanks, John.