S5 Bonus: Guillermo Rauch, Vercel & Next.js (Replay)

But I remember I just wanted to create a simple web page that used React components. In particular, I was trying to build the web page that said, 'Welcome to our company, leave your email to get started.' And I noticed that all that infrastructure was a pain to set up. You had to configure Webpack, you had to basically spend all this time just working on the meta problem instead of just your UI and your brand, the cool stuff that you want to share with customers. It's a very simple contract of you can get started with no configuration, and there is one command to develop, and one command to build, and one command to run the entire thing on your machine. My name is Guillermo Rauch, and I'm the CEO and co-founder of Vercel.

Vercel is a developer platform for front-end teams, and our intent is to give you all the tools necessary for you, your team, your company to succeed on the web. We have this lifecycle that we call develop, preview, ship. Develop: you can use any modern front-end framework to develop on our platform, but we create Next.js, which is a React-based framework. We like to think of it as the SDK, or the missing SDK for the web. Just like every other ecosystem like Android or iOS have their SDK built in, we want to perfect this blend of opinionation and minimalism in an SDK that we can give all developers in the world for free, and it's completely open source. So Next.js turns React into a technology that you can use to build pages and websites and applications. It's very ergonomic and easy to use. The preview part of our lifecycle is that once you push your code, we give you a live URL that you can share and collaborate with your team. We think that the best products are built by teams, not just individuals, and we think that the front-end ecosystem has this amazing advantage that when you push code, it's just much more fun to go to a live URL and see how it works, experience it, test that it meets the needs of the product managers and your customers, share it with your customers even early on. And then finally, the sort of ship phase of the lifecycle is about delivering your application to a global edge network that makes your apps really, really snappy for end users. So the way that we think of this as a workflow is that each phase should sort of reinforce the last. So when you push your front-end, we want you to make sure that it performs great for your end users so that you can run the best possible business or have the most enjoyable possible application for end users. So we also have an analytics layer that informs the next step of development here. So when you ship your code, we measure it from the perspective of your end users, and we kind of give you the data that you can use to then develop, then preview, then ship, and make this process just a constant source of improvement for your applications.

It was really interesting because when I sold my previous company to WordPress, which is another great web platform, having been always a JavaScript person, a front-end person, I saw an opportunity to sort of build out basically the front-end layer of the web. Because I thought that systems like WordPress, Shopify, Strapi, they've done such a fantastic job for the people that are working on the back-end. For example, at WordPress, one thing I learned is that one of our biggest customers was the person that logs in every day to edit, to review, to write new content, especially at larger companies. I thought it was fantastic. It has an incredible plugin ecosystem, folks love the editor, the block-based editor of WordPress. But what I was noticing at the time was that there was this trend in the industry toward APIs. Everything was becoming an API. And I noticed that very early on because I was always interested in how you can sort of create interesting business models out of developer-first methodology. So for example, Stripe is a great fintech company that started with a great developer API. I remember actually I was very excited when I was at WordPress that they were starting to merge this plugin into main that was the REST API for WordPress, and then a GraphQL API for WordPress developed. So I was noticing that the industry was breaking down that monolithic way of building where, for example, in the case of WordPress, your back-end and your theme all live inside the same code base and the same technology with the same tools. And I thought that for the front-end, the most interesting tool that you could possibly use was JavaScript, let alone things like React. So I had this idea of creating a framework that made this concept of sort of awesome, super interactive, super fast JavaScript applications a reality. But unlike predecessors like Meteor and other ideas that had been in the JavaScript ecosystem in the past, I decided that by design this framework was not going to have its own database or its own opinionation about how you would get your data. So it's literally just a front-end layer. The interesting thing that happened early on in the development of this was I noticed that the best possible experience for the front-end developer was going to come from the ability to iterate very fast. So I had this idea that you should just write one command very quickly and then get your page up and running in the cloud. Cloud and framework were getting closer together, we're starting to merge so to speak. So I developed Next in parallel with the sort of infrastructure platform that would make Next the best possible framework it could be, and it would also make the front-end developer not have to worry about all these things. Like I remember at the time, even just getting SSL up and running for a quick front-end project was a tedious task. We developed the framework and the cloud platform in parallel, and that turned out to be one of the biggest strengths of Vercel because, as I mentioned earlier, we give enterprises or teams all the tools that they need to succeed from develop all the way to ship.

So one of the things that happened in the early days of the React ecosystem was that folks were sort of struggling with the idea of infrastructure, but on the compiler level, on the tooling level. So we had all these cool pieces of software that we could use to bring a React-based project to fruition. But I remember I just wanted to create a simple web page that used React components. In particular, I was trying to build the web page that said, 'Welcome to our company, leave your email to get started.' And I noticed that all that infrastructure was a pain to set up. You had to configure Webpack, you had to basically spend all this time just working on the meta problem instead of just your UI and your brand, the cool stuff that you want to share with customers. That was our first opportunity. The MVP was this zero-config framework. It wasn't all worked on perfectly in the beginning, but what we did have, which we maintain to today, is a very simple contract of you can get started with no configuration, and there is one command to develop, and one command to build, and one command to run the entire thing on your machine. We are one of the few open-source serverless frameworks that can run in its entirety on your local machine or inside a container. The MVP was assigned from a contract design type of thing. We knew what the boundaries of the system were, we knew the expectations of the simplicity of the ergonomics of the tool, and then we kind of started, you know, we continuously, even until today, continue to improve the internals from those boundaries. And then on the cloud, Vercel side, a very similar thing happened. We knew that we wanted deployment to be as simple as git push or running one command per cell, and then you get a URL. But then we iterated on the infrastructure, and we continue to iterate on the infrastructure. We never really stopped changing the internals because we continue to improve them based on what frameworks need and what our customers need. But the boundaries have stayed the same. And one of the reasons that I bet on the web is I remember I was super excited about HTTP/2 back then, now I'm really excited about HTTP/3. I figured that the hyperlink is the right boundary of abstraction for the cloud side. We didn't want a framework that spit out a binary to run in an app store. We wanted the developer to get a URL back from the system. So that is the same contract that remains until today. We just continue to improve the underlying infra.

