Interview with Guillermo Rauch from Vercel by Passionate People

Hello, Guillermo.

Hey, how's it going?

Pretty good. Thank you for being here again. We meet again in Hopin. We meet again as part of one of our conferences.

This is where we live.

Yeah, happy to see you again. Last time we talked, we said let's hope next time we can do it in person, and well, here we are. Let's hope next time we can do it. Yeah. Well, first of all, let me tell you what a great overview of what this hybrid frameworks concept enabled us to do. And I think you saw the reaction in the chat. Everybody is excited about the possibilities that this is unlocking. I wanted to get maybe a quick hot take from, from your side. I think that, well, you recorded your talk fairly recently as well, and you put, as from the looks of it, a lot of thought into it. Are there any points maybe that you said, oh, I wish I've said this additional thing, or this point I could rephrase it maybe for our audience.

No, I actually am really happy with it. I think I strongly recommend that everyone looks at the data. And I think the other thing I always spend a lot of time thinking about is maximizing freedom. I think we've all sort of thought about silver bullets in the engineering world, right? That's what that paper was created years and years ago, the Silver Bullet paper was all about how the author was observing that everyone was always promising a revolution in computing that was gonna solve all problems. He actually calls out visual programming back in the day. Oh, like now if we can forget about code and drag around objects and whatever, that's the silver bullet. And my point has always been that, you know, it's seductive, right? Like, oh, I'll only use this or I'll only use that or I'll delete that and that simplifies the model and it feels good in the short term. Over the long term, you always realize there are no silver bullets. And I think this has been super true over the past 4 years. The important thing I think is that you— 'cause we used to think that silver bullet with Next was server rendering. And then we realized, whoa, there are a lot of merits to static, to Jamstack, to all those things. So what about creating a hybrid framework? So that's kind of like an antidote to the idea of a silver bullet as a framework.

One of our speakers yesterday actually had a very similar point that we, we brought Webpack to the world because it tried to solve the problem of prior technologies to it. Now we see Webpack— well, not everyone, but a lot of people see Webpack as the thing to get rid of right, with ES modules. What are we going to have when we are going to get rid of ES modules, right? So for sure, it is this idea, and I completely agree with you.

You have to always actualize yourself, right? Like, you might think, well, React is a silver bullet, Webpack is a silver bullet, Chrome is a silver bullet, right? So I think we're constantly having to—

Absolutely. And, uh, well, let's not get into browser politics because I had a conversation about that with Sean Wong, uh, and then, well, he had this idea, also a similar concept from PyConf 29— no, 24, I think, when the idea of, yeah, the birth and death of JavaScript, right? And now there's also this idea of, well, something else will come in the future. Now, talking about Next itself, I'm going to start with some of the questions in the chat. I have many of my own. But let's start with the ones here. So well, Photis asks, how do you debug server response time performance in Next.js?

Yeah, so this is a point, uh, that I, I'm gonna use the talk as a reference. It actually makes sense to perhaps not look at that, right? Because like, at the end of the day, what matters to your end user, uh, is I would say probably large contentful paint. The server was a segment of that. Maybe I had an incredibly faster response time And then they loaded a Java applet, you know what I mean? Or a gigantic image or 20 scripts and 4 GDPR popups. And so, I like starting, and this is a methodology of engineering that I've always recommended to everybody in the world, including our own engineers that work on infrastructure or backend or whatever, which is start with the more complete metric and then slice down that metric. So for example, if Fotis uses Vercel Analytics or any other tool and say, oh, this page, large contentful paint is 3 seconds. I love to make that lower. 3 seconds waiting for the hero of the page for this particular page is too much and this page is really important for my site or for my team or for my business. And then you break down into more observability. So To answer Fotis more concretely, I would say, uh, Vercel Analytics will actually capture things like time to first byte, and we actually automate a lot of that. So server responses are pretty fast, but let's say that you have a server-rendered page that is going to, uh, overwhelmed database. So that's where you want deeper tracing into that. And I've used products like Datadog in the past where like they allow me to save traces of my code. And I really recommend those, but I wouldn't recommend going too deep into that rabbit hole if there are other bigger things to optimize.

Yeah, starting from the thing that's closer to what the users perceive as well.

Correct.

Very good technique to do that. Um, Tristan is asking how Next.js applications are bundled with Webpack. Will we be able to one day use other tools like Snowpack or Vite?

