Screaming in the Cloud - How Vercel is Improving the Developer Experience on the Front End with Guillermo Rauch

Episode Date: December 21, 2023

Guillermo Rauch, Founder and CEO of Vercel, joins Corey on Screaming in the Cloud to discuss how he decided to focus on building a front-end tool that is fast, reliable, and focuses on the developer experience. Guillermo explains how he discovered that Javascript was the language that set online offerings apart, and also reveals the advice he gives to founders on how to build an effective landing page. Corey and Guillermo discuss the effects of generative AI on developer experience, and Guillermo explains why Vercel had a higher standard for accuracy when rolling out their new AI product for developers, v0. About GuillermoGuillermo Rauch is Founder and CEO of Vercel, where he leads the company’s mission to enable developers to create at the moment of inspiration. Prior to founding Vercel, Guillermo co-founded LearnBoost and Cloudup where he served the company as CTO through its acquisition by Automattic in 2013. Originally from Argentina,Guillermo has been a developer since the age of ten and is passionate about contributing to the open source community. He has created a number of JavaScript projects including socket.io, Mongoose.js, Now, and Next.js.Links Referenced:Vercel: https://vercel.com/v0.dev: https://v0.devPersonal website: https://rauchg.comPersonal twitter: https://twitter.com/rauchg

Hello, and welcome to Screaming in the Cloud, with your host, Chief Cloud Economist at the Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. Welcome to Screaming in the Cloud. I'm Corey Quinn. I don't talk a lot about front-end on this show, primarily because I am very bad at front-end. And in longstanding tech tradition,

if I'm not good at something, apparently I'm legally obligated to be dismissive of it and not give it any attention. Strangely enough, I've spent the last week beating on some front end projects, and now I'm not just dismissive, I'm angry about it. Here to basically suffer the outpouring of frustration and confusion is Guillermo Rauch, founder and CEO of Vercel, and also the creator of Next.js. Guillermo, thank you for joining me. Great to be here. Thanks for setting me up with that awesome intro. It's true. If I were talking to someone who looked at what I've done, and for some godforsaken reason, they wanted to follow in my footsteps, well, that path has been closed. So learning a bunch of Perl early on and translating it all to bad bash scripts and the rest, and then maybe picking up Python,

isn't really the way that I would advise someone getting started today. The de facto lingua franca of the internet is JavaScript, whether we like it or not. And I would strongly suggest that that be someone's first language, despite the fact that I'm bad at it, I don't understand it, and therefore it makes me angry. Yeah, it's so funny because it sounds like my story, my personal journey was when I was a kid, I knew I wanted to hack around with computers and reverse engineer them and improve them and just create my own things. And I had these options for what programming language I could go with. And I tried it all.

PHP, Perl, ModPHP, ModPerl, Apache, LAMP, CGI bin folders, all the whole nine yards. And regardless of what backend technology I used, I encountered this striking fact, which was the thing that can make your product really stand out in a web browser is typically involving JavaScript in some fashion. So when Google came out with suggestions, as you would type in a search box, my young kid Argentinian brain blew up.

I was like, holy crap. They can suggest, they can read my mind, and they can render suggestions without a full page refresh? What is that magic? And then more products like that came out. Google Docs, Gmail Chat, Facebook's real-time news feed. All of the great things on the internet seemed to have this common point of there's this layer of interactivity, real-time data, customization, personalization,

and it seems uniquely enabled by the front-end. So I just went all in. I taught myself how to code. I taught myself, I became a front-end engineering expert. I joined some of the early projects that shaped the ecosystem. Like there was this library called MooTools. And a lot of folks might have heard that name. It's in the annals of JavaScript history.

And later on, you know, what I realized is, what if front-end can actually be the starting point of how you develop the best applications, rather than this thing that people reluctantly frown upon, like yourself. I mentioned that as an opportunity rather than a this, because when you create a great front-end experience, now the data has proven you run a better business. You run a more dynamic business. Probably you're running an AI-powered business. All of the AI products on the planet today are using this technology to stream text in front of your eyes in real time and do all these awesome things. So yeah, I became obsessed with front-end and I founded this company, Vercel, which is a front-end cloud. So you come here to basically build the best products. Now you don't have to build the back-ends.

