Building Delightful User Experiences with Guillermo Rauch

Welcome to Software Engineering Daily. My name is Mike Bifulco. I'm your host for the day. And today I'm super excited to be sitting down virtually for a chat with Guillermo Rauch from Vercel. If you are unaware, Vercel is the company that produces quite a bit of infrastructure for JavaScript developers on the internet, as well as a bit of tools and technologies that have kind of been guiding and riding the zeitgeist for JavaScript developers for quite a while here. Next.js is part of the brainchild of Vercel as well. And I'm super excited to be able to sit down and sort of pick your brain for a little bit. Guillermo, it's super nice to meet you. How are you doing today?

Great. Thanks for having me.

Yeah, of course. I'm thrilled to get a chance to talk to you. So I kind of like to start discussions just talking a little bit about you first. So I'd love to hear if you don't mind telling me a little bit about your work history and how long you've been building Vercel and sort of what led you on the path that got you starting the company.

Yeah, as you mentioned, we've been working on the foundations and infrastructure for the JavaScript world for quite a while. And that's kind of been my career for spanning decades. My start with programming kind of led to the discovery of JavaScript through my obsession with web technologies. So I kind of wanted to build for the web. I was in love with a web browser and the idea that you could make it more dynamic, interactive, real-time, animated,. And in order to do those things on top of older webpages and the static webpage world, you have to use JavaScript. Nowadays, even though WASM exists, primarily the way to add dynamism to a webpage, to make it come alive, to make it more app-like, to make it more like software is to add JavaScript to it. So my career started with making contributions to different JavaScript projects. The ones that I'm most proud of is In the very early days, it was MooTools. I was a core contributor when I was 16 years old and MooTools kind of was a pioneering framework in many regards. A lot of the folks that were working on MooTools got hired by Facebook to work on FBJS and later on obviously on React. So the DNA of a lot of the technologies that we take for granted today run very deep And a lot of those have been in the works for many, many, many years. So my work history is part investing in all those foundational technologies for web frameworks. I also created a real-time framework for the Node.js world called Socket.IO to enable real-time communication. And I was also very interested in the startup world. So one of my first jobs that was kind of created out of my contributions to MooTools was here in the San Francisco Bay Area and that's where I kind of fell in love with the idea of creating companies and I had the opportunity to, and I saw the opportunity to create a company that was open source first and that created infrastructure to scale up web projects and the engineering teams behind large-scale web projects. And that led to the creation of Next.js and Vercel as a platform to support it.

Yeah, that's really interesting. I feel like in the past, let's call it 10 years, open source sort of had this groundswell of support from the developer community where there's really a moment where the support for devs who wanted to build things open source and kind of share what they were building with the rest of the world became the obvious way to do it because we all get to benefit from each other. And certainly from where I sit, it felt like a welcome change to happen and it's It's really cool to see organizations that are embracing it wholeheartedly. I'm really interested, maybe we can chat about this in a bit, in hearing your perspective on open source and the way it's growing. And maybe even about the federated internet. We can go in all kinds of directions with that. Yeah. So when it comes to, I guess, your current work at Vercel, so when did the company start? How long have you been building it for?