Yeah, so Yes and no. So, Next.js uses Webpack as an implementation detail, right? So, in fact, many of the things that when we introduced the framework, we said, well, aren't you tired of configuring Webpack every time you wanna publish a simple page or a set of pages to the internet?

The world even.

Yeah. Exactly. So, first of all, we try to make that not a concern of the framework. right? So when I, when I hear questions about Vite or Snowpack, I hear two very important things. One is, uh, HMR performance. And again, go, going to the point of like focusing on reality, we measure HMR performance, uh, at scale and we care a lot about minimizing it. But again, focusing on reality, we have to minimize time spent on HMR without deleting features, right? So, going back to my point, like, oh, well, I'll get faster if I delete— remove everything, all the analytics scripts. I actually talked recently to a principal engineer at one of the largest retailer websites in the world, and they introduced a bug where they lost their analytics for a week, and that literally resulted in losing a lot of money just because they deleted those scripts. So the answer to this is we're gonna get to Vite and Snowpack-like performance without sacrificing everything that Next.js is doing. So for example, Next.js runs the server rendering code, if you have any, as part of the HMR process, right? So one way that it could make HMR really fast is, well, we won't do server rendering HMR anymore, right? So, we'll get to as close as possible to zero. We have a really good plan. There's a lot that we can skip doing, right? There's a lot of transforms to the code, but I don't think it makes sense to throw away Webpack because I don't see a fundamental shift in, oh, like, if I rewrote Webpack, I'm gonna be faster. I think Webpack can be incrementally improved. And I think Snowpack and Vite are great projects that are pushing us in the right direction.

And we go back to that idea of having these moving targets apparently of what to remove next, right? And probably it's more of how we are using these tools that are making things so bloated or so misconfigured that we get—

Totally. When I think about the developer experience, my largest Contentful Paint matters, right? So like, it's like the largest Contentful Paint that happens after you make a change to the code, right? So you can think of it that way. And then how we bring that down to zero or near zero is less interesting, I think. The bottom line is we have to identify that problem. Again, when I hear people asking us for Vite integration, I think they're basically saying to me, make that HMR trace slower or faster, actually, or bring it down to zero. The other thing that I think is really interesting about Uh, pre-bundling dependencies, I think that's super interesting as well. And I think Snowpack was, uh, doing that at first. I think the idea of a CDN to distribute those bundles is actually really interesting as well. Um, I think you're gonna see us do a lot of that for dev mode first. Mm-hmm. But there's some ideas that apply to prod, like replacing bundles of code to already deployed applications via federation techniques and similar. So we're basically looking at both at this point, which is like bringing—

and I was going to ask you about that. I had a conversation with Tim about federated modules in the context of micro frontends, etc. So let's not necessarily get into it, but, um, this is going to enable a sort of module replacement for production, which is correct.

That's what people want basically when, uh, when they ask for federation. And I think that has a really interesting— there's a really interesting take there, which is the web has been an environment where dynamic code replacement at runtime happens a lot, right? Like, when we talk about a lot of these third-party scripts, like ads, for example, they're always downloading code. They're federating in code from another server, basically. And if the hypothesis that we have is that we need to shift more computation to the cloud, it follows that it should be possible not just for your own team to federate code in, but even potentially for partners and vendors to federate code in as well, provided that the secure sandbox is respected and a lot of other constraints.

Exactly, because of course you cannot have a conversation about federated modules or about the CDN for modules without having, oh, there will be man-in-the-middle things, et cetera.

But that happens for the client side today, right? Like you're trusting that Google Analytics that Sergey Brin and Larry Page are not gonna hack your tokens that are stored in local storage. And obviously there are solutions coming to this, but it's been the Wild West, I think. The web has been the Wild West.

Absolutely. And we were even wilder before.

We're still getting—

we're somewhat better.

We're controlling the wildness.

Yeah. We have one question about if there are any plans to expand analytics functionality into Nuxt. You mentioned it's possible already. You can use it with—

Absolutely. Stay very tuned because because Nuxt is a huge priority for us. 'Cause like a lot of what I say about the component model and React, you can substitute React with Vue and everything that I've said is still true. So Vue for us is an absolute priority.

Wow, that's so cool to hear, especially because a lot of people, when they hear the awesome things that the Nuxt theme is doing and the features that you're releasing, there are a lot of interest in, Well, we would like to have some of those things as well available in Vue. And I think, of course, well, we had this conversation last year about React and Nuxt and Mixteam.