You can use back-ends that are off the shelf. You can connect to your existing back-ends. And we piggyback on the world's best infrastructure to make this possible. But we offer developers a very streamlined path to create these awesome products on the internet. I have to say that I have been impressed when I've used Vercel for a number of projects. And what impresses me is less the infrastructure powering it,

less the look at how performance it is and all the stuff that most people talk about. But as mentioned, I am not good at front-end or frankly programming at all. And so many products in this space fall into the very pernicious trap of, oh, well, everyone who's using this is at least this tall on the board of how smart you are to get on the amusement park ride. So I feel that when I'm coming at this from someone who is not a stranger to computers, but is definitely new to this entire ecosystem,

everything just made sense in a way that remarkably few products can pull off. I don't know if you would call that user experience, developer experience, or what the terminology you buy us for there is, but it is a transformational difference. Thank you. I think it's a combination of things. So developer experience has definitely always been a focus for me. I was that weird person that obsessed about the CLI parameters of the tool and the output of the tool and just how it feels for the engineer. I did combine that with, I think this is where Vercel really stands out, I did combine that with the world-class infrastructure bit because what I realized after creating lots and lots of very popular open-source projects, like one that's called Socket.io,

another one called Mongoose, DX or developer experience in the absence of an enticing carrot for the business doesn't work. Maybe it has some short-term adoption. Maybe it has raving fans on Twitter or X. But at the end of the day, you have to deliver something that's tangible to the end user and to the business.

So I think Vercel, focusing on the front, has found a magical combination there of I can make the developer lives easier. Being a developer myself, I just tremendously empathize with that. But it can also make more profit for the business. When I make your website faster and render more dynamic data that surfaces better recommendations for a product on e-commerce or in a marketing channel, I can help you roll out more experiments. Then I make your business better. And I think

that's one of the magical combinations there. The other thing, frankly, is that we started doing fewer things. So when you come to Vercel, you typically come with a framework that you've already chosen. It could be Next.js, it could be Vue, Nuxt, there's 35 plus frameworks. But we basically told the market, you have to use one of these developer tools in order to guide your development. And what companies were doing before, I mean, this almost seems obvious in retrospect, that we would optimize for certain patterns and certain tools. But what the market was doing before was rolling out your own frameworks. Like every company was basically...

React, for example, is a very popular way of building interfaces. And our framework actually is built on top of React. But when I would go to and talk to all these principal engineers at all these companies, they would say, oh yeah, we're creating our own framework. We're creating our own tools. And I think that to me now feels like

almost like a zero interest rate phenomenon. Like what business do you have in creating frameworks, tools, and bespoke infra when you're really in the business of creating delightful experiences for your customers? What I think is lost on a lot of folks is that if you are trying to learn something new and use a tool and the developer experience is bad, the takeaway, at least for me and a lot of the developer experience is bad, the takeaway, at least for me and a lot of people that I talk to, is not, oh, this tool has terrible ergonomics. That's its problem. Instead, the takeaway is very much, oh, I'm dumb because I don't understand this thing. And I know intellectually that I am not usually the dumbest person in the world when it comes to a particular tool or technology. But I keep forgetting that on a visceral level. I just wish I was smart enough to understand that. No, I don't. I wish it was

presented in a way that was more understandable and the documentation was better. When you're just starting out and building something in your spare time, the infrastructure cost is basically nothing. But your time is the expensive part in it. So if you have to spend three hours to track down something just because it wasn't clearly explained, the burden of adopting that tool is challenging. I would argue that one of the reasons that AWS sees some of the success that it does is not necessarily because it's great, so much as because everyone knows how it breaks. That's important. I'm not saying their infrastructure isn't world-class. Please, don't come at me in the comments on this one. But I am saying that we know where its sharp edges are, and that means that we're more comfortable building with it. But the idea of learning

a brand new cloud with different sharp edges in other areas, that's terrifying. I'd rather stick with the devil I know. Exactly. I do think that you're not going to be able to make a difference for customers in 2023 by creating another bespoke cloud that is general purpose. It doesn't really optimize around anything. And you have to learn all the sharp edges from scratch. I think we saw that with the rise of cloud native companies like Stri and twilio where they were going after this amazingly huge markets like financial infrastructure communications infrastructure but the angle was here's this awesome developer experience and that's what we're doing with vercell for for the front end for building right? There has to be an opinionated developer experience that guides you to

