Ben is joined by Kyle Mitofsky, a Senior Software Engineer on Stack Overflow’s public platform; Kelsey Hightower, Principal Developer Advocate at Google Cloud; and Guillermo Rauch, cocreator of Next.js. They cover what’s new in Next.js 13, how growing demand for front-end applications has made the React codebase “ginormous,” and what’s required to support a sustainable community of open-source contributors.
We talk about how Next is bringing image components, server components, and in-house analytics via split bee—and bundling them all together with Turbopack, powered by Rust, our Developer Survey most loved language of 2022.
Guillermo Rauch is the CEO and cofounder of Vercel and cocreator of Next.js, an open-source React framework that helps developers build fast, lightweight web applications. The most recent version is Next.js 13. You can find Guillermo on LinkedIn.
We previously talked with Guillermo about the security risks of laziness, how Next.js mixes static site and SPA functions, and the front-end trends that get him excited.
Kelsey Hightower is the Principal Developer Advocate at Google Cloud. Find him on Twitter or GitHub, or read about his very personal history with Kubernetes.
Kelsey has also distinguished himself on our podcast before.
Kyle Mitofsky is a Senior Software Engineer at Stack Overflow. Find him on Twitter or GitHub.
[intro music plays]
Ben Popper Hello, everybody. Welcome back to the Stack Overflow Podcast. The episode today was recorded at the Next.js Conference in San Francisco back in October of 2022, but we thought it was a great conversation between Guillermo Rauch, who is CEO over at Vercel, and Kelsey Hightower, who is a senior distinguished engineer at Google. They talk about a lot of interesting stuff involving the future of the web, where Rust fits into front end development, and how to balance innovation, open source, and corporate governance and contributions to big things in the ecosystem. So enjoy the conversation, it was recorded kind of live so you’ll maybe notice a bit of that, and let us know what you think.
[music plays]
BP Hello, everybody. Welcome back to the Stack Overflow Podcast, a place to talk all things software and technology. We are coming to you live from the Next.js Conference in San Francisco. We just wrapped up a big day of announcements and we are lucky enough to be sitting down with two distinguished folks from the software industry, Kelsey Hightower, distinguished engineer at Google, and Guillermo Rauch, CEO of Vercel and co-creator of Next.js. Both of you, welcome to the program.
Guillermo Rauch Thank you. I'm excited.
Kelsey Hightower Happy to be here.
BP So we had a lot of big announcements today. I think the one maybe we should start with is just the updates in Next.js 13. You and I chatted a little bit about this yesterday, but moving to the edge, moving more to the server side, making the client thinner, not having all that JavaScript shipped that way. Why did you make those changes and how do you think it'll impact developers' lives?
GR I think one of the key themes for today is just how much front applications are growing, how much demand there is on the front end side, and as folks move toward running lots of experiments, running lots of tests, putting a lot of the logic on the front end side, going and starting personalizing their experiences a lot, now we're seeing this React codebase is getting ginormous. So putting all that code, all those permutations of UI in the cloud near your data, and unblocking the ability to stream it from the edge, making our applications faster, making the client more lightweight, that's kind of the big thing for today.
BP And Kelsey, what were you excited about from the announcements that you heard today and some of the fireside chat talk?
KH Yeah, I think that whole trend, because I think the big idea really is that if you start to treat the web like one big computer, you start to want to do this kind of paradigm that we're seeing in Next.js 13. And so this idea that the browser is the end-all be-all for client side things, well that's just a small view of the web in general. But now when you step back and you treat this whole thing as just one big tiered computing architecture, it starts to make sense. And then I think the thing that makes me super excited is how easy it is to use it. As someone who spent time in the Ruby On Rails world, that whole convention over configuration deal where you just put things in the right directory and you sit back and say, “Go,” and all the things go to the right layer, that's a game changer. And so for someone who really respects infrastructure who knows how complex it is, when I don't have to do it it makes me smile.
Kyle Mitofsky Yeah, absolutely. Layouts RFC now getting polished, it's just the way my brain works on a particular level. One thing we've seen is this kind of tug and war between HTML and JavaScript over the last decade. JavaScript wants to eat some of the things that HTML does. I think there's this quote, I'm going to butcher it, but any sophisticated enough JavaScript framework is just going to rebuild the browser in JavaScript. It's like, “Why do that? We have HTML.” And I think one of the things that was exciting to me, and maybe Kelsey, you can also talk about this, is with the image component and the font component, being able to go reuse some of those HTML browser native capabilities, even though we're shipping this thing in JavaScript, that's kind of a build step to get you to the right outcome, but we want to ship the right HTML, let that be easy, let the browser do some of that work. How do you see that being used inside these components? What's the trajectory there for your stake at Google and the web?
KH I think it's a huge sign that the maturity of the web is the fact that it's been so backwards compatible for so long. And I think there's been some experiments to try to change that. We saw Macromedia Flash where we thought we could just get away from that altogether and just create experiences that way. But it turns out there's that combination, I think it was said during the fireside chat, we're dealing with both things at the same time. We're presenting information and we have to deliver experiences. So no one's going to be happy with, “Here is your driver's license number.” No, I want to unveil your driver's license number. And so that dual responsibility of what these platforms deliver, information and an experience all in one, I think that's why it's that way. So I think HTML as a container is cool because sometimes that's all you need, but then having the situation where you can actually inject experience, not just data, not just small bits of functionality, but actually experience and those little divs or those little containers you decide, I think that's the part that makes this all super exciting that now you can actually have, to me, I feel it as a canvas or collaboration. I might set up the data container and then call out to someone else to generate the other part of that experience.
GR Yeah. Why I'm excited about the introduction of React Server components today is that we can say, “Okay, this code runs in the server. This code runs at the edge.” But then you can augment it with that idea of delivering experience, so that's when you bring in client components. So the fact that we now have a technology, and I think unlike the Ruby On Rails example we were just talking about, that is so universal in the runtime. I have access to the same APIs, I have access to data, and I can choose where I invest. Is this all server components or do I also bring some client side interactivity? And I don't leave the framework. I don't have to step out of my comfort zone to do that, and we can create a rich ecosystem of reusable components around this. I think it's a huge leap forward for what React has been able to do. I think it's primarily around architecture, and it's a better way to architect your codebases.
KM And maybe just for listeners who aren't familiar with the client component, server component distinction, can you just elaborate on what those two are and how they fit into the Next.js pipeline?
GR Yeah. The other tug of war that we've seen in front end for years is, now is this a single page application, meaning I have to ship all my code to the client? Or is this only a server rendered application? And these are things we could do with Ruby on Rails or PHP where I server render and I give HTML to the client, and at most what I can do is use HTML attributes to add some interactivity in the client. I think with React and with the idea of a React Server component we can say, “Now okay, this component will do data fetching on the server side. It'll be secure. It'll allow me to have all these permutations of how I'm going to present my content loaded in the server, and I'm going to have a very thin client. I'm not going to ship a lot of JS to the client, but if I want to bring in some of the capabilities that single page applications have, they're available to me.” One that I like to mention always is when you create a Next.js application, we do a lot to make it such that out of the box, the page loads really fast. We talk a lot about the web vitals and that idea of the Largest Contentful Paint happening in under two seconds even in very slow devices. But what about the subsequent interaction? What about when I tap? This is something I love about native mobile apps. All the taps are instantaneous, at the very, very high expense of you downloaded a huge app and you have a lot of state on your client, but all the taps feel really good. So Next.js kind of gives you the best of both worlds because it's able to hydrate that application on the client's side. Now all the links are instantaneous. We have prefetching built in, meaning that we'll try to scan what hyperlinks exist within a view port and start prefetching those so everything happens fast. But then the developer can decide, and I'll give you an example from YouTube. As you navigate throughout YouTube, if you were playing a video, that video kind of transforms into this sticky video that now is picture in picture at the bottom right of your screen. And now the client is super stateful because it's almost like you loaded an application. YouTube is a good example of something I can create quite easily, of course with a huge amount of engineering to become YouTube. But that idea of, I send you a YouTube link, I want that video instantaneously when you first load it, even if it's cold, meaning you've never accessed this site before. Your cache has gotten evicted. You just got a new phone. We're going to make that first YouTube load really fast, but then you get this super rich client-side experience and that's where you combine client components and server components to make this thing happen.
BP So let's talk a little bit about the Turbo side of things. I know that this came out of an acquisition and we got the chance to chat with some folks earlier who had helped you build this, but you had mentioned to me that in some ways this is about maturity. There's 3 billion downloads of this, and you're not going to write a AAA game in JavaScript. Let's try Rust out and see what it can do. When did you make that sort of architectural decision to try a different language? I know it's very beloved by programmers. It's always at the top of Stack Overflow’s most loved languages. And what do you think it's going to unlock for that next generation of web and front end development?
GR Yeah, as I was mentioning earlier, I think it's been unprecedented to see just how much code folks are adding to this application, just how much the front end is growing. So when we first built Next.js it was on top of Webpack, which was JS-based. That was the bundler that allowed us to stitch code together and deliver it optimally, not just to the client, but we used Webpack to be able to create very precise and lean functions that we can deploy to the cloud on Vercel. So bundling has always been this fundamental engine of the evolution of the framework, but as the code bases grew, especially with the rise of TypeScript and CSS in JS and other technologies like it, the JS-based tooling like Webpack and Babel and Terser couldn't keep up. Just too many lines of code, too many files. There's this meme of, you open node modules and it’s the black hole of the universe. You've seen it, I'm sure. But that's for a good reason. It's just that this community is so prolific, and the NPM ecosystem itself is growing exponentially in terms of publishing and downloads. So by switching to Rust, essentially we did two things. First, we looked at architecturally what would make our codebases truly scale. And what we realized is that we needed to switch to an incremental architecture, meaning the work that you've already done in a huge codebase will not be repeated when I'm sitting down at work again on the same application. And the insight we grew out of this acquisition is a technology called Turborepo. So Vercel bought this company called Turborepo. Essentially what Turborepo does is, if you have a huge repository of code with multiple projects, imagine if every time you pushed code, you rebuilt every single one of your libraries, your front ends, even your back ends. So of course you don't want to do that and you want to say, “Okay, I'm editing my front end called ‘store’. And I'm not going to rebuild blog if I didn't change a file inside the blog directory.” So you can think of Turborepo as a way of orchestrating builds in large monorepos of code. The way that you can think about Turbopack is that same engine and idea but applied to the more granular problem of bundling and compiling and transpiling JavaScript and TypeScript code. So first we said, “Okay, that is a winning architecture. Who wants to do the same work twice? Nobody.” And then on the other hand we realized that even with the right architecture, JS could not keep up with the demands that developers are throwing at it. So we decided to move to Rust, which can do the work, and we proved it, by the way. In an early release of Next.js, we replaced Babel, which is the thing that transpiled JS and TypeScript, we replaced that with SWC, which is a Rust-based alternative to Babel. And the change from that was incredible. The performance improvement that that brought was incredible. And that gave us a lot of confidence that if we switched to Rust to do this very predictable transformation of inputs into outputs I would say, yes, the JS and TypeScript ecosystems move fast in terms of adding syntax and things like that, but it's a problem that Rust is extremely well suited to do.
KH Yeah, I mean, I'm coming from the Go world where the whole language was started because people didn't want to wait for long build times and large distributed codebases. Google was famous for having a huge monorepo, and we built tools like Bazil to try to solve this problem. I also think, and even though it wasn't explicitly called out, having infrastructure like this on this side of the town, you can start to address a secure supply chain problem. Where are these modules coming from? Is this image compliant? Did you have a license for this image? I don't hear a lot of people talking about this stuff today but it's a very real problem. So when we think about software supply chain, all of these assets come from somewhere and there should be an accounting record of it. We don't eat food without looking at the back of the label. If you're allergic to something, you don't do that. And so I think this sets the foundation for that next level of maturity. Where is this stuff coming from? Because if something is known to be bad, then at least we have an alerting system to go out and say, “Hey, if you're using this kind of technology, if you're using this build process, then those SHA256s that were generating these hashes, we can go and tell you that module is bad and you probably want to rebuild and you probably want to upgrade.” So to me, I think it's fascinating to see that this idea of propagate reproducible builds, and reproducible builds leads themselves to faster builds because you now can actually prove that something's already been built so you don't have to build it again.
GR That's an excellent example because something that emerged in the Next.js community and the Webpack world was because the technology couldn't keep up with such a large number of files, we started putting too much trust on the supply chain so we wouldn't transpile whatever was inside the node module directory and you had to explicitly call it out. So with the introduction of Rust-based tooling, you can grow your own repos of code where you can vendor dependencies if there are dependencies that you need to have a lot more scrutiny over. Imagine crypto code. You can put it in your codebase. You can process it every time you make a change. And you can do this fearlessly because you are not at risk of your development workflow getting slower.
BP I don't want to bring up a touchy subject, but there was one other announcement which was Splitbee and first party analytics versus third party analytics from whatever company you might be getting that from. I could think of a few. What do you think the advantages are for developers on that first party analytics side? I myself had to deal with some headaches around GDPR recently so I know this personally from our side. But GDPR and what else do you think is important about the Splitbee announcement?
GR Yeah, so we bought this company, Splitbee. Two fantastic founders who were already a part of the React community. In fact, they created one of my favorite libraries, React Hot Toast, which is used by lots and lots of folks. But their thinking was quite simple. So they're from Austria, one of the first countries to deem that some analytics were illegal there. And the idea was, “Okay, can we create something that's very focused on real time data and is very focused on utility rather than tracking private details about visitors,” and a lot of that was in the service of making better products. The reason it's called Splitbee is that the vision was, “Can we bring the idea of ‘I'm running split tests’, ‘I'm running A/B tests’, ‘I'm running experiments’, and bring that into the desk of the developer to sort of evaluate their next move, and make this very data-rich product engineering life cycle happen.” So that was extremely well aligned with where we're seeing the React world going, first of all, with the introduction of React Server components. We think that when a developer upgrades to Next.js 13, they're going to be able to experiment fearlessly. They're not going to have to worry about all this overhead of, “Everything is static,” or, “I'm shipping too much client-side JS.” So the acquisition of Splitbee fit really nicely into that. And then there is the fact that I want to get insights about what's happening with my app, and I don't want to in exchange have to render a cookie banner, or I don't want to slow down my application because I have to include this third party script that is going to download a bunch of JS code just to report some stuff to some other cloud. To us, this idea of giving you that feedback loop of what's happening in your product just feels completely essential to the modern developer flow, and we wanted to bring that into Vercel.
KH And it's not surprising to me. When you think about your car, it also gives you feedback loops because it's closer to the machine. iOS has Screen Time and gives you analytics about how you're using your apps and how you're using them in which way. So I think for most frameworks to be successful, there's a level of insights that only the framework can give. And so the closer you get to that framework, you may start to provide framework specific insights that are just hard to do as a generic concept.
BP Yeah, I think you make an important point there that that would give developers a certain level of trust and confidence that they can own that for themselves. I want to ask one more question, but if you have anything you want to say on the Splitbee analytics side, I'll let you do it.
KM Yeah. I just like the idea that it's one more thing that's given to you for free on that platform. There's this decision fatigue of picking all the right best of breed particular things, and not to say that this is or isn't best of breed. Boy, if I'm one click away from knowing how many users are on my site at one moment in time, that's really powerful. We're all server rendered, and so when we do A/B testing it always happens on the server for us, and so sometimes it's a little wild to me to think that people are doing A/B testing on the client. They're shipping two JavaScript bundles on the client, letting the client do the coin flip and figure out who's going to do it. And so the idea of that is very much aligned with server components of bringing this backwards in the stack, letting this happen earlier, shipping less JavaScript, I think is a very exciting part of bringing that in-house.
BP Cool. So the last question is sort of in the same mold as what we were just talking about, trust, is about open source. I know both of you work at companies that have huge open source projects that have developed into very popular languages and frameworks, and there were some questions today during the fireside chat about how you balance being at a company like Vercel or Google with Rust or a Golang. So I would just love to hear your thoughts on that. What's the balance of upstream and downstream that pushes the technology forward the most, while also maintaining the trust of the community and allowing them to contribute and feel empowered?
KH I think people underestimate what it takes to maintain something for 20 years. I've had some small libraries in the Go community, some larger projects in the community, and a single person trying to do this stuff on the side for free on the weekend, that's tough. And look, I might do it for five years, but I may not be willing to do it for 20. And so the other part of that equation is that there has to be a community, one that's willing to be sustainable. And so the thing that's also hard is, should I let a random person take over these libraries under my namespace? Who are you trusting in this instance? So to be sustainable, you actually have to have the right resources. And a lot of times, I don't know about y'all, but I like to get paid for the work I do.
BP Not coffee and a tip?
KH That's not going to cut it all the time. And there's other things too, and I think these days you need a logo, you need marketing because you're competing with other frameworks, but then there's liability. You can't just be shipping software without thinking about the security concerns and all that boring stuff most people don't want to be involved in. So when we think about healthy open source I think the split is, the amount of stuff that we're getting for free from these projects is astonishing. You still have the fork button. I think that is a big point of the community to keep everyone honest. And so if a project starts going too far in the wrong direction the community can always stand up to take over that responsibility as long as they understand what they're signing up for long term. So I think it's been in the best interest of all the big projects that I've been a part of to have even your competitors collaborate on the same thing and compete at the layer that's actually hard. That combination of hardware and software is really, really hard. Getting that reliability is just tough. So I think, honestly, open source has been the fastest way to experiment with new ideas and propagate them. And if you're responsible enough, you can back them.
GR Yeah, I love that. I see that the job of Vercel is providing extraordinary services for developers. And when I think about that I think about collaboration, I think about our workflow, I think about the front end infrastructure itself. And ultimately our platform is an open platform that is agnostic to what is the open source framework that you're using on a given day to solve a specific problem. So we back Next.js because what we've realized is that our wedge into the market has been to give you that combination between software and hardware. So if you think about the infrastructure as hardware, what is the software layer that best works with it? But also being mindful that there is many different kinds of software that is useful and we can run and that continues to proliferate in the open source community. And one of the things that we've been able to do, to your point about folks that are working on exciting projects but need more support, is we've hired a lot of these open source maintainers. So we contribute to React and Next.js of course, but we also contribute to Svelte, and we hire folks that contribute to the Vue community, and we create APIs on the infrastructure side that help those authors make their frameworks more powerful. So that idea of the symbiosis between the infra, or you can almost think of it as client serverless architecture, I like to find those opportunities where we support open source but we also have services that will help large companies, small companies, and even individual developers.
[music plays]
BP All right, everybody. Well thank you so much for listening. And thanks to Guillermo and Kelsey for coming on. I am Ben Popper. I'm the Director of Content here at Stack Overflow. You can always find me on Twitter @BenPopper. And if you like what you hear, go ahead and leave us a rating and a review. It really helps.
KM I'm Kyle Mitofsky, a Senior Software Developer here at Stack Overflow. You can find me on Twitter @KyleMitBtv.
GR I'm Guillermo Rauch, and you can find me on Twitter @RauchG.
KH I'm Kelsey Hightower, distinguished engineer at Google Cloud. You can find me on Twitter @KelseyHightower.
BP Awesome. Thanks, y'all.
[outro music plays]