And if I said, you know, just use React, I would be falling for the same silver bullet fallacy that I called it earlier. Oh, like React is a silver bullet. Just go with it. I'm super, super, super, super excited by React and where it's headed. I think it has years of innovation coming. But there are no silver bullets in computing.

Does that mean we'll see maybe a collaboration between SvelteKit and Next.js or something?

It's already happening in the form of, you know, I've had several conversations with our team. We always reach out to be like, oh, we're adding this capability to our network, like maybe you can take advantage of it. Like image optimization is a great example here. If Svelte has a plugin or component or tag or whatever it is for images and you deploy your SvelteKit application over Vercel, boom, images are optimized automatically.

That's wonderful. That cross-pollination is something that it's making the web, well, to move together towards a better—

Absolutely.

There's a question from Anna. What are the benefits that Vercel deployment provides over Azure for a Next.js app?

Yeah, so the Vercel ethos is that infrastructure should be invisible and available to the developer. So in a lot of cases, these things are very powerful, like Azure is obviously very powerful, but it's not really developer-friendly. And what I see with a lot of teams, instead of focusing on those metrics that we talked about, like what is the largest Contentful Paint for my homepage, for e-commerce, or for my item page, or for my content page, they start splitting their time between Azure config hell and solving the problem the user has, right? In most companies that are not in that top 10 of the web that I call the Faguzon, my— and obviously I'm biased, this is like the whole thesis of Vercel. My wager, my bet is that most companies in the world are not gonna have the time, resources, interest in working on that undifferentiated infrastructure. They need to be working on executing on their brand, on their design, on their performance. Yeah, so that's the biggest difference. Like, we could get into more technical details, but they're kind of boring. And yeah, I'd say that it's a team benefit and it's also an individual benefit.

Definitely not boring. I would love to have another 2-hour conversation about that. But John mentions, and I think it's really relevant to it, Sometimes like the deployment— That's really insightful. No, but it's also sometimes outside the—

That's so insightful. And that's what I was talking about. Like if it's out of reach for you to start accessing and tweaking and testing in prod and previewing, then how do you check performance? Like how do you know that the thing actually worked or that, you know, it performs correctly? You can't— it creates a silo for the team, for the developer, that isn't healthy for the business ultimately.

I think that's, uh, that's really, really valuable. Excuse me, that's a really valuable way of putting it. Um, someone in the chat during your talk also mentioned like, I wonder why full stack doesn't always include the hosting story. And right, Vercel's kind of ethos, as you said, well, is deploy, ship, Preview, right? It's the whole package of empowering frontend developers to build really full-stack applications.

I always imagine myself as a waiter that's serving the customer, like the request. I'm the waiter that's gonna serve the request, right? But you have to do that at scale, right? So how do you live right next to the customer that's coming to your website to ask you for something? How do you do that? You have to live literally at the edge of where the customer is. And because you can't look at each request individually, you have to look at the data to inform the next item of development.

It's like when you get a crab sousette and they prepare it so that you see the—

Yeah, here's your largest contentful paint. How does it taste?

And you see the flames going on. Samuel from Storyblok, he asks you, well, do you get inspiration from Nuxt? Are you discussing some features together?

And well, absolutely. We check in very frequently with them. We've gotten a lot of inspiration. You know, some say that inspiration, yeah, is a serious form of flattery. We've taken a lot of ideas from them, most notably around dynamic routing with the file system. They unlocked a lot of goodness there. I mean, there's probably endless things, but that one was huge because that was really well designed. And generally, by the way, I gave a talk around how Vue has been inspiring because the very first version of Nuxt was trying to bring a templating-like language to React. At the end, it didn't work out because JSX became so entrenched. And it's so native and it's become easier to use and TypeScript supports it that it wasn't necessary. But both Vue and Nuxt have been huge inspirations. And in terms of how we discuss things together, we're very transparent with how we evolve the framework. So everyone in the world can learn, not just the Nuxt team, but we also work very closely with them on how can Nuxt customers and users take advantage of some of the innovations that we're putting down in the stack, whether it's incremental static generation, whether it's serverless functions, whether it's image optimization. And from that conversation, they've also suggested amazing ideas to us, like how they plan to make functions even easier to call from the client side and a lot of things like that.