So the company was incorporated in, I believe it was November 2015. I started working on some of my first open source ideas in early 2016, always starting with open source. Open source to me is that way of validating product market fit, right? Fundamentally, and this should be obvious to people, right? It's free. So if you are not adopting something that's free, then you should keep iterating, right? It's obviously such a great deal for adoption. And yeah, so early 2016, the genesis story is super interesting, right? Like I've sold my previous company to Automattic, the company behind WordPress.com, WordPress, and many other awesome projects, now Tumblr as well. And when I left, I knew that I wanted to make developers' lives better. If there's something that I obsess about, it's developer experience and removing friction. A lot of my love for JavaScript, Node.js, and many other things came from like how succinct it is, how easy to get started, how quick, fast. I fell in love with Node when like I saw how quickly it could start up how quickly it could run tests, how quickly it could spin up lots of web servers, et cetera, et cetera. So I left WordPress and I knew that I wanted to have an impact on the web and when I first started creating the landing page for my startup, I wanted to use the best tools available at the time. I was friends with folks in the React team because of my previous shared work history on MooTools. And when I first tried out React, it blew my mind. Like very few technologies have blown my mind. Going back to the genesis of MooTools, we're one of the earliest adopters of Git and GitHub in kind of the open source library world. I have one of my points of pride is I have a very old GitHub account and Twitter account. And yeah, so part of that was realizing that, oh my God, React is gonna change everything. It solved so many gnarly problems I had experienced with MooTools, with jQuery, with JavaScript in general, but even with this idea of reactivity, creating real-time applications would be much easier if the world adopted React. And concurrently in the world of infrastructure, the status quo or the state of the art was Kubernetes. So like every other developer at the time, I was like, "Okay, roll up my sleeves. I'm going to create a page. I'm going to put a webpage online using all of this state-of-the-art technology that has helped the biggest companies on the web scale." And they're being so generous to open source, right? So Google open sourced Kubernetes, which is a spinoff of Borg, which is how they orchestrated containers and millions of applications inside of Google and React was how Facebook was basically turning facebook.com into an incredible real-time application with chat, notifications and infinite scrolling newsfeed and self-updating comments and all these things. But when I started creating that landing page using this state-of-the-art technology, I was like, okay, I've spent weeks just configuring compilers and bundlers and trying to deploy the best practices. And it's kind of like that Simpsons episode where Homer is assembling the little playground for the kids and he's staring at the instructions and he compares what he built and the beautiful picture on the instructions, like building an IKEA. And it looks completely different and his creation looks horrible. Like that's how I felt. I'm assembling React together with Babel and Webpack and Grunt and Gulp and like all these things. And like, I wasn't living up to the incredible promise of those technologies. Like if the output should be that you put out a great product on the web, why is it so awful that I'm just trying to use all this state-of-the-art great technologies and like I can't be productive with them. And that's kind of the genesis that still to this day, we continue to create and bring a lot of value to our customers by helping them realize that they've gotten into traps like that. They've gone to Hacker News or they've gone to conferences or they've read the latest awesome technology and infrastructure as code and whatever. And like at the end of the day, you go to their .com and it doesn't perform well. It doesn't, perhaps it doesn't server render. So they adopted React, but they adopted it as a client-side technology, not truly fulfilling its potential, not truly using it the way that Facebook actually used it. So that's kind of a little trap of open source, right? Like Google puts out Kubernetes and it's, ah, actually it's not quite like how they use it internally. Or Facebook puts out React, oh, it's actually not quite, like internally they have a framework that's very much like Next.js. So that's what inspired that creation of Next.js is like, hey, let's take this engine and let's actually make it work for the citizens of the internet. And ever since then, we've had tremendous success with it. And I was just looking at recent statistics from the Google Chrome User Experience Report and Next.js is now running a really large number of the top 1,000 websites on the internet. And the distribution of traffic on the internet is such that the top 1,000 webs actually amount for a tremendous amount of traffic. So Next.js is running a lot of the web today and we're very proud of that. And we continue to invest in improving the developer experience and improving the server-side runtime execution model. And we can talk a lot about the things that we launched at Next.js Conf with Next.js 13, which we're really happy about.

Yeah, you've touched upon so much in such a short amount of time that I'm sort of gobsmacked by how much has changed really since React came around. But even before that, on some level there was this feeling that I remember spending a lot of my time as a web developer swapping class names for things in the DOM that I had to keep careful control of. And React kind of changed that. It also inverted the model for building things for the web where suddenly you were thinking about the way data sort of propagated. Your applications differently. Very similarly, my sort of prism that I saw Vercel through was that I spent a lot of my life SSHing into servers and dealing with FTP passwords and doing all kinds of nonsense that was like, this was just the way to do it. There was nothing necessarily inherently wrong with what I was doing, but it was the process at the time. And there was this beautiful sort of marriage of developer experience of bringing about tooling that was built for the process that developers use. FTP and SSH are sort of like the one-dimensional view maybe of how to deploy software to the internet and a sort of containerized and graceful software deployment process that came about with Vercel and around the time that you were sort of delivering your first version of your products to the world was like an explosion of capacity for people to get things done. I'm very happy that I no longer have to be the administrator of a single Linux VM anywhere if I don't want to. I think that's really exciting for someone that doesn't want to focus on that. And the paradigm shift there, it really hasn't been that long, but it's such a big change in the way that we deliver things for the web. I think there's a lot to be said for that. And it's really, really interesting to think about even just what's changed since, I don't know, let's call it 2010, just for round numbers.