success. And I agree with you that there's really these days in the developer community is zero tolerance for sharp edges. And we spend a lot of time in even documentation. Like it used to be that your startup would make or break it by whether you had great documentation. I think in the age of frameworks, I would even there say that documentation, of course, is extremely important. But if I can have the tool itself guide you to success, at that point, you're not even reading documentation. We're now seeing this with AI and generative AI for code.

At Vercel, we're investing in generative AI for user interfaces. Do you actually need a re-documentation at that point? So I think we're optimizing for the absolute minimal amount of friction required to be successful with these platforms. I think that there's a truth in that, of meeting customers and where they are. Your documentation can be spectacular, but people don't generally read the encyclopedia for Fauna either. And the idea that is that, at least ideally,

I should not need to go diving into the documentation. So many tools get this wrong, where, oh, I want to set up a new project, and it bombards you with 50 questions, and each one of these feels pretty momentous. Like, what one-way door am I passing through that I don't realize the consequences of until I'm 12 hours into this thing, and then have to backtrack significantly? I like, personally, things that buy us for having a golden path, but also make it easy to both deviate from it, as well as get back onto it.

Because there's more than one way to do it is sort of the old Perl motto that is true in spades in anything approaching the JavaScript universe. Yeah, I have a lot of thoughts on that. On the first point, I completely agree that the golden path of the product cannot be documentation mediated. One of the things that I've become obsessive about, and this is an advice that I share with a lot of other startup founders, is when it comes to your landing page, the primary call to action has to be this golden path to success. Like two, three, four clicks later, I have to have something tangible. That was our inspiration.

And when we made it, the primary call to action for Vercel is deploy now. Start now. Get it out now. Ship it now. And the way that you test out the platform is by deploying a template. What we do is we create a Git repo for you. It sets up the entire CICD pipeline.

And then at that point, you already have something working, something in the cloud. You spend zero time reading documentation, and you can start iterating. And even though that might not be the final thing you do on Vercel, I always hear these stories of CTOs that are now deploying Vercel at really large scale, and they always tell me,

I started with your hobby tier, I started with your hobby tier, I started with your free tier, I deployed a template, I hacked on a product during the weekend. Now a lot of our AI examples are very popular in this crowd. And yeah, there's a golden path that requires zero documentation. Now, you also mentioned that what about complexity? This is an enterprise-grade platform. What about the escape hatches? What about flexibility? And that's where our platform also shines because we have the entire power of a Turing-complete language, which is JavaScript and TypeScript, to customize every aspect of the platform. And you have a framework that actually answered a lot of the problems that came with

serverless solutions in the past, which is that you couldn't run any of that on your local machine. The beauty of Vercel and Next.js is we kind of pioneered this concept that we call framework-defined infrastructure. You start with a framework. The framework has this awesome property

that you can install it on your computer. It has a dev command. It literally runs on your computer. But then when you push it to the cloud, it now defines the infrastructure. It creates all of the resources that are highly optimal. This basically converts what was a single node system on your computer to a globally distributed system, which is a very complex and difficult engineering challenge, but Vercel completely automates it away. And now for folks that are looking for more advanced solutions, they can now start poking into the outputs of that compilation process and say, okay, I can now have an influence or I can reconfigure some aspects of

this pipeline. And of course, if you don't think about those escape hatches, then the product just ends up being limiting and frustrating. So we had to think really hard about meeting both ends of the spectrum. In my own experimentations early on with ChatGPT, which is how I insist on pronouncing ChatGPT, a lot of what I found was that it was a lot more productive for me to, instead of asking just the question and getting the answer, it was write a Python script to query this API to get me

that answer. Because often it would be wrong, sometimes very convincingly wrong, and I can at least examine it in various ways and make changes to it and iterate forward. Whereas when everything is just a black box, that gets very hard to do. The idea of building something that can be iterated on is key.

