[00:00:00] Introduction
Guillermo: we're obsessed with customer experience. We call ourselves the front end cloud because we propose that teams start building front and first. Start with the customer, start with what you want to deliver, start with how fast it is, how dynamic it is, and then work backwards into the technology.
Andrew: Hello, welcome to the DevTools FM podcast. This is a podcast about developer tools and the people who make them. I'm Andrew. And this is my cohost, Justin.
Justin: Hey everyone, uh, we're really excited to have Guillermo Rauch on with us today. Guillermo, uh, you either directly or indirectly have really impacted a lot of the work that Andrew and I have done over the years, you know, be it your early development work working on things like Saki. io or obviously now the work that Vercel enables, The webpage for our podcast is hosted on Vercel and sponsored by Vercel, which we appreciate.
Um, so we're really excited to have you on. Before we dive into the questions, would you like to tell our audience a little bit more about yourself?
Guillermo: Hey folks, I'm Guillermo and the founder and CEO of Vercel and the creator of Next. js. And I'm really happy to be here because I love DevTools. And what Vercel does is provide developers with the best possible DevTools to build the fastest and most personalized web experiences on the internet.
[00:01:17] The Evolution of Guillermo's Career and the Birth of Vercel
Andrew: Cool. So, uh, you, before Vercel, you had a long life as an open source person. Uh, you'd had a lot of really cool projects. You were the creator of socket . io. I was visiting the new tools page and I saw your old picture with, yeah. With, with your emo haircut, fun to see. Uh, so from those days.
Guillermo: yes, I was 16.
Andrew: Oh, wow. Yeah. So from those days, how did, how did those tools and ideas shape where you went with your career and where Vercel is at today?
Guillermo: It's funny you mentioned Socket. io because a lot of people still get surprised that I created Socket. io. They say, holy shit, the Vercel CEO created Socket. io and it is surprising to me even in that, like, I didn't start a company for Socket. io. Like that thing became so popular, I got lucky in that I, I think I hit really good timing with a open source solution for building real time web applications. Real time Everything has sort of been the calling of my career. If you think about what we do today at Vercel is really making everything real time, like make the deployment process feel real time, iterating really quickly on projects. Socket. io was amazing because I was able to give the world a solution for something that everybody wanted, which was create this real time applications that are like chat, like interactive, et cetera.
And they couldn't do it at the time because web browser support was so lacking. So I kind of filled a very interesting niche of you want to build the future web browsers don't support yet. So you need a developer experience that bridges the gap. So I learned a lot from that project. And one of the big takeaways was when I introduced socket.
io, The hello world example was seven lines of code, and I kept code golfing it to just make the thing really easy to understand. So you could create a chat app or the back end for a chat app in like seven lines of code, and people still love it for that reason. It's just so ergonomic. The developer experience is so great, and Motos was very similar too.
So if you think about jQuery and why projects like that became so popular, kind of the same pattern, right? The browser lacks some APIs, or they're super clunky. What if we created a developer experience on top of that and distributed it as a library? So, yeah, those were a huge inspiration for me as I, as I thought about creating Next.
js Vercel. you know, make, saving, saving developers lives, saving developers time in their lives, I think, is one of the most important things we can do for just like overall productivity, quality of life, creating better products. Thanks. Unleashing them into the world, but also I think the other thing that I couldn't do with Sakura at the time was Can I create an infrastructure business on top that not only makes it easy to create things, but then for businesses, it gives them some ROI.
It gives them a return on investment. Like if I buy this thing, if I give my developer this tool, it makes my business better in a measurable way.
Justin: So besides those projects, besides like Mutool and Socket. io, when you're thinking up to sort of like the lead up of founding zeit and then Vercell, like what was the sort of like pivotal projects in that journey,
Guillermo: One huge pivotal moment for me was realizing that we had React in open source. It was, uh, I call it sometimes like the discovery of like a fundamental physics for developers because before React it was really hard to collaborate and share units of work, we'll call them components for the sake of this conversation. And when I sat down to actually create something with React, that's when using investment terms, like I saw Alpha 'cause. You have React, it's amazing in theory, but you want to put it to use, and the meme at the time was you need to take a, get a PhD, and you've seen those funny photos of like a huge blackboard.
That is like a hundred times the size of the person writing on it. And there's all these equations, like creating a project with react felt like that and going back to what I was good at, right? Like with things like socket IO and mood tools, I'm good at creating a developer experience on top of systems.
That are very hard to get started with. That would be the kind of the in democratizing those systems. So another metaphor I give people is react was like the discovery of a new awesome kind of engine, right? Like the steam engine or a Tesla electric engine. But what most people want. Is to get from point a to point B with a car.
And so next day, I sort of filled the need of like, here's your car. It's going to get you places. It has an engine and some people are like huge fans. Like they get into the weeds, they pop up the frunk and they look at like, okay, what's in here. Um, most people don't really care as it turns out, especially as you go into like higher and higher levels of the kinds of companies that we talked to today.
The reality is that they don't care that much about like each knob and each gear and each piece that went into constructing that engine. But more and more so people are becoming aware that they need to make their developers productive. And that hiring software developers is how they're going to actualize their businesses.
Especially for the largest companies in the world. And so we kind of, uh, I was able to create a technology that kind of satisfied both needs. And, uh, yeah, turned out pretty well. But I mean, embedded in a huge way to Meta, open source in React and, uh, Google open source and a bunch of other cool things like Kubernetes.
We can get into the infrastructure side of things if you want. Uh, but yeah, building an open source was a huge part of what makes it successful.
Andrew: Yeah, I can see that theme of making a complicated, tool simple with like, the first product I knew from ZEIT, uh, now, you just run now at your CLI and you get something pushed to the cloud. so since those days, uh, the company's changed a lot. It's got a different name, uh, a few different products.
Like the first thing I actually associated you guys with was a terminal of all things.
Guillermo: That's awesome. I was just tuning my terminal yesterday and I was like, terminals are freaking awesome. And that's why we started that project. But it was a total side
quest.
[00:07:40] Ad
Andrew: We'd like to thank our sponsor for the week code crafters.
Code crafters makes programming challenges for experienced software engineers. If you're looking for a weekend project that takes you to the edge of your programming abilities, you got to check them out. Uh, I've, I've worked through a few of their challenges now. Uh, I've done the builder on Reddis, which was a fun introduction. I leveled up to do the build your own get, which was a much larger challenge.
One of the cool things about code crafters is not only are you learning to do some programming language better and learn about some modern tool. You're also learning how to like sift through their code, sift through their docs, learn about their protocols and really get to the bones of how these services actually work. I haven't started it yet, but my next challenge. For the last leg of this sponsorship it's to try to build my own SQL light. On the podcast.
We've had lots of companies and products come on that are built around SQL Lite and all the cool things that it enables. So I think it would be pretty cool to get to learn how it actually works.
If you asked me learning, like this is way better than grinding on some leak code, you actually would get to build real skills and have fun while doing it.
Besides the content, even these are experiences targeted towards experienced software developers. For example, instead of trying to tie you into a custom in browser experience to edit code code crafters, let's use your ID and your terminal. So you work as you normally would. Push up to code crafters, they run the test and they tell you if you pass, you asked me, it's pretty cool.
Just try out code crafters for yourself. Visit code crafters.io/dev tools. Dash FM. There you'll get a 40% discount and you'll be helping out the podcast a little bit too.
That's not the only way to help out the podcast. You can become a paid member. If you become a paid member, you get access to our episodes a little bit early and you never have to hear any of these ads again.
If you want a sponsor dev tools, FM, head over to dev tools.fm/sponsor to apply. And with that, let's get back to the episode.
[00:09:33] Vercel's Vision: Democratizing Web Development for Ambitious Projects
Andrew: So how would you explain the company Vercell to someone who doesn't know anything about it right now?
Guillermo: Yeah, I think every business today is becoming a digital business. That's like what we all agree upon. Right. And becoming a digital business is actually really, really hard. Even though there's things like the cloud and AWS and like all this amazing open source knowledge, doing something at the level of the giants of the web, like Amazon, Google meta is extremely hard, but that's today's battlefield.
If you're a competitor of Amazon, like how do you get started in this world? Like deploying a massive storefront at planet scale, that's really fast and personalized and ever improving. So we want to democratize the tools and infrastructure for businesses of all sizes to be able to get to that level of proficiency and excellence.
So Vercel is a platform for folks that have very ambitious ideas. If you want point and click. Drag and drop and build a website for a restaurant? Vercel might not be the perfect fit. But if you're thinking about doing something ambitious on the internet, and when I talk about ambition, for example, Next.
js, our open source framework powers chat GPT, and it powers like actually a lot of the generative AI companies and, uh, a lot of the best storefronts in the world and nike. com. And so I'm really happy that we've been able to kind of find a good balance between ease of use, but also there's basically this infinite ceiling of how big you can get and how big you can build with our technology
Justin: how has the vision of the company sort of changed over time? So what was it like when you like started? Did you have kind of an inclination of where you wanted to land or like, how has that evolved?
Guillermo: Yeah, it's a really good question because vision for the technology wise, it actually hasn't changed that much. I sometimes go back, one of the cool properties of Vercel is that you can time travel to everything that you've deployed going years back. So I went back to like our earliest landing pages and I clicked let's see the deployment for this landing page.
And every time I read that stuff, I'm like, almost like impressed with myself because I'm like, wow, you were spot on. Like, I think, um, for now the product that you called Andrew, we called it at the time. Real time global deployments was one of the first taglines. And, and it really hasn't changed that much.
Like one of the things that we do really well today is that we allow this large merchants or huge companies to like launch globally, which is really hard, but it was very feature based at the time. I think this is probably the most growth that I've experienced personally as a leader of this company is.
Being able to actualize the messaging and make it resonate with more kinds of buyers, other kinds of developers, other kinds of architects, engineers, decision makers. So I think that's the biggest thing is like the vision never changed from a technology standpoint. We wanted to unleash this really fast tooling, this really great developer experience onto the world, uh, take all the pain away from creating and scaling infrastructure.
But today I give you sort of. The ambition of creating the best products. When I talk about what we do for you, and then we can get into the how, and I think that's a really healthy thing as the company grows because we change and adapt our tools. Today is Next. js, but for example, we also added through an acquisition, we acquired a company called Turbo. Turbo repo is a way of orchestrating large monorepos of code for really, really large builds. And we didn't start with that and it didn't quite fit that tagline of like global deployments in some ways turbo comes before the application framework, but it is in the same vein of like, here's tools that the giants of the internet use.
Like companies like Google, I think Google has the largest monorepo in the world, like billions of lines of code. And I wanted to democratize that technology. Now that technology, again, it's a point solution in the service of you create amazing experiences on the internet, amazing products for your customers.
I think when I say keep reflecting on like what truly makes us different as a company and as a group of people on a DNA level, is that we're obsessed with customer experience. We call ourselves the front end cloud because we propose that teams start building front and first. Start with the customer, start with what you want to deliver, start with how fast it is, how dynamic it is, and then work backwards into the technology.
Andrew: Yeah. Through that lens, it makes a lot of the things that you guys have done recently and make a lot of sense. So like one joke you might see about, uh, Vercell on Twitter is that they just wrap services. But that is exactly what you're saying is that we want to wrap these services so that. We've democratized them and make them easy to deploy for anybody.
Cause like on Vercel, I want to run on the edge. I just export a variable. Oh, I want to have a Postgres database, key value store. Oh, right there, right off the shelf.
Guillermo: Yeah, that's a really good point. That's exactly how we architect. So first is what do you need to solve? What experience do you want to deliver? And then we work backwards into the how and we abstract out the how from you so that you don't have to worry about it. So you, you hire us to do that, that sort of legwork.
Um, and you judge us based on the experience. And by the way, the more we build out, the more I realized that we have to double down on this idea because the things that actually grow fastest that we put into the market and are most successful start that way. And then as they mature, as they get more usage, we can optimize them based on actual customer feedback. So every day I tell myself, keep building new things like we built this entire company. Even though now our infrastructure is like, has seven years worth of work. If I'm building something new, I start with like, all right, developer experience, customer experience. Then work backwards and iterate in public.
Justin: Yeah, I mean, that's such a powerful concept. And I think that, um, one of the things you, I mean, Vercel has become a big topic in the industry and there's a lot of people that talk about it. I mean, to your, to your credit, one of the things that you don't hear is that, oh, it's a bad experience. Like, that's not something you hear.
Like there are things that people will always complain about, about anything, but like the experience is not something that anybody, you know, You know, has anything to say about. So I think that that, like what y'all have accomplished with the, the sort of just onboarding experience, the ease of development, the DX and everything is really powerful. I want to transition and ask you a little bit of a different question. So, so you said you're, you're like front end first, you're, you're like focusing on that first customer experience and working backwards. And that makes a lot of sense, especially considering some of your hiring decisions. So one of the things.
that, you know, folks on Twitter had talked about kind of early on is you've hired a lot of people who work on these core frameworks. So you have Rich Harris on staff who works on Svelte. Uh, you have Sebastian on react. So what is your thinking around the, the hires in that area and like the framework levels?
Guillermo: Yeah. One of the key things for us is that even though we've seen tremendous success with Next. js. When I think 20 years into the future, I think about, you know, we'll be building the best tools for the job, whatever it takes. So as I mentioned earlier, it's about creating the best developer experience for the things that they need at the given time.
And we've always been a multi framework, multi runtime company. In many ways, and this is an oversimplification, but if you've never heard of Vercel, using the famous Y Combinator X for Y explanation, we're like, AWS for the front end, right? And that means that you have to be, if you, if you have that kind of aspiration, you have to be very versatile.
You have to be very open minded about what solutions, what languages, what technologies you support. So Svelte is a really great example of a completely different take. It's not React, it's different syntax. It's maybe you can call it like signals versus, uh, re rendering or effects or whatever. and we wanted to have that point of view inside the company so that we can build the infrastructure that this frameworks connect to in a very versatile way. So the infrastructure has to be very flexible to serve the needs of as wide of a range of possible of people that want to build this way. So notice that we call it front end. We do a lot of back end things, which sometimes like maybe throws people for a loop, but the thing is that when you build with Svelte, when you build with React, when you build with Next.
js, when you build with Nuxt, you're building the customer facing part of the experience, and that's where we want that flexibility. And then we want to build infrastructure that perfectly serves the needs of both the end users. So of course, when you go to like UnderArmor. com, it has to be really fast.
Thanks. But also we see the community of framework creators as our customers as well. So we support like 40 frameworks, I believe, out of the box. So by getting the inputs of Sebastian and getting the inputs of Rich, we're building the best possible platform.
Andrew:
[00:19:11] Embracing React Server Components: The Future of Web Development
Andrew: so recently, uh, you guys have been working towards a pretty big goal of React server components. Uh, I've read on Twitter that like, basically you guys. Are the people who invested in it and it's why it's really even a thing. So as a company, why did you guys think that RSC was the right bet to make?
Guillermo: Yeah, it's a great question because I created Next. js and I had a lot of influence. Over the design of the pages router. So to replace that is like killing your baby. You know, like I love my baby pages router. And I honestly do, like we've done incredible things with, with it. If you think about all the companies that we've served, one of the things that used to be really hard for, um, I think for the internet in general, but for, for Rocelle was the customer built something, they launch it and he needs to scale to like Unknown amounts, amounts of traffic, and it has to be very efficient.
With Pages Router, we did more than just create a developer experience. We created a framework that had this novel integrations into cloud infrastructure, like ISR, that allowed people to scale to the tune of like, we went from like zero to tens of billions of requests per week as a platform. And a lot of that IO to the fact that we created great integrations between Next.
js and the cloud. So it's more than just. You get good feedback when you develop locally. When you deploy, you're orchestrating this global footprint of services and caching systems and, and functions and serverless and other things. So the framework worked really well, but it had a lot of really important limitations as I saw us going from that initial customer base to even more demanding software applications. So particularly one of the things that we did well with Next. js Pages Router is that we gave you a model for what we would call like hybrid static and dynamic pages. Next. js So the workload could be backed by a headless CMS, for example, or some e commerce API. And then when we render, we can push that page to the edge.
And then when the content changes, we can regenerate it at a runtime. That was very important in our competition at the time with Gatsby. Gatsby was fully static generated, worked really well if you had 100 pages, Went over that and all of a sudden, like it just doesn't scale. But even our framework for the most demanding applications, the most dynamic, most personalized applications in the world was also too static. And what it resulted in was You had to use a lot of client side JavaScript in order to actually deliver on things like A B testing, feature flags, advanced personalization. Think of even what merchants are doing today. Like you go to Amazon and then AI summarizes all the user reviews. So that level of dynamism required us to basically forego a lot of the assumptions that we put into the framework.
For example, the entire page gets hydrated. Every single component has to get hydrated. All at once. The fact that data fetching happens all in one function and you have to decide if the page is entirely static or entirely server rendered. So we needed something that actually kind of did what Next did in that competition with Gatsby, but again, although this time in competition with ourselves. In some ways, I think what's really interesting is that the biggest competitor of AppRouter is PagesRouter. And it's weird because it's coming from the same vendor, but it's actually solving for all the pain points that we experienced with it. And sometimes I think what happens is that folks are not yet at that level.
They haven't really seen the problems that the framework creates down the, down the road. So it might be like, Oh, maybe I'm just okay with pages router. And that's totally okay with, because we still support it. But some of the things that we experienced ourselves at Vercel with the limitations of pages router, actually what's directly.
Influencing the adoption of react server components. So one of them, one of them that comes to mind is, um, our, our marketing website is built with next JS and our cloud console is built with next JS. When we want to do things like experimenting on a small portion of the page, next JS pages router makes you almost go back to the thing that next JS was trying to get rid of, which is you go back to a create react app in a fully client client rendered application. What we saw is that, you know, that has a tremendously negative impact in your Core Web Vitals. It actually makes engineers, and this goes even into like why Vercel exists, it makes engineers more fearful about experimenting with new ideas. One of the things that makes Vercel really special is just how experimental we are, and how many things we try before we put it into the hands of customers.
With hundreds of flags at any given time, that inform different new experiences that could be launched, or could be killed. So we, we found that the previous version of our framework was kind of inhibiting that fearless evolution, fearless dynamism of the experience, and we needed something better. And I think React Server Components is amazing because it's the first time that I've seen a comprehensive solution to that problem.
And it's exciting for the open source community because going back to that idea of like Google, Meta, Amazon, they have internal versions of this. Amazon, for example, is very famous for they stream the experience. Like I always like showing people like if you zoom out and you go to the product detail page of Amazon, you can see it coming to you in chunks.
And what's fascinating is that to the end user almost feels like a static page. That's how fast it is. They think it's cached. So that's kind of what I, I am, my ambition for the, for App Router and React Server components is. Thanks. It's so fast that you think it's the entire page was already computed for you and it's in some cache somewhere.
In reality, it's being assembled and streamed on demand for you. And the content is exactly what you like. Uh, if you're a logged in visitor, what you've seen recently, your recommendations, what he left in the cart, things like that. And those are the things that again, really move the needle for the kinds of people that are building this sophisticated sites.
Justin: So now that y'all have, I mean, you've been working on the sort of react server component integration, especially into next for a long time, what are some exciting examples that you've seen of it?
Guillermo: Yeah. So the very first company that comes to mind is wop. com. Uh, they refactored from pages, writer, app, router, and yeah. They were one of the earliest adopters of the framework. So they had not yet, um, they basically took a chance on it even when like, I believe it wasn't even stable yet. And what they told us is like, it kind of blew my mind.
Like doing like tens of millions of dollars in revenue through this faster version of their storefront with a tiny team. In fact, the, the fact that a startup could build something so complex, so dynamic. And put it out and just start receiving all this revenue kind of blew my mind. It was kind of that idea of like, can I give the infrastructure to people of what rivals amazon.
com, but democratize it for the rest of the world. So it was, it was, um, it was amazing to see, uh, early on. another thing that's really exciting is our most successful customers have already migrated to app route or in the process of migrating to App Route, and this is with us, again, giving you all of the options.
You can stay where you are, you can adopt app router, but typically, as people mature their applications, they start hitting the limitations of pages, router, and, uh, want to embrace, uh, re server components. Another thing that comes up a lot is. It used to be impossible to sort of maintain the stability of your caches as you make releases.
So, um, let's say that I'm caching some content comes from a CMS and in the old world with ISR, I would push it. For example, with CacheIt, I roll a new version of my site, all my caches are gone. So one of the very exciting things that React Server Components solved for us is this idea of decoupling the cache of the content and of the backends from the actual page rendering.
And of course today you can still cache the entire page if you want, but the fact that we have this sort of like several layers After the page begins rendering is making it such that deploying doesn't take away from sort of what you've been building up until that time. So it means better stability for your back end.
It means deploying more fearlessly because you're not sort of hurting the existing experience umm Generally speaking, it's been exciting to see how everybody's adopting it for new projects as well. Figma. com, for example, just migrated from, interestingly enough, Gatsby into the Next. js app router. So it's always awesome to see.
To me, something I've always felt really proud of is, The companies that I respect, the tools that I use, the folks that I want to work with using our tools, right? And so Stripe launched their Black Friday experience on the Next. js App Router, Figma. com, a lot of awesome websites are adopting it and, uh, and we continuously improve it,
Andrew: Yeah, the, the app router is really interesting. It just allows you to craft your code in such a different way. Like the thing that one of the tweets from you that made it click for me was somebody was like, what's the equivalent of like get static props for, for this. And he's like that you're just like, that's it.
That's, that's the whole thing. You can use that. But at any point in the tree now, and I think that's just so simple and really
unlocks a lot of cool things.
Guillermo: And you know what's funny? That was the, that was the top feature request for so many years. So something that's been great about react evolving in this way is that we'd get all this feature requests and we literally could do nothing about them. So when we launched get static props and get server side props, People would say, awesome, I want exactly that, you nailed it, but please give it to me on the component level. And I was like, well, there's almost no way I can do this. Layouts is another great example of, we've been, people have been asking for layouts for so many years. And we didn't do it for so many years because we couldn't find a way that it would be sustainably implemented. We knew what was coming ahead for React.
We knew that, for example, suspense based data fetching was coming. So we, we had to be very careful in how we added to react so that we wouldn't get in the way of its development. Get initial props, get side props, and get server side props were awesome innovations because they sat, they sat outside of React.
They were like, okay, React, like now you take over. And in that way, Next. js Pages Router was a very collaborative player. So we route with Next. js, we do the initial data fetch with Next. js. And then we hand it off to react. What's happening today is that. It's React itself that needs to fetch the data. In order to create those very dynamic streamed experiences, React has to say, okay, now I have to fetch some data, or, if it's not available, I have to give you the skeleton.
So I flush and I stream the fallback, and now I continue down the tree. Oh, I need some more data. Maybe I can fetch it from the cache. Maybe I render, I stream it to the end user. So, um, in a nutshell, It's been amazing to see that React is taking more of the burden of what we needed, and in many ways couldn't implement.
And now Next. js can sort of be, it's It realizes full vision,
Andrew: Yeah, in practice, it kind of just makes the whole API melt away. It's like, I don't, I'm not really caring about like using next JS APIs to get my data. I don't really have to make API routes. That's just, that's just part of my app and it all just kind of fits together.
Guillermo: Yeah. I remember a conversation I had with, uh, Seb at one point and I was like, it's almost like he made me realize that creating an API and creating a react front end, we're almost like two products. So if you think about, think about what comes to mind when you think world class API, you think, well, like.
Stripe and their awesome documentation and how they authorize API calls and how they manage rate limits and observability. That's actually how you create a world class API product. And then you create a product experience for an end user. What Next. js almost asks you to do is to partake in the journey of creating two products, even when your intention was to create one.
So most people need to create just some application on the web. If we ask them to create an API, we're now asking them to create another application. And that comes with security implications. They have to like, think about how to secure an API endpoint, which will get exposed to the entire internet, how to document it, open API specs, and so on and so forth.
And then they need to worry about implementing their product. So to your point, it feels like the present is just very streamlined.
Justin: Yeah, I feel this really strongly in my time at oxide is like thinking about the API is like the entry point of the product was like a really strong motivator. And it is like, it's a very different mindset when you're crafting a big API. And we kind of see, and I like next chess has really helped drive.
This is like, we see, like, Originally it was like, oh yeah, we'll either server side render the whole page, you know, really old school style, or, you know, we'll break it apart and we'll do a spot on an API. And then it like kind of got a little bit closer. It's like, okay, now we're building back ends for front ends.
And the model like scaled really well. Cause people realize it's like, they were just building APIs because it was like the thing to do. It's like, oh yeah, we need an API for our service.
[00:33:26] The Evolution of Building for the Web: From Monoliths to Modern Approaches
Justin: And then the APIs would. Because they just build it for their UI or whatever. They were the only people consuming their API.
So it is nice.
Guillermo: That's actually one of the biggest pain points at Vercel that we felt is when we had to create very bespoke APIs just to make one front end experience better. And we talk about this all the time, like, if I were to start this company over again, I would just start it with the app router. I would, you know, talk to my data layer in the most streamlined way possible.
Because really what you're looking for in the early days is product market fit. You're not looking to create a API and then this front end and this SPA and the customer doesn't care. So you need to get to market really fast. And that's what I'm excited about with this. To your point, it's almost like a return to the old way of building, but we're bringing the future into it. So it feels a lot like Ruby on Rails in some ways. which is how Shopify built into this magnificent business and GitHub built itself into a magnificent business and so many other examples and yet it addresses a lot of their shortcomings. Right? Like when I navigate GitHub, they retain no client state. Everything is this turbo link thing. They need more streaming, clearly. Because sometimes it takes 10 seconds to go from page to page. Whereas it could be very incremental. It doesn't feel like a spy. It doesn't feel like instantaneous. Like that feeling of a single page application that is already downloaded. On the other hand, you'll talk to those engineers and they'll tell you that's the most productive they felt in their entire career. Uh, they call it a monolith. I reject the premise that you need a monolith. I think what, what people really want is a monolithic way of building. I don't think they care that it's deployed into a 64 core bare metal 4xl instance in AWS or what, like it's an actual monolith, right?
Like a mainframe, like an SAP app or whatever. But the experience of building has to approach a monolith. It has approached a monolith in the data fetching code, like, when I show people the code of react server components that looks like PHP, they're like, holy crap. Um, like, yes, thank you, but also why are you returning to 20 years ago?
And that's when we need to explain, no, no, no, but we're bringing the future into it. Um, and yeah, so, I, I, some people get frustrated about the pendulum swings. But I've never seen the industry fully pendulum swing. It's not like we're building exactly like we're building with php right? We have this rich client side model now.
We have interactivity. We have optimistic states. We have an entire ecosystem of client side libraries and components, et cetera, but we did have to reclaim those benefits of the, I think DHH called it the majestic monolith. I think monolithic DX is what people ultimately want, and I'm very happy to sort of be contributing to delivering that to people.
Andrew: so you, you mentioned earlier that like the way you guys build for Vercel is you set out with like a product vision, start at zero and see if the platform can support you.
[00:36:45] The Future of Development: Generative UI and AI Integration
Andrew: Uh, recently you guys have been experimenting with AI a lot and releasing a lot of like new AI features and libraries. So like, what's your vision for Vercel in the AI category and what do you guys plan to provide developers?
Guillermo: Yeah, in two words, our vision is what we call generative UI. We believe that there is a before and after with this LLMs in their ability to generate code on behalf of users. And this LLMs are actually particularly amazing at generating Tailwind, JSX, HTML, those kinds of things. So we created V zero, which you can think of it as a generative UI design tool.
You go in and you paste a screenshot or you talk to it and you generate ui. This is a, this is designed and conceived such that you save like 90% of your time. I don't believe, and there's a lot of chatter on Twitter about this, that like, we're gonna replace software engineers, but I think we're gonna massively augment them with generative ui. And as we were creating this. We completely dock footed Vercel V zero. And if you want to check it out, it's visual dev uses reacts server components for streaming. So as you, as we generate the UI, we give it as a client, very important because AI's are pretty slow, especially when you have to do a lot of pipelines and very complex products.
So you have to be able to render stuff as it becomes available. The other thing is really interesting and why reacts ever components got created is. As the name implies, the server could have tens of thousands, millions of possibilities of components. In the conversation I talked about, you can have feature flags, you can have variants of components. And the client doesn't need to download a bundle that contains every single one of them. For example, the client doesn't need to download components in languages that it's not interested in speaking, right? So, with React Server Components, we're able to actually create a product that not only can fetch from lots of different components, can even generate them on demand.
So we dogfooted React Server Components, uh, Vercel KV, Vercel Postgres, Vercel Postgres. This is an example of how we build our platform itself. We build products on it as first class citizens. From day one, Pure Vercel. And along the way, one of the things that really stood out to people was this ability to, the LLM responds with something, and we can stream it to the client.
And this stream is not just text, like ChatGPT does, or Markdown. We could stream any kind of visual and interactive Representation. So recently we open source sort of the backing technology of the zero, uh, into what we call the AI SDK. So the AI SDK allows you to create your own generative UI experiences.
Imagine you're Robin Hood and you're creating a stock trading AI assistant. And you want to say, what is the price of Apple? An old school sort of old school from a year ago, an old school chat AI app, would you say? The stock of Apple is, well, first of all, they would tell you the stock of Apple is, I don't know, because I'm an LLM and blah, blah, blah. The AI's most recently gained this amazing capability called function calling. Now the AI can respond with like, let me call a function to get the price of Apple. The thing that Vercel has open sourced now into the AI SDK and is giving the world is the ability to not just call a function, but call a component. So we can grab the price of Apple. We can use react server components. We can inline the data fetching. So we can say, go and fetch the stock price from some stock API. In the meantime, we can stream a skeleton or a suspense fallback. So we can give the customer a really nice user experience. And then we give them the chart of the price of the stock over time.
So we're basically democratizing all the infrastructure for you to go and build your own generative UI experiences. And I think this is going to have a profound effect into assistance that people build into their existing applications. Thanks. Um, support experiences, a company called clar not recently talked about and it went viral in the internet about saving 40 million by automating all of this repetitive questions that we're getting from customers.
And the other thing that I'm really excited about is that I talked earlier about how, unless you're Apple, Google meta reinventing yourself online has been really difficult. Think about, I don't know, PG& E, a company in the U. S. that, uh, you know, has a website, but they don't have as many engineers as MetaDos, and they're trying their best, and like, all of their world has kind of, has kind of become online first, overnight.
Or think about banks that used to work with, like, branches, and people walking in, and now they're, again, like, digital first company It's very possible that these companies will never get to the point where they build something as good as Instagram. com and they'll just leapfrog creating some of that more than more of that traditional software with forms and lots of clicks and navigations, et cetera.
And they just ship AI experiences. So I'm really excited about what generative UI can do for the folks that are kind of struggling on the internet. Uh, another example I always think about is that mobile has been a nut that has been particularly tough to crack for most companies, there's like 10 or 20 native apps that we all use.
And then there's a long tail of companies that wish they had an app, but getting the Swift developers, the Android developers, the react developers, the Shipping on three platforms is really difficult. But if you can ship a AI experience, because I open pgne. com and I'm like, I don't know why my bill is 300.
Please help me. Or my, my electricity just got cut off. I didn't get a notification. Please help me. So I think there's going to be a very long tail of user interactions. that people are not going to solve with traditional software UI experiences. They're just going to leapfrog to AI. And hopefully this technology can help people get there.
Andrew: Currently the SDK, like only streams components you define though. Right. So it's not like a full V zero, like, Oh, I asked it for weather and then it generated a full weather component for me with all the data fetching.
Yeah.
Guillermo: even know you
had that. That's kind of by design, by the way, because there's risk with like AI just creating like Imagine that you're Nike and we stream Adidas by mistake, right? So even the brand experience has to be carefully curated, but I do think that's next, right? Like, I believe we can tame these AIs enough That they can create completely novel results.
Because ultimately what matters to you the most is the data, right? Like the data has to be accurate and accurately represented. The other thing that you want to infuse is your brand aesthetics and identity. The way to think about that is that that's almost like the system prompt, your colors, who you are, your values, like, I don't know, like at Vercel, we like minimalist, dark things, right?
Like that's kind of like my system prompt. I do think we're going to get to the point where V0 and some of it's fully rampant. Generated, uh, capabilities can also be safely embedded into the AISDK in the meantime, what people can do is sort of work on like permutations and or base components and then give some more freedom to the AI to call into them.
And then a good example here would be a comparison table. You have a more, more of a generic component. And you can invite the AI to use it. So instead of just rendering text, the AI can say, well, now I can use a component here. Another way to think about it is, You could produce diagrams on the fly where the SVG is completely generative by chaining two AIs together.
You have the function called first generate the real component to which it passes the properties and the properties are dreamt up by the AI. And then the other component uses another AI partition, another model. So this model kind of lets you do ensemble of AIs. Which is another thing that we discovered in the production of AI for, um, for vZero. Most AI products at scale today, like little known fact, perhaps, are ensembling models together. So if I go to chat, I don't know if chatgpt does this, but I know that a lot of chatgpt like products do. And I say, um, I paste an image and I say, get me the strings. There's an optimization that you can do by routing that to a model that's good at that task. Translation is another example. Translate X to Y. Maybe I don't need the full power of the most powerful model that's out there, so I can route it to a more inexpensive model. So, what's really cool about React Server Components is that, in a way, they're also a great orchestrator of asynchrony. In this, AI flows are very hard to actually write code for because sometimes they have to, for example, plan 10 steps.
And execute them in sequence, or they need to call three AIs in a row in order to produce a result while they're giving the customer feedback. So the AI is the case, not just generating UI, it's also letting you orchestrate this more complex flows of data.
Justin: It's a really, it's a really compelling use case. And I mean, I think the demos are fantastic and v0 is, is great. Want to go back to something that you said previously is that. You know, you think that the iteration of AI that we have, this is going to be really augmenting people. It's going to be making engineers be able to do more than they've been able to do before.
And you're talking about like companies being able to sort of leapfrog these kind of awkwardly under engineered apps that are insufficient for their users into something a little bit more tailored. Um, the advancements of LLMs, especially recently has been pretty, pretty Fast, uh, relative, or it seems really fast and we've gained a lot of capabilities.
What do you, like, where do you see this going the next, you know, three to five years, how do you see it projecting? I mean, is it going to be augmenting faster or is it like going to radically change how we interface with things? Like, what is it gonna, what do you
think that future looks like?
Guillermo: I think it's gonna, I think it's going to continue to enhance our productivity at a rate that we haven't really seen with, let's call them like traditional developer tools, right? So,
an example is, if you want to make developers more productive with just Next. js, your options are somewhat limited, right?
You can improve the development experience, you can make the HMR faster, you can make builds faster. We're doing all of those. We're rewriting the entire compiler into Rust for the dev mode experience is almost complete. But what's next after that? What do you do when you've rewritten it into Rust? You write it into, like, faster Rust?
Like, you know, like, you're kind of, like, out of options for, like, traditional developer experience methods. Um, one thing that's particularly interesting to me is that what we need to be really good at is translating user intent into working software. That's what Copilot is already starting to show what's possible there.
Because sometimes you just write a comment and then it suggests a completion. That is not a typical developer tool in the sense of like, there's no algorithm that anybody wrote. The way that it's optimized is not by, you know, making those algorithms faster, etc, etc. And the productivity gains are just massive, right, from incorporating these kinds of tools.
So I think for a while we're going to see that these two work streams are going to be done concurrently. We're going to continue to improve the performance of build tools. We're going to continue to improve the performance of runtimes, but we're going to hit diminishing returns. All of the alpha in developer experience will be in getting closer to the actual intent of the developer or designer.
So we almost have to start earlier. Maybe I don't even use Next. js yet. I just have an idea for an app, and I can draw it. So I remember there was this funny tweet that said like, with, with AIs and LLMs, it's almost like the return of the idea guy into prominence, right? Because the meme in Silicon Valley was like, there's always some person that wants to start a company, and they don't bring much, they just have ideas.
And then they have to find the technical co founder and the technique and the design co founder and whatever. I want to make more and more, uh, that vision possible. Not of a person that has not worked on their skills, but yes, to having more and more ambition into what you can do full stack, I want to build that entire product from idea to global delivery on yourself and perhaps Adam.
I'm not an expert in talent. Perhaps I don't know what the right UX is for this data schema that I have. Or, honestly, there's so much friction in doing that, that I perhaps would have not built the product. I find this with myself all the time with vZero. People sometimes ask me, how come you post all this random stuff you build on Twitter?
Like, when do you have time? And part of that is like, I have been doing this for 20 years. So I've, I've become decent at like try and deploying things. Obviously I'm dogfooting the product. I have some unfair advantages that if I ever get stuck, I not only can ask chat GPT, but I can ask all this awesome colleagues that I have, but in reality, a lot of it is AI, uh, I think four out of the last five products that I've built.
All of the UI has been built with V zero and for me is that removing that writer's block. There is a writer block that happens with creating products and creating new user interfaces. That is tremendous. And, uh, you, you all can probably relate to this experience. I'm gonna self own for a second. I run create Next app. It shows me that page that says, welcome to the next phase, whatever. And then I delete all of it because I don't want it. Sorry. Next chance. Like, I don't want to your links. I don't want your logo, et cetera. And, and, and now what do I have? I have a blank page and it has tailwind in there, which is awesome.
But what do I, okay, I have to put something in there and that's where I think the zero and, and, and all these tools are just going to be amazing because. They're going to make us a lot more ambitious with starting new things, shipping new things, et cetera. You asked what are the capabilities that are coming to market that I think are going to take us to the next level.
Okay, so what if I already have built the application? What if my application is millions of lines of code long? What if it's legacy? What if it's not an XJS operator yet? Do I not get to play with all these toys? And I think the answer is all of the recent advancements like large context windows. Are going to make it possible to reason over much more code, essentially.
So they're going to do wonders for things like migrating from pages, writer, operator. We actually have done experiments internally with this, where in order to migrate our own workload from pages, writer, operator, we use the AI for large, large chunks of it. We're going to be able to create, and this is, this is coming soon for V0.
We're going to be able to create code in the style of what you already prefer. And what do you already have? I think it's going to be huge because yes, it's cute to use Visio for something that new, but what if I already have a design system and what if like, not everyone can ship minimalist, chatzy and looking code, right?
Like, what if I have to respect the brand identity of my company? So I still see all of that fundamentally, like the, all the stuff that's boring, clunky, uncreative. It's going to get done by AIs, a hundred percent. I sometimes think that it's useful to think of a lot of what we do as translation. When someone gives you a Figma, you're actually translating that into Tailwind.
When you move from PagesRider to AppRouter, you're translating that. There's more of a cognitive overhead sometimes, because like, the conceptual model changes. But if I go with the translation route, I can at least give you the initial draft, the robot will say, all right, you're, I did all the legwork for the first part of the migration.
Now you use your intelligence to determine, Oh, we're going to use client side rendering and client components over here. We're going to use server components over here. And like, I think the human will be sort of the editor in that process that continues to refine the code that the AI generates.
Justin: I totally agree. Like, uh, I, I love to liken my job to being a plumber. Uh, I, I see AI is just a really good wrench. Like we, we invented a really good wrench. That's really going to help a lot of plumbers and help more people become plumbers that weren't them before.
Guillermo: Absolutely. I, I love my job as a plumber
too.
Justin: well, let's talk about a different aspect of your job.
[00:54:57] Investment Insights: The Power of Obsession and Unreasonable Goals
Justin: Uh, so, uh, something that I can't help but notice is I see your name a lot on funding announcements for a bunch of different. Company. So it seems like you've been, yeah,
Guillermo: It's like a meme now. I'm attached to so many memes. There's Vercel memes, there's funding announcement memes.
Justin: yeah, for sure. You seem to be, uh, writing a lot of angel checks and I was curious about specifically. Like, what do you look for when you're wanting to invest in a company?
Guillermo: The easy answer is I'm always looking for extraordinarily talented people, um, that have dedicated their life to the pursuit of, uh, success. Sometimes the specific thing that might be overlooked by others. One of my first angel checks was to a company called Auth0 and the founders were unreasonably dedicated to authorization and authentication.
Like just let that sink in. Imagine convincing someone that's not in tech, that that's a, an interesting thing to pursue every single waking hour of your life too. We're going to make login really great, like. And. Yeah, so it's like, it's still part of like, what I've always loved about Silicon Valley and why I fit in so well here, which is like, just power to the nerds, like you want to nerd out for 10 years.
On auth and it turns out that auth is going to power the, you know, it's going to be the digital entry point into every experience that matters on the internet. So you're also looking for that tan, right? Going back to like plumbers and real world is like, you're a locksmith, you're installing, uh, you know, uh, keys and locks into the world into physical doors.
Thanks. But now in the digital realm, you can create an engine that does that with just three clicks. Oh, and it turns out that instead of there being billions of doors, there's going to be like trillions of doors. So you need that kind of like ridiculously sized market. You also need some kind of like controversial hypothesis.
I think the very first thing that I thought about Auth0 was, wait a second, you're a two person company and everybody in the world is going to trust you with their auth? Like it almost made no sense. So you, you need things that make almost no sense, uh, whether Sam Altman like rolls into your room and says like, I'm going to invent AGI, it's like, sure, Sam, go away.
No, you need something, and perhaps he doesn't quite get to like AGI is like science fiction or like that takes way too long, but you can deliver it along the spectrum of that sort of controversial statement. Same goes, I think, for, uh, same was true for Auth0, so the technical sort of underpinnings and the unreasonable pursuit of that, uh, you know, niche, you can call it, but it turns out it's not a niche, I think Paul Graham has become really good at this, where like, you have to simultaneously appreciate it as a niche and then believe that that niche will grow to become it.
a huge part of the global economy. Classic example here is Shopify starts with um, the founder saying I want to sell a snowboard and there's no easy way to like with two clicks sell a snowboard. And then he went to knock on the doors of like lots of VCs and they said, well, but I don't know if there's going to be that many people that need a small shop online.
Turns out there were a lot. Uh, and so that's why it has to be sort of that duality of like seems small because otherwise there's no alpha and everybody's in it. And then grows to be unreasonably big and obvious in retrospect. Bitcoin is actually another great example. When I first bought Bitcoin, I thought of it as my classic angel check.
It's like, oh, I'll just put 20, 000 into this thing. People say it's weird and like nobody would want it, but there is a chance and it seems like a niche that could get pretty big. And I think it's exactly like that sort of investment thesis.
Andrew: Yeah, we just had Danny Grant on from Jam Dev and she asked us, how would you invest 100, 000 into super early stage founders? And she said basically the same thing is that a person that is just wildly obsessed with a problem is a great start. And then you expanded upon it saying it's also an unreasonable goal.
So unreasonable goal paired with like unreasonable drive to solve it.
Guillermo: You know, over the, over the last couple, it seems like to be accelerating now, like over the last couple quarters, I've been getting a lot of feedback from people that passed on Vercel early on, and they're now coming to me saying why, which I really appreciate. And most of the times it's something along the lines of like, It just seemed so unreasonable.
Like the things you were saying, and I didn't want to even hear it myself. It's like, I'm embarrassed. Like the over aggrandized things that I was probably pitching at the time. Like, Oh, we're going to take over the entire cloud. We're going to be the next AWS. like, dude, you were some guy with a Shiva Inu in San Francisco, like with a DAG and you'd built nothing other than some open source project.
So there was a bit of that in our story as well. And just like the sheer size of the ambition was pretty crazy. Like, I think the, the thing that, um, has also become a meme that I really appreciate is a lot of people like myself have gotten into this. Because we underestimated how difficult it was going to be. Because if you could show me a quick video, like a trailer, when I started for sale of the next seven years and some of the lows and like late nights and pagers and whatever, I was like, huh, is it, is it going to take all of that? Like, holy shit. Like, let me, let me, let me get back to you, you know? So you kind of start with like this unreasonable goal and also a little bit of, and like, this is like this spoiler alert, like it's going to be so much harder.
And crazier than you believe. And you have to be signed up, you have to sign up for that. I think they, so you need someone that has the grit. Um, some people call it grind set now, like in, in that's because. Again, they're just so obsessed. Danny is right. They're so obsessed with making that true and invested in some version of their, uh, ego into it as well.
Like I'm going to die before this succeeds. That was my thing. Like I'm going to make this work at all costs. It was kind of my thinking.
Justin: That's awesome.
Andrew: So, uh, we've covered the, the, your answer, I think, to this question a little bit throughout the episode, but we like to ask it because it's a great way to sum up everything. So what do you think the future of front end looks like? And, uh, what do you think the next wave of apps will be centered around?
What will they look like?
Guillermo: Yeah. I think things are going to get a lot easier. We hear a lot of the community feedback about the next JS operator and not only because of AI, but I think it's exciting that AI will fuel this. It's going to get a lot easier to write applications. A glimpse of this future is that kind of joke we made about like, we reinvented PHP, right?
We're all getting Lambos. We're like, Oh, you just write some simple looking code that just queries the database. And then the UI happens. I think we're going to deliver on that dream pretty soon here. Um, it's already started and we're going to double down on that direction of just like making it and reasonably easy.
But I think what was missing from that. Old approach is unreasonably fast, interactive, personalized, generative. I think generative UI will play a huge role into the future of software. It's going to get a lot easier for people to reach more users. Um, I kind of talked about how difficult it is to meet every user, every device today, right?
Like you have to develop a mobile app, an iOS app, an Android app, a web app, a API, I think we're going to go back a little bit, almost like that dream of the semantic web. Like, write once, deploy everywhere, and like, what really matters is the semantics, the data, the content, the idea, because the rest is just automated by the computers. We're seeing a lot of interest in, like, the development of agents, right, and folks deploy to Vercel in order to protect against agents, and like, a lot of folks are paranoid over, like, how they're, uh, in the age of AI, their content is just being scraped, misused, etc. But also the reality is that with Agents, we can make any system interoperable even without you explicitly programming its interoperability.
We kind of talked about why like it was too effortful to create an API route and then create your frontend. What if all you are is frontend? Because all you care about is the customer experience. The interoperability between systems can be automated, everything will be an API in some way, in some senses.
So I think empowering the future with ai, empowering developers with ai, and also helping companies become AI companies, especially when they're struggling to deliver in today's software challenging challenges in in, in the world of today. It's part of our mission now, and, um, we're excited to deliver on it.
Andrew: I'm excited to see you accomplish the goal. It's a, it's a big goal you guys got, but it definitely speaks to the unreasonable goals.
Guillermo: We we'll get
there.
Andrew: So, uh, that's it. All we have for questions. Thanks for coming on. This was a great episode. Me and Justin have been waiting for this one for a while and it was an amazing chance to get to talk to you.
Guillermo: Thank you so much. I really had fun with it.
Justin: Yeah. Thanks so much, Guillermo. Uh, you're, I mean, we're big fans of the work that Verso has done and continues to do. So yeah, wish you all the best of luck and excited to see what comes next.