I love the concept of the inversion that you're talking about, because I see that happening across so many different domains. So On one hand, we inverted the data flow model or the way that we think about UI as a function of data and state. So it used to be that JavaScript was this thing that came later on, you sprinkle it on your page, it has to almost like reverse engineer the state out of the HTML that's been rendered by some other technology that that software doesn't know about. It was this incompatible world. Two forces fighting for who controls the experience. And with React and Next.js, we're saying, okay, the frontend, of course, this is how software engineering should be done. There's a render function, you bring data in and then that system takes over and it's unidirectional, it's clean, simple, it's a pipeline. It's honestly just how most infrastructure even in the real world should work. It has to be smooth and direct. Another inversion I think is that idea of like, what matters more to your business? Is it the frontend experience, which is where the customer interacts, buys, signs up, etc.? Or is it the VM with Linux that you were SSHing into? And what does the customer care more about? Ultimately, what do business stakeholders care more about And even what's better for the web, especially for the web in competition to walled gardens like iOS. Something that I respect about Apple is that they were always about their Apple design guidelines, the obsession with good experience, the giving you frameworks that are not just frameworks for like computer science, like, oh, here's a framework for, you know, how to do data structures, binary search, classes, functions, they do that with Swift, but that came way later. The things that they built that were cool to me were, oh, when you launch an app, it has to have this placeholder state that is instant. Like when you launch Twitter, you get the bird instantly. Oh, that means that the user receives feedback immediately. And then they had frameworks for like, oh, when the application's in the background, it won't consume your resources, but it can communicate with the user through notification. The framework's much higher level and it made for a better ecosystem. Obviously it has all the downsides of a walled garden and review processes and developer licenses and all of that stuff, but good results followed for when you were in that garden. Now for the web, I think that inversion means if you adopt technologies like Next.js that are so obsessed with that user experience, you will naturally just converge into that. You will err on the side of doing more things for the end user, more polish for the application, more animation, more customization, more. The other thing that I love to see more of in the web is more of your brand identity. One of the ways that we've scaled the web is we've said, oh, if you need to do, if you need to go to the knowledge base of this company, go to kb.company.com. Which is run, the front is run by this other third-party system. Your login is not preserved, your brand is not preserved and oh, and it opens up in a new tab and it doesn't preload and it doesn't prefetch. It's like another system. And then we saw that same problem with third-party scripts on the client side. So everything that you want to integrate onto your website comes from a third-party domain and it loads as an iframe or it loads later on in the lifecycle or it's some bubble that is popping up here So we built this kind of disjointed duct-taped things because we didn't have a framework that governed the components of your UI, that allowed them to click like Lego bricks. And that I think is a true revolution that React and Next.js are coming, are bringing to the web.

Yeah, that's a really good point. And the Lego bricks effect I think is something that infrastructure, people working on infrastructure have been really good at for a long time. Making these things that have interfaces on the input and the output side that they're sort of agnostic of what happens on either end of them, but they work really well. And for the web, for a very long time, it was not that way. It was sort of like you have a very fragile deck of cards that you deeply understand how every little card was placed in there. And anything else that comes along is someone with a baseball bat taking a swing at your card deck.

Yeah, it's like Rube Goldberg. There's this super funny meme that there's this guy creating this crazy Rube Goldberg apparatus in his kitchen. And he has to carry it along himself with his hands and all of the ideas that he had for its automation didn't pan out. Unfortunately, a lot of the quote unquote modern web that people thought that they were going for is like that. It's like this disjointed experience, like the CI pipeline breaks down and the npm package is out of date and your DIY framework has no owner because that person left the company. And so we do need to bring some of those ideas of kind of like a cohesive system. We call this at Vercel, the SDK that the web has been missing, the SDK for the web. And yet there's gonna be multiple and maybe you want to change some pieces of it. You wanna substitute React for Svelte and things like this. But overall, the system has to be in harmony to help developers be productive and to help create those high-quality user outcomes.

Yeah, I agree with you there. And I think it's really interesting that for a while the web has purported to be the SDK for multiple screens, right? That phones and tablets and to a certain extent watches and TVs and cars and things like that all are web capable. But we haven't had a really great recipe for building just things generically for for the web. Yeah, there's a lot of potential there and it's a really interesting perspective to have on the way that you're growing your products and the developer experience that people like me get to use. So let's pivot a little bit from there. You've been working on quite a few things at Vercel. Your team has been hard at work delivering things. I know you had an event late in 2022 and along with that came the launch of Next.js 13. Do you want to talk a little bit about the event, the launches that came along with it and the things that your team is thinking about?