I love that. The way that Vercel actually first introduced itself to the world was this idea of immutable deployments and immutable infrastructure. And immutable sounds like a horrible word because I want to mutate things, but it was inspired by this idea of functional programming where each iteration to the state, each data change can be tracked. So every time you deploy in Vercel, you get this unique URL

that represents a point-in-time infrastructure deployment. You can go back in time, you can revert, you can use this as a way of collaborating with other engineers in your team. So you can send these hyperlinks around to your front-end projects, and it gives you a lot of confidence. Now you can iterate, knowing that before things go out, there's a lot of scrutiny, there's a lot of QA, there's a lot of testing processes that you can kick off against this serverless infrastructure was created for each deployment. The conclusion for us so far has been that our role in the world

is to increase iteration velocity. So iteration speed is the faster horse of the cloud, right? Like instead of getting a car, you get a faster horse when you say, okay, I made the build pipeline 10% faster, or I brought the TLS termination 10% closer to the visitor. And like, I have more pops, things like that. That to me is the speed. You can do those things and they're awesome. But if you don't have a direction, which is velocity, then you don't know what you're building next. You don't know if your customers are happy. You don't know if you're delivering value. So we built an entire platform that optimizes around what should you ship next? What is the friction involved in getting your next iteration out? Is launching an experiment on your homepage, for example, is that a costly endeavor? Does it take you weeks?

Does it take you months? One of the initial inspirations for just starting Vercel and making deployment really easy was how difficult is it for the average company to change in their footer of their website is this copyright 2022. And you have, it's new year.

You have to bump it to copyright 2023. How long do you think it takes that engineer to A, run the stack locally so that they can actually see the change, deploy it, but deploy it to what we call the preview environment so they can grab that URL and send it to Corey and say, Corey, does it look good?

I updated the year in the footer. And then you tell me, looks good. Let's ship it to production. Or you tell me, no, no, it's risky. Let's divide it into two cohorts. 50% of traffic gets 2022, 50% of traffic gets 2023. Obviously, this is a joke, but consider the implications of how difficult it is in the average organization to actually do this thing. Oh, I find things like that all the time, especially

on microservices that I built to handle some of my internal workflows here. And I haven't touched in two or three years. Okay, now it's time for me to update them to reflect some minor change. And first I wind up in the screaming node warnings and I have to update things to so that they actually work in a reasonable way. And on some level, making a one-line change can take half a day. Now, in the real world, when people are working on these apps day in, day level, make it a one-line change can take half a day. Now, in the real world, when people are working on these apps day in, day out, it gets a lot easier to roll those changes in over time. But coming back to something unmaintained, that becomes a project the longer

you let it sit. Part of me wishes that there were easier ways around it, but there are trade-offs in almost any decision you make. If you're building something from the beginning, if, well, I want to be able to automatically update the copyright year, you can. If you're building something from the beginning, if I want to be able to automatically update the copyright year, you can even borderline make that something that automatically happens based upon the global time. Whereas when you're trying to retrofit it afterwards, yeah, it becomes a project.

Yeah, and I think that's just a simple example of changing a string. That might be difficult for a product engineering in your organization, or it might be slow, or it might be not as streamlined, or maybe it works really well for the first project that that company created. What about every incremental project thereafter? So now let's stop talking about a string. Let's think about an e-commerce website where what we hear from our customers on average, like 10% of revenue flows through the homepage.

Now I have to change a primary component that renders them a hero of the page. And I have to collaborate with every department in the organization. I have to collaborate with the design team. I have to collaborate with marketing. I have to collaborate with the business owners to track the analytics appropriately.

So what is the cost of every incremental experiment that you want to put in production? The other thing that's particularly interesting about front-end as it relates to cloud infrastructure is scaling up front-end is a very difficult thing. What ends up happening is most front-ends are actually static websites. They're cached at the edge, or they're literally statically generated, and then they push all of the dynamism to the client side. So you end up with this spaghetti of script tags on the client. You end up accumulating a lot of tech debt,

you end up shipping huge bundles of JavaScript to the client to try to recover some dynamism, to try and run these experiments. So everyone is in this kind of mess of the, yes, maybe we can experiment, but we kind of offloaded the rendering work to the client. That in turn makes me, basically, I'm making the website slower for the visitor. I'm making them do the rendering work. And I'm trying to sell them something.