From the outset, we launched in a very public way, and we wanted to get customer feedback as soon as we could. So it was very much built in collaboration with anybody that was interested in building anything with these new JavaScript and React technologies. I think us focusing on a niche, in a way, even though that wasn't obvious or 100% conscious to us at the time, we were very focused in our audience. So we leveraged our existing audiences. I think something that was really interesting that we were doing differently at the time was Next.js was very focused on server rendering, as opposed to... it was almost like a contrarian thing because a lot of the JS ecosystem at the time was excited about single-page applications. We evolved our framework and infrastructure a lot around now what are these folks that need server rendering asking us. That ended up being very successful because a lot of the folks that gravitate towards Next are companies that were doing things in e-commerce or companies that wanted really good SEO, and the framework just fit really nicely. So being an open-source project, the roadmap and the issue management and all that is very open, and I think we kind of constantly evolved it based on the feedback of users in the community, either from companies or even folks that were trying out the platform in its early stages to build side projects.

So a big part of it in the early days was just attaining production-grade quality. So one of my obsessions for a long time was, you know, I want these tools to scale extremely well from I have a single page that's on a domain that I'm publishing to something that scales to like billions of pages in the largest websites in the world. And a lot of that was sort of very conscious and designed from the outset. But in the early days, you kind of have to be realistic that there is only so much you can do, especially as a service. So we really worked hard on the fundamentals. How can we make the deployment pipeline very reliable and reproducible? How can we make performance very predictable? How can we work up to a point where we can give our customers SLAs rooted in SLOs of availability and performance? So a lot of that was like building a very strong core. In fact, the way that this idea of the strong core, which we used to sort of share a lot internally in the beginning, was we didn't rush to add lots of features. People are surprised sometimes of some features that we decide not to include yet, and we tell you, hey, there's a user-space solution for this, a user-land solution for this. And that had to do with continuing to develop a very strong core, and that in many ways means saying no to very enticing features.

I think one of the most interesting strengths of an open-source first organization like ours is that we're able to recruit from folks that are using and or contributing to our software. So I think the vast majority of initial hires came from that open-source ecosystem. Many came from adjacent ecosystems that had been already a part of like Meteor, Socket.io, and other projects that had been involved with. Many customers came from those ecosystems as well. So that kind of always the priority is people that value developer experience greatly and are already immersed in the communities in which we develop our software.

I think it's always a combination because the speed at which things grow, there's just so much that's emergent behavior. And in many ways, with design, things to have emergent behavior within controlled boundaries. I had a customer recently that was bootstrapping an entire payment platform on top of our API functions to support in Next.js. Could I have anticipated that? No, because most of our customers are doing cool things with components and UI and e-commerce, and they tend to use existing platforms for their APIs. However, we knew that with introducing the API route support that under the hood gets deployed as serverless functions, we would be giving our customers tremendous flexibility and scalability and just a lot of dynamic power for their projects. So there's always things that are interesting and emergent, but we always wanted to excel at a particular use case. So for us, we really lean toward this is going to be the absolute best place to deploy your front-end, and we're going to give you the absolute best performance both for developer and end user. Now, when it comes down to scalability, things that we designed were conscious. For example, a goal toward team scalability. So Next.js designed this pages system to provide isolations between the sections of your application. Going back to like one of the reasons I never liked the single-page application concept was I didn't think it had good team scalability. I didn't think that you could come into a project, create a new entry point, and start adding complexity there that wouldn't add or slow down the rest of the application. It was much harder to do that with the single-page application model. So team scalability was built in from day one. We also knew that with how the web works and how much is bound by how fast the initial load time is, which today this concept didn't exist at the time, the web vital largest contentful paint is extremely hard, if not impossible, to get outstanding largest contentful paint timings for complex applications without server rendering or pre-rendering in some form or fashion. So with the design of Next.js, with server rendering, with that kind of scalability in mind, we also knew reverse engineering how Google Search and Facebook.com worked, the common pattern was they both use server rendering at scale. I'm not going to pick that fight. They've tried enough things, and they were pressured by billions of dollars a day in advertising or other sort of products and services flowing through those platforms to get that text in front of your retina in as few milliseconds as possible. My whole thing was like, let's design a framework that allows customers to get that ambitious with performance. Now, what was emerging was, for example, how fast the traffic on our platform has grown and the number of use cases and frameworks and funky things that people try to do with the platform. So with things being so open and growing so fast, there's a lot about scalability that you don't quite anticipate, and you just have to adapt and react quickly to the environment.