Yeah, for sure. So we like to talk about Next.js as that core infrastructure for the modern web, right? And this infrastructure that we give you that you basically have to stop worrying about and building yourself has 3 primary layers. The first layer that gets developers really excited that I think relates the most to the developer experience is the compiler infrastructure. So if you go back in time to like Rausch G in 2016 and that pain that I had creating that landing page, a lot of that had to do with the fact that the story of using React was very DIY. React was this library and then you have to shop for the compiler pieces and you have to assemble them. So Webpack, Webpack plugins, Webpack config, a lot of folks, their first perception of Next.js was, It's like Webpack as a service. I don't have to, I can delegate that nightmarish compiler infrastructure stuff that is really, really hard. And that actually also comes from a perhaps oversimplification or a little bit of ignorance is bliss from how much or how the frontend has been perceived by many people. To create a world-class frontend the way that Google or Amazon have done it, you need to invest in build systems. You need to invest in compilers. You need to invest in optimization, optimizing compilers. It's not the idea that you take JavaScript source and you just put it on the webpage, which is kind of how JavaScript started. That idea is dead. JavaScript has to be heavily optimized, bundled, code split, transpiled before it gets handed to an end user. So we started out using Webpack and you've seen the growth of Next.js, you've seen the growth of React. React is number 2 on all of GitHub by stars. The number of frontend projects has grown exponentially. The number of npm packages and npm downloads continues to grow exponentially. All the tooling that was built for compiling that JavaScript was built in JavaScript itself. So it was all JS-based. So it really cannot keep up with the growth of lines of code, code bases, complexity. So we are taken into this process of moving from JS-based infrastructure to Rust-based infrastructure. So Rust is a safe, native, compiled, safe, from a type safety perspective, language that produces, in our case, obviously can be generalized, but really, really, really fast code, machine code. And what we're seeing is that we created this new project called Turbopack to replace Webpack. It's a general purpose compiler. So any project in the world can adopt Turbopack as the successor to Webpack. To Webpack, but Next.js bundles it in the very same shape that it bundled Webpack once upon a time. And it basically makes everything about the developer experience faster to the tune of we've made benchmarks. And obviously these are synthetic benchmarks, but to give you an idea, it can be up to 700 times faster than Webpack.

And again—