I'm trying to speed up some process. It's my responsibility to make it fast. So what we ended up finding out is that, yes, the cloud moved this forward a lot in terms of having this awesome building blocks, this awesome infrastructure primitives. But both of the developer experience, just changing something about your web product,

and also the end user experience, which is that web product renders really fast. Those things really didn't happen with this first chapter of the cloud. And I think we're entering a new generation of higher level clouds like Vercel that are optimizing for these things. I think that there's a historical focus on things that have happened before. And that was painful and terrible. So we're not going to be focusing on what's happening in the future.

We're going to build a process or a framework or something that winds up preventing that thing that hurt us from hurting us again. Now, that's great in moderation, but at some point, we see this at large companies from time to time, where you have so much process that is ossified scar tissue, basically,

that it becomes almost impossible to get things done because, oh, I want to make that, for example, that one line change to a copyright date. Well, here's the 5,000 ways Deploys has screwed us before. So we need to have three humans sign off on the one line change and a bunch of other stuff before it ever sees the light of day.

Now, I'm exaggerating slightly, just as you are, but that feels like it acts as a serious break on innovation. On the exact opposite side, where we see massive acceleration, has been around the world of generative AI. Yes, it is massively hyped in a bunch of ways. I don't think it is going to be a defined way that changes the nature of humanity, the way that some of these people are going after. But it's also clearly more than a parlor trick. I'm kind of in that camp. So like you, I've been writing code for many years. I'm pretty astonished by the AI's ability to enhance my output.

And of course, now I'm not writing code full time. So there is a sense of, okay, because I don't have time, because I'm doing a million things, any minute I have seems like AI has just made it so much more worthwhile. And it can squeeze so much more productivity out of it. But one of the areas that I'm really excited about is this idea of generative UI, which is not just auto-completing code in a text editor, but it's the idea that you can use

natural language to describe an interface and have the AI generate that interface. So Vercel created this product called V0. You can check it out at v0.dev, where to me, it's really astonishing that you can get this incredibly high quality user interfaces. And basically, all you had to do is input a few English words. I have this personal experience of, I've been learning JavaScript and perfecting all my knowledge around it for like 20 or so years. I created Next.js. And Next.js itself powers a lot of these AI products. The front end of JGPT is built on Next.js. And I used vZero to basically recreate my blog.

I created route2g.com. I deployed it on Vercel. But every pixel of that UI, I handcrafted. And as we were working on vZero, I said, okay, I'm going to challenge myself to put myself back in the shoes of like, I'm going to redesign this and I'm going to start over with just human language. Not only did I arrive to the right look and feel of what I wanted to get, the code that it produced was better than what I would have written by hand.

Concretely, it was more accessible. So there were areas of the UI where some icons were rendered where I had not filled in those gaps. I just didn't know how to do that. The AI did. So I really believe that AI will transform our lives as programmers, at least I think, in many other areas in very profound ways.

This is very similar to a project that I've been embarked on for the last few days, where I described the app I wanted into ChatGipity and followed the instructions. And first it wound up sending me down a rabbit hole of the wrong framework version that had been deprecated and whatnot. And then I brought it all into the S-code, where Github Copilot, it kept switching back and forth between actively helpful and ooh, the response matches publicly available code. So I'm not going to tell you the answer, despite the fact that that feature has never been enabled on my account. So yeah, of course it matches publicly available code.

This is quite literally the React tutorial starter project. And it became incredibly frustrating, but it also would keep generating things in bursts, so my code is not at all legible or well-organized or consistent, for that matter, but it's still better than anything I'd be able to write myself. I'm looking forward to using v0 or something like it to see how that stacks up for some of my ridiculous generation ideas for these things. Yeah, you touched on a very important point, is the code has to work. The code has to be shippable.

I think a lot of AI products have gotten by by giving you an approximation of their result, right? Like they hallucinate sometimes, they get something wrong. It's still very helpful because sometimes they send you in the right direction. But for us, the bar is that these things have to produce code that's useful and that you can ship and that you can iterate on. So going back to that idea of iteration velocity, we called it v0 because we wanted it to be the first version. We still very