I'm so looking forward to tomorrow's presentation on Nuxt 3 as well to see the advances of some of the features they announced. And between you and me, because, well, the audience is part of this secret group now, after like the Next.js 10 release, I went straight into my colleague Puya, who is head of framework at Nuxt, and told him like, oh, please, we need some of these wonderful features. And he was like, well, we're working on some of them. Stay tuned.

Yeah.

So I'm not going to spoil anything.

I'm not going to say it. There's a lot, there's a lot of amazing stuff coming. So I'm really, really excited. And it's basically on every piece of the framework, right? Whether it's performance, whether it's components and widgets, whether it's the infrastructure for development mode, like everything. Yeah.

Tim mentioned something you're working on. Again, probably don't want to get ahead of myself if you're announcing it, but he mentioned it. So I have to ask. What can you tell us about that script kind of component similar to the image component? Is that something you plan to release somewhat soon?

Yeah, it's exciting because when I showed the iceberg and I confess to everybody that the iceberg should have been horizontal. It became a meme on Twitter recently. I get it. Yes. I felt really bad when I saw that. But most of that iceberg is third-party scripts. Most of the— like, the page is trying to paint and render and fetch your own data. And then it's like—

And your chat widget and your—

Have you ever seen that GIF of the huge Kool-Aid cup breaking into the room, destroying the room? It's like, hey, I'm here. That's what a third-party script does to your page today. Like, Intercom says stop. Rendering the product, stop rendering the sign-up button, the try free button, whatever it is that you're working on that is the north star of your business. Intercom says, "Wait, wait, wait, browser, stop." In one JavaScript thread, right? It's saying, "Stop, load me." So that script loader technology that we're working on will allow you to continue to use all those things. Without— like, it's basically saying to the Kool-Aid cup, hold up, like, let me do this thing. I'll give you your slice, your time to shine.

So, so exciting. One other thing that I'm gonna run and ask—

the docs team is working on it. They probably already are.

Yeah, probably. Tristan has another question. Beyond CDN build and deployments, serverless functions, etc. What are the edge— what are the next edge powers you will add to Vercel?

Yeah, so I mentioned, uh, freedom, developer freedom being like one of the most important north stars for us. So, um, without spoiling much, uh, we're going to give you not necessarily opinionated ways of how your deployment should work Instead, giving you even more flexibility into how the entire lifecycle of the application, the runtime, basically the developer is just gonna have more, more flexibility to integrate with more systems, impact how Vercel caches stuff. A lot of the defaults are so sound, but imagine Vercel let you basically interject in more places of the lifecycle of serving a page. So I'm really excited about that. I'm really excited about continuing to basically expand into new protocols like HTTP/3, like enhancements to basically just the size of the network. And hopefully all of those are transparent to the developer, but our north star continues to be developer freedom.

I just wonder, integrating more benefits from like SWR, for example, correct? It was created by you guys. Well, I, it's just such an exciting future of optimization. Um, I'm taking a look here at the, at the chat to see if there are any other questions. Uh, if not, well, I would like to ask you once again, you shared in your presentation, but where can we learn more about these ideas for the future that Vercel has in store for us?

For sure. So the main thing is we, uh, which is really exciting for me, we have made our entire product evolution changelog transparent recently. So if you specifically want to be on the absolute top of everything that's evolving in the platform, vercel.com changelog, it's a resource that I love. You can actually follow our Twitter account called @vercel_changes. So that's for the global cloud side of thing. And then specifically around Next.js and Vercel, Twitter is usually the best way or following me or Lee Robb, who's here in the chat. He can paste his own Twitter. He's the one that is a lot of this early access to new features and new things that you can deploy and starter kits and examples that we're launching. One of which I'm really excited about that is coming that Lee has been working on. Follow Lee and he'll give you a lot of free stuff that is really exciting.

That's so exciting. Thank you, Lee, for being here. If you can paste your own Twitter, handle as well there. So we can go— well, I follow you already, but the rest of our audience members that don't yet follow you can go and do it. Guillermo, it was a pleasure to talk to you again, especially in this, well, follow-up kind of conversation about where Vercel is going and how your advances are also helping the web advance and move forward. Thank you for being here at JS World Conference 2021. I hope, as I mentioned at the beginning, that the next one we actually do in person.

Yes.

And if not, well, I will be delighted to talk to you once more via Hopin or whatever other platform it is. Thank you again and enjoy the rest of the conference, guys. Thank you very much.