Yeah, no big deal. Yeah, it's astounding. This is measured against projects that are really large. And sometimes developers come to me and say like, "Hey, yeah, that's a great marketing number, like 700 times, but I don't have 20,000 modules or I don't have like 50,000 modules." And I can tell you that working on Vercel itself or working with like some of the largest Next.js users in the world, like Walmart, you get pretty quickly to really astounding numbers. Of files, modules, dependencies, components. So we're turning a world of, that was already pretty fast, compared to when I talked to folks that have minute-long iteration cycles, this is the part of the pipeline that you're entering code into your editor and you're witnessing in real time the UI that you're making. And some folks live in the space of minutes there. I talked to a big, retailer recently that was telling me that they actually had to write CSS and push it to prod, to the staging prod environment to see what they had done. So they're going for minutes, then we went to seconds. Then we went to, from seconds, we already went into this process of moving parts of the infrastructure from JS to Rust. So Next.js already introduced SWC, as a substitution for Babel. And that helped us for many projects go from seconds to hundreds of milliseconds. And now we're going with Turbopack from hundreds of milliseconds to single-digit milliseconds for a lot of updates. It's actually pretty remarkable. And the key thing is that we're buying you a lot of time, right? Like what's happening is that you can now build larger projects Now that dovetails really well into the second category of really exciting announcements, which is in addition to Turbopack, we're moving more and more of the world's JavaScript code from the client to the server. So we introduced the app directory with support for React Server Components. So React Server Components is this new paradigm for server-first rendering. So if you combine that idea of we're moving the code from the client to the server, that means fundamentally that you're taking code that was obstructing your ability to deliver UI to your client and ultimately deliver a sale or whatever it is that your business needed to do on the web, you're now taking that cost. You're saying like, I'm responsible for delivering a fast product. So as your products get larger and more mature, the server can take in a lot more code than a client. It's not bandwidth constrained, it's not space constrained, it's not memory constrained, it's not battery constrained like a mobile device. So by moving a lot of that code from the client to the server with React Server Components combined with being so fast and efficient at bundling that code and refreshing it during development, we're kind of giving you that best of both worlds of great developer experience and great end user experience. So a lot of this, I think it's important to note, especially for folks that have been thinking about Next.js, we're always obsessed with never breaking Next.js. So we still support Webpack. You can adopt Turbopack incrementally with no, basically very few backwards compatible breaking changes. Same goes for this concept of React Server Components. You just introduce a new file system structure into your project, the app directory instead of the pages directory and now you gain all this new benefits of the, basically what's the future of React. So I wanted to circle back to that idea I've mentioned earlier of the way that Facebook used React and scaled it to billions of users, is a lot more like this app directory that we're introducing than even the framework that they open source themselves, create-react-app. So a lot of folks just don't know this, but the version of React that you were getting before was kind of like a diluted version of what the true potential of React was. So the React team has been working for multiple years on incredible advancements like suspense and concurrent mode that allow you to now use React like the big leagues. So another thing that we introduced with the app directories is streaming support. So it's not only that the server and the edge begin the rendering, but the rendering pipeline is basically never blocked. Very complex applications grab data from everywhere in the cloud, right? Like we talked about that idea of like, okay, with the render function, with React, with Next.js, we can get data and state from anywhere and we give you a great developer experience to like create that UI on top of that data. The problem with data is that not all data is created equal and served equal. Some is faster, some is cached, some is cacheable, some data is not cacheable. You don't want your financial, data, your social security number, your bank balance to be cached at the edge. We need to retrieve that from origin. So the new model allows you to stream data that can come from multiple places, have different policies attached to it, different levels of authentication and policy applied to it. And this streaming-based model makes that really not only a great developer experience, but you are actually rendering a page faster. You're rendering the page as data becomes available, which is awesome. So yeah, this new app directory kind of enables React Server Components, it enables streaming, it enables layouts. So this was the most requested feature on Next.js for a long time. And I'm gonna share something in this podcast that perhaps I haven't shared before, but it wasn't obvious feature to add to Next.js. But we've always been really careful to not fall for local maxima and give people something that we know will have to be refactored later. Sometimes it's just better not to have a certain feature than give you a half-baked version of it. So I'm really happy that we're actually introducing layouts together with these innovations in React because I could have given you a regrettable version of layouts years ago. So layouts is quote unquote finally coming to Next.js, but it's coming in the right way and I'm extremely excited about it. Obviously developers again are extremely excited and love this feature. If it's, as the name implies, I guess, it allows you to define layouts, like parts of the page are common across different sections of your application. And it has an ergonomic benefit in that when you develop your page, it's just easier to distribute some of your content components, but it has a runtime benefit as well. So when you're rendering page transitions, we can retain the layout. So essentially it makes your pages more efficient, your navigations more efficient. It's worth calling out too that what makes a great user experience is not just the initial loading time, it's the subsequent interactions. So I think the way that I thought about 2022 as a year is I was very focused, 2022, 2021, obviously other years, but think of it as the journey so far has been to give you a great loading performance. What does that mean? You go to a website, and you get the product page, you get the signup page, you get the landing page extremely fast. And we've done that really well so far, I think. We're creating, we're adding more to that. So we're adding the, as I mentioned, streaming. So if the data was not already, like we can now improve that loading performance, make it more sequential, make it more progressive. We're also adding edge rendering. This started back with Next 12, but we're refining it a lot with Next 13. We're making it more stable, which is that ability to run dynamic code to start rendering that page as close to the visitor as possible. So all of that that I'm talking about is in the service of loading performance, but we're also concerned with the, transition, the interaction, what happens once it's been loaded and you want to buy. And a lot of the improvements that we're bringing into Next.js relate to improving that. For example, with a lot of the innovations in React, we can now hydrate faster. So we can make the interaction time when you press buy a lot quicker. To circle back on layouts, when I transition to a page that shares a bunch of the page, I can make that more efficient as well.

I don't have to rerender the entire page.