much believe there's humans in the loop and folks will be iterating a lot on the initial draft that this thing is giving you, but it's so much better starting with an empty code editor. And this applies, by the way, to not just new projects, but I always talk about our customers have a few really important landing pages, key pages. Maybe it's the product detail page in e-commerce. Maybe it's your homepage and your key product pages for a marketing website. Maybe it's where the checkout, for example, extremely important. But then there are a lot of incremental UIs that you have to add every single day. The banner for accepting cookies or not, the consent management dialogue.

There's a lot of things that the worst case scenario is that you offload them, again, to some third-party script, to some iframe of sorts, because you really don't have the bandwidth, time, or resources to build it yourself. And then you sacrifice the speed, you sacrifice brand fidelity. And again, because we're the front-end cloud, we're obsessed with your ability to ship UI

that's native to your product, that is a streamline that works really well. So I think AI is going to have a significant effect there where a lot of things, where you were sending someone to some other website because you just didn't have the bandwidth to create that UI, you can now own the experience end-to-end. That is no small thing.

A last question I have before we wind up calling this an episode is there was a period of time, I don't know if we're still in it or not, where it felt like every time I got up to get a cup of coffee and came back, there would be three JavaScript frameworks that launched during that interim.

So Next.js was at one point, one of those when someone got up to get a cup of coffee, but that's shown a staying power that is frankly remarkable. Why? I don't know enough about the ecosystem to have an opinion on that, but I noticed when things stand out and Next does. Yeah, I think it's a number of factors. Number one, we, as an industry, I think we coalesced and we found the right engine to build our car. And that engine became React.

Most folks building UI today are choosing React or a similar engine, but React has really become the gold standard for a lot of engineers. Now, what ended up happening next is that people realized, I want a car. I want the full product. I need to drive. I don't want to assemble this freaking car every single time I want a car. I want the full product. I need to drive. I don't want to assemble this freaking car every single time I have a new project. And Next.js filled a very important gap in the world

where what you were looking for was not a library. What you were looking for is a framework that has opinions, but those opinions are very in line with how the web is supposed to work. We took a page from basically the beginnings of the web. We make a lot of jokes that in many ways our inspiration was PHP, where server rendering is the default, where it's very expressive. It's very easy to reach for data. It just works for a lot of people.

Again, that's the old sack is the olden days. So it obviously didn't quite work, but the inspiration was, can we make something that is a streamlined for creating web interfaces at scale? And to your point, there's also a sense of like, maybe it doesn't make sense anymore to build all this infrastructure from scratch every single time I start a project.

So next, fill in that gap. The other thing we did really well, I think, is that we gave people a universal model for how to use not just the server side, but also the client side strategically. So I'll give you an example. When you go to ChatGPT, a lot of things on the screen are server rendered.

But when you start doing interactions as a user that require, for example, like you'd say, hey, Dally, generate an image, that stuff requires a lot of optimistic UI. It requires features that are more like what a mobile native application can do. So we kind of gave folks the best of both worlds, the speed, interactivity, and fluidity of a native app. But we had those sort of fundamentals of how a website should work that even Perl and PHP had gotten right once upon a time. So I think we found that right blend of utility

and flexibility and folks love it. And I think, yeah, we're excited to continue to help steward this project as the standard for building on the web. I really want to thank you for taking the time to talk about a lot of the genesis of this stuff and how you view it, which I think gives us a pretty decent idea

of how you're going to approach the evolution of what you've built. If people want to learn more, where's the best place for them to find you? So head to vercell.com to learn about our platform. You can check out vzero.dev, which will be opening broadly to the public soon

if you want to get started with this idea of generative UI. And myself, I'm always tweeting on x.twitter.com or x.com slash RouchG. Define me. One of these days we'll be able to kick that habit, I hope. Thank you so much for being so generous

with your time. I appreciate it. Thank you. Guillermo Rauch, founder and CEO of Vercel and creator of Next.js. I'm cloud economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five star review on your podcast platform of choice. Whereas if you've hated this podcast, please leave a five star review on your podcast platform of choice, along with an angry, insulting comment that will be almost impossible for you to submit because that podcast platform did not pay attention to user experience. If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duck Bill Group.

We help companies fix their AWS bill by making it smaller and less horrifying. The Duck Bill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.