So think of Next.js 13 as giving you the state-of-the-art loading performance that is edge-first, that is streaming-enabled, and is fundamentally server-first with the state-of-the-art on interactivity, a page that hydrates extremely fast selectively, and that when you make transitions between pages, retains as much as possible of the work that's already been done. So that kind of sums up our improvements in the rendering infrastructure category, which is a lot. And then finally, the other layer of this infrastructure that you get for free when you adopt Next.js is what do we call kind of the high-level components or the toolkit of Next.js. So we announced enhanced support for fonts, which is, one of the biggest pains by a huge margin on the web. Like I think a lot of folks have that experience of like, you go to a website and the text is not there. It's like, I think one of my biggest pet peeves, period, that because the website is loading a custom font extremely inefficiently, usually from a third-party domain, usually with the CSS is not there yet and whatnot. Or the font is overfit, meaning the font has glyphs that you don't need and variants that you don't need, like bold, italic, semi-bold. I'm a typeface aficionado, but there are folks that go so deep. Like one of our good friends, Rasmus Andersen, the creator of Inter, those people know every in and out of like, the kerning on the font and the glyphs and whatnot. And fonts nowadays come with hundreds of different variants or dozens of variants and so on. And the way that developers have shipped these custom fonts to the web has been naive, has infringed in privacy because now you're going to fonts.google.com when I'm actually going to bank.com. Why do I need to go to Google when I'm loading my bank landing page? So we shipped this pretty incredible component for rendering fonts extremely efficiently. And I think it's also a good summary of the approach of Next.js and Vercel to this problem because the developer experience is literally that you import Inter from @next/font/google. So like you can still use Google's phenomenal repository of open source fonts, but now the dev experience is just like it's one import away and then it gives you back a className and you put your className into your layout and you're done. So fonts, we made images better as well. We continue to improve images. It feels like the history of the web is just improving images more and more and more and the web is made up of fundamentally images, especially with generative AI and DALL-E and all these things that are coming to market. So more native, more web native, we call it internally, image handling, less usage of React, less usage of custom runtime code, more usage of the web fundamentals and the web primitives. And also we kind of re-announced, but we stabilized more our approach to image generation. So you can now generate social cards with a package that we give you. It's a package that you have to import, but it has a very good integration into Next.js, especially with the Edge runtime. So you can basically create images on the fly at the edge extremely cheaply. And these are the social cards that you find all over the web when you share a link on Twitter, you share a link on Slack and you see that beautiful summary card. Well, we can now create those programmatically using React components. So it's pretty freaking awesome. So I think I got everything. There's a lot just on Next.js, but I think to summarize, we predicted at the beginning of 2022 that the web would go edge-first, that there would be a return at that inversion that you talked about, that things would shift from client to server, that obviously developers would continue to demand performance both on DX and UX. And that the web is gonna become more first party. So what does that mean? Like to integrate systems, you're not gonna use a script tags in the client. You're gonna use fewer of them hopefully. To get fonts, you're not gonna go to third parties. To optimize fonts, Next.js serves your images and your optimized images from the same domain. We also, Vercel announced the acquisition of Splitbee to give you first-party privacy-first analytics. So instead of bringing Google Analytics, which is again, third-party domain, banned in Austria, you know, GDPR conflicting Google Analytics, you can use Vercel Analytics powered by Splitbee. So that first-party aspect of the web is something I'm also extremely excited about.

That is a colossal mountain of things to have delivered to the world in the past year. What I like about it is that I feel like for a long time we were optimizing server-side things for a couple of reasons. One is if it takes a long time for a page to load, people disappear. But also Google search engines stop valuing your thing. You start to be devalued from a search perspective.

It's like a death by a thousand cuts.

Yeah, and there's so many things to think of and there's a lot to consider in the way that works. And really a theme that lives through everything else you just mentioned. So the developer experience for build times, the experience of the apps folder and code splitting and using Suspense and layouts and all these things makes the, once the page is loaded, the end user experience better, which keeps people around. So now that the, you know, I've come to your page and it's loaded quickly and it's more pleasant to use, Creates an attachment, and that's something that I feel like is almost just an expectation of the way the apps work in 2023 now because people are so used to installing native apps on their phone, right? They have that experience in a native app, and the web feels more and more capable of delivering native, native plus experiences by the day. I think that's massively exciting.

Yeah, I love what you mentioned about keeps people and makes people come back because it's, as we go deeper into the e-commerce world and become more successful there. You know, like you can use the web for multiple things and you can use Vercel for multiple things, but e-commerce is a big one. And when I talk to the CEOs and chief digital officers of the largest retailers in the US, something they always talk about is that loyalty, that brand loyalty that they work so hard for, that they develop with their customers in the brick and mortar world, in the World of Atoms and beautiful storefronts and avenues all over the world. They've put so much care and so much design. Some of them actually have said things to me that make me think about like, they've had the equivalent of those design-obsessed engineers that we employ that craft custom components on top of headless UI and make it beautiful and choose the gradient and choose a color and choose a font. This is why custom fonts are so popular on the web, right? Those folks were doing that for decades, if not centuries in the real world and they want to do it now in the digital world. And that's why we're seeing that investment into frontend and that excitement over these technologies because what keeps people around and keeps people coming back is a great storefront experience. And to your point, it's not just about that initial, server-rendered time is about A, did you render the right thing? Classic example, is Mike still logged in? Is your cart, your profile picture, is it there or does it come 5 seconds later? Does it shift the layout or was it just there? The product recommendations, are they relevant to you? Into your past history with that website, or are you anonymous again? Or the only way for that company to scale was caching statically at the edge. So they kind of were using edge, but not really because they were just caching the same static version for everybody. So now the recommendations are pointless. So there's just so much about that experience that at the end of the day, it makes that person that visited the website say, you know what, I come back to this. Because it's faster and better. And I think the success of Amazon.com speaks to that. We always talk about democratizing the best practices of the giants of the web with Vercel. And I've experienced that with Amazon. It's fast, so I keep coming back to it.

Yeah, it's fast and thoughtful in a lot of ways. And I think one of the interesting things about this phenomenon that happens when we start to be able to build applications that fulfill and then surpass the expectations of people using them is that if you're doing a really good job at Vercel and I'm doing a really good job building the applications that people are using, they may never notice that I did a great job of building the thing. They just love the thing. They don't think about the loading screen or they don't think about, oh my gosh, every time I come here, I get this error. And you really feel the service that you're getting from whatever it is that you're looking at, whether it's an ebook or a blog or amazon.com. It's a very, very different experience. And suddenly the value you're delivering is actually the value value you're delivering and not like the marginal gains of a slightly faster load time.

Yeah, I think that speaks to the post-DevOps world, right? Like, does the customer really care about that you use Nomad or Kubernetes or Terraform or Terragrunt or whatever the fad of the day is?

Yeah, we've come a very long way from those times and I'm grateful that you and I and all the folks that we work are like, we're standing on the shoulders of a lot of people's hard work to have gotten here. And it's cool to be able to start from where we're at today. I did also want to mention one thing that I admire that Vercel does really well with Next is that you've mentioned actually a handful of things already that are features that are sort of released with Next 13 in a somewhat experimental state. Turbopack being one of those. I think the apps folder is another. And there may be a couple other features that I'm forgetting off the top of off my head that you sort of opt into using that live alongside the prior experience in a way that's stable. I think that's something that's admirable from the perspective of it gives people like me who build with these tools a notion of what's coming and how to anticipate the changes coming down the road. I'm sure on your end, it's also shaking out lots of things that you didn't think of or bugs or tooling concerns.

Getting it into people's hands early has been amazing.

Yeah. My question for you is, how do you manage to maintain both at the same time? So the current state and the future state.

Yeah, great question. So there is a, there's a Hacker News thread that I have a very unpopular opinion about that has become kind of a meme and it became super popular. It's a comment that someone made about how Oracle has so many tests that the core database that Oracle builds has so many tests that it's almost impossible to to work on Oracle. And obviously I'll take out the part about making it impossible to work. That's not a good property of any system, right? But I truly admire systems that have extremely high quality test coverage and testing is an art and a craft. When all of this is done, I think I'll be remembered for, it's funny 'cause a lot of people point out a tweet that I made that is like, "Write tests, not too many, mostly integration." And articles have been written about this tweet, it's funny, which is funny to me. But the idea there is like, hey, you have to test the end, as close as possible, the integrated experience of your product that you're delivering to people. You have to test it from the point of view of its usage, ideally. And sometimes of course implementation details like security, we have a dedicated testing suite for security and things like this, but we always try to holistically test the system. So secret superpower, secret sauce of Next.js is just how thoughtful we've been about its testing story. So we move with confidence, we evolve with confidence, we can replace parts with confidence And that's, for example, what gives me the confidence that I'll be able to completely replace Webpack with Turbopack. There's also a gain of incentives. Sometimes you have to be thoughtful. And this again, just like tests of art and science, it's not that the best tester is the one that reached 100% code coverage at all costs. And no, there's Economics, there's how much time you spend, there is understanding of how the product is used, et cetera. And I think that same thing applies to breaking compatibility. Like it's not that like the best system is the one that never broke compatibility. I think folks also talk a lot about how Windows kind of went or Microsoft went a little too extreme with backwards compatibility. And I think you can be a good steward of an open source community and project and bring people onto the journey of the future with removing or crafting or warning and thoughtfully deprecating. And that's something that we pay a lot of attention to. And fundamentally, I think that, for example, from Webpack to Turbopack, it'll be super seamless. Another funny thing is that we've been working on that transition without people realizing. So for years, I've been, And nowadays, I of course delegate this to our team and our CTO, but I've been super thoughtful about, okay, can we start minimizing footguns of configurations or plugin hooks or things like that? Or can we prevent their existence at all? Such that then we can replace Webpack with something else. And those thoughts go back to possibly 4 or 5 years. So that's another quote unquote trick is that we've been thinking about the future without even being able to write the code yet because writing this massive amounts of Rust code is not trivial nor fast, but we were preparing the architecture for it. So that's one way that we, bring kind of this seamless upgrade experience or backwards compatibility. And we celebrate it internally a lot. We collect tweets when people tell us like, "I upgraded from..." And sometimes it's jokes or it's funny because we're like, "How were you so out of date for so long?" Like, "I upgraded from Next.js 1 to Next.js 13 and it didn't change anything." We've gotten tweets like that. So the key thing to, so the second category I spoke about, which is like the rendering infrastructure side, the app directory, that is completely optional opt-in and a lot of benefits are still there when you upgrade to Next.js 13, even if you use the pages directory. You can use the fonts improvements, you can use the image improvements. There's even DX improvements that we bring sometimes to the table. That apply to pages. So there's never, we work really hard to never give a reason to developers not to upgrade to a major version. The changes are usually very minimal.

Yeah, it's interesting to see on launch day, the excitement that comes from the new features launching and like the groundswell of information that seems to propagate across places like Twitter and YouTube while people are watching these things. And then this kind of realization that like, oh, you know, my upgrade process, so my personal site is built with Next. My upgrade process for that I think was maybe 8 lines of code to be compatible from 12 to 13. And it was, I had to remove nested anchor links under the Next Link component.

And there's a code mod for that.

Yes, right. It was a very thoughtful thing to do, yeah.

If you run the code mod, you can append to the link component an attribute called legacy behavior if you don't actually want to change the code. And then there's a code mod for actually changing the code. So yeah, I love that. And this is a space that I'm really excited about because I think AI will help tremendously. It's already helping by the way, just more like ad hoc, not fully automated, but the idea of migrating code with AI is just, So exciting to me.

Yeah, I think we'll see a lot of exciting changes come in the next few months here and years as AI sort of hits its stride here too. So Guillermo, I really appreciate you taking the time to hang out and chat with me today. I have hours and hours worth of additional questions I could ask you, and I'd love to follow up with you sometime in the future. For now, I'm hopeful that you will have lots of exciting changes coming about this year as well. But where can people find you online if they have questions follow-up, things like that, and where can they find Vercel and Next.js?

For sure. So on Twitter, I'm @guillermo_rauchg, R-A-U-C-H-G. I strongly recommend following the Vercel and Next.js accounts. In particular, over the recent weeks, we've been tweeting out a lot of very short videos that help you understand and break down some of the concepts and improvements that I've been talking about today. So huge fan of that. I also recommend checking out nextjs.org/learn if you're interested in picking up Next.js skills. We added a recent addition to that, which is the fundamentals. So we kind of take you from not all of JS, but we tell you like, okay, what do you need to know about JS to React and then from React to Next.js. It's kind of like smooth journey. We teach you how to deploy as well. And if you're thinking about larger and more ambitious enterprise-grade projects and things like that, I recommend checking out vercel.com and vercel.com/enterprise. But even like you said, for your own blog, like my own blog runs on Vercel, your blog runs on Vercel. So we make it extremely easy to deploy frontend projects of 35+ frameworks. So it's not just Next.js. You import your Git repo onto Vercel and we take a lot of pride in how quickly we can deploy that. And we deploy Astro and Solid Start and SvelteKit. I'm very excited about SvelteKit 1.0, which just launched. So yeah, head to vercel.com and start importing your projects.

Wonderful. Well, Guillermo Rauch, thank you so much for coming on today. It was really great having you here. I'm looking forward to chatting again sometime in the future. Thanks again. Thank you, this was great.