Guillermo Rauch on Just Do Less — SmashingConf Live August 2020

Okay, so yeah, the talk is called Just Do Less and it's really about a set of principles for making great technology happen. I'm gonna go into specifics of software development and Jamstack and a lot of the exciting work that we're doing with Next.js of which I'm the co-founder and co-creator, and the Vercel platform, the best place to deploy any Jamstack website and Jamstack frameworks like Next.js. So in the past, as Phil said, I was involved with a number of projects of which the common theme really has been speeding up user experiences, real-time communication, But most of all, it's really been about JavaScript. It's been about creating great UIs with it. It's about community. And with this sort of background, a lot of what I wanna talk about today is how do we make great technology happen? How do we make great decisions for technology? And kind of the underlying principle that I wanna talk about is this idea of just doing less. The principle is hopefully something that can allow you to navigate a world that is getting more and more complex. Especially in the frontend world, right? So it's hard to navigate sometimes the plethora of decisions when it comes down to static site generators, web frameworks, React versus Vue, JavaScript versus WebAssembly, all the things that are sort of coming your way. It's quite hard to make good decisions. So hopefully with this principle that I'm gonna talk about today,, it becomes easier to navigate that. Ultimately, it's also about remembering that, uh, as developers, we do a lot of work to ultimately create delightful experiences for people and enabling great business outcomes. So I really want to involve this theme of, um, all the technology that we use, choose, and create has to do ultimately with the end user experience. And the other and perhaps less obvious part of this all is that sure, you want to start doing as little as possible. You wanna start being as lazy as possible, really. You wanna start being as simple as possible, but no, but not simpler. And I'm gonna talk about how we can navigate that world of ever accumulating complexity because at the end of the day, We all get excited as developers to reboot projects, start from scratch, start from a clean slate, use the latest web framework, but it's helpful sometimes to just look ahead and sort of foresee the complexity that is coming because for most people it is coming and it's inevitable. And I wanted to contextualize the talk too because we are And we have been, as a company, as developers of a popular web framework, we have gone through this journey ourselves. So we've been in the space of designing a framework and when it comes down to exposing developers with choices, there's also been many. So one of the things that I wanted to do with this talk that I've been working on for a while now is give you our journey as well, give you a sort of opinionated point of view of this very complex world. And hopefully with the lessons and examples that I provide, you can sort of make very informed decisions and learn how we basically put this principle of less is more into action. And one of the things that I've seen come up in the recent number of years that has helped sort of bring this principle into action has been Jamstack. And I've always thought that Jamstack is interesting because I don't think it really is a stack per se, right? So JavaScript and APIs and markup are not an actionable stack. Like I tell tomorrow one of my developers, hey, go and use JavaScript API and markup to build our new website. I think likely would be faced with that sort of choice paralysis again of like, okay, what JavaScript? What API? Markup where? I've been using markup for the past 20 years. So part of what I want to share with this talk is how basically Jamstack, it really is a principle just like less is more and how Jamstack can be sort of that guiding lighthouse for creating delightful user experiences for people. One of the principles that I've loved about Jamstack is its close affinity to the world of CDNs, right? Like when, again, like when I tell you about a stack, it's hard to comprehend sometimes how it would relate to a deployment mechanism or to a delivery mechanism like CDNs. But that's, I think, what also makes Jamstack interesting because it's a software architecture at the end of the day, right? And software architectures will talk about concepts, right? And like one of the important concepts that I like to talk about is this idea of pre-rendering. Which is something that we've been involving as a first-class citizen, not just in our minds but also in the frameworks that we're creating. And one of the cool things about CDNs in particular is that it relates to that idea of helping the end user in my mind, because if you render pages faster because you deploy to a CDN by default, you convert more customers. If you're working on something that sells items like e-commerce websites, you sell more items. And if you're working on content websites, you make people click more ads. And obviously this sounds horrible. I hate ads. I use an ad blocker. But the reality is that one of the interesting things about Jamstack is the economic implications of, um, helping both customers and businesses, which by the way, and this is actually a bit controversial to say, but I think this is a major departure Right? Like, when you think about Kubernetes, when you think about all kinds of other software architectures that people sell or promote, they don't always really put the customer as the epicenter of the technology. And that's something I do like about the world that we're going into in the frontend space is that we're talking about the reality of the product. We're talking about the performance of the product. We're not talking about service meshes and microservices and maybe like some napkin math about how it's gonna save you money. We're talking about concrete steps to make the world better. And I very much like that. And one of the key things is that we can do a lot more with less. And that's kind of the principle that I wanna talk about. The first way in which you do less or nothing at all really is the backend. So we've seen the emergence of this sort of reusable backends, right? And that's kind of the A of Jamstack, which is like, hey, I'm gonna bring an API that already exists because whether my team already created it or because I buy it off the shelf. So what do I mean by buy it off the shelf? Well, if I go to a headless CMS provider, they're giving me the API without me doing anything at all. So I'm effectively doing less or nothing at all. E-commerce is extremely exciting right now, especially in the sort of COVID world in which major retailers and brick-and-mortar stores and physical places are rushing to digitize. Okay, I want to bring you online, I want to create the best possible customer experience. Is the API relevant to that? Well, increasingly The answer would be no, and it would be that I can acquire it as a premade, prefabricated piece. We've seen this as well with login and identity with providers like Auth0 and Magic.link, where I just sign up for an API, they give me the credentials. We've seen pioneers in this space like Stripe and Twilio. So we're in great company when it comes down to choosing an architecture like this. Perhaps even more exciting is the code generation, right? Like, I wanna take this to such the extreme that backend is becoming not as interesting because it's being auto-generated, right? Like, if you've used Hasura, if you've used EdgeDB, if you've used Prisma, what you're noticing probably is, and I was, as Phil was saying, I was involved with Mood Tools myself, A lot of that code can just be auto-generated. Okay, I know my database schema. Okay, generate backend. So the remaining challenge is actually obviously the most interesting one, which is, okay, how do I do the parts that I'm tasked to do and how am I really productive in doing so? So Next.js over the past 4 years that it's existed has gone through a very interesting transition. So Next.js was known at the time for SSR, but then we realized that a lot of optimizations such as automatic CDN caching were only possible to make fully, fully, fully automated— like you don't have to deal with caching headers and configuration and so on— if we also exposed a capability for static generation. So today Next.js is in a very exciting place because It kind of marries a world of dynamic server rendering with capabilities for static pre-rendering or static generation. So one of the points of this talk is that Next.js is a technology that is effectively gonna allow you to start with as little as possible and then transition towards more and more and more as much as your business or application demands. And I think it's fairly unique in that perspective. But one of the interesting questions, or perhaps even observations that I've made about the Next.js ecosystem, and I'm gonna contextualize it by going to Next.js examples, you're gonna see that Next.js has also become a quite interesting world of possibilities. So these are all the different ways of managing state, for example. Obviously there's ways of using Next.js with servers. There's— Next.js is a very flexible and powerful tool. And obviously we actually like that a lot. We love power. But with that sort of comes this question of like, okay, where do I start? Right? Like where, what is the thing that I should do with Next to walk that journey of going from less to more? So I wanna basically teach you in this talk some of the things that we've learned about using React at scale, using Next.js at scale, using Jamstack at scale, our own Jamstack journey, what pieces are great, what pieces we've taken, how we've sort of evolved our code bases and so on. And as a consequence, again, I'm not gonna tell you here to like, a gospel of architectures and microservices and reinventing IT. I'm going to tell you concretely that we wanted a fast website and application that is per— that has perfect uptime. I'm going to tell you about how to reuse as much knowledge as possible, both the knowledge that you build up with your own team but also knowledge from the ecosystem and primitives that even web browsers have invented that we should try to not reinvent. And at the end of the day, again, this is about giving users the best experience, not just developers, which is a thing that obviously React has become known for over time, right? Like great DX, hot module replacement, real time, and all these things for developers as well. So luckily for us, it really does come down to following a principle. So I'd like to stick to use Jamstack, use the React platform, and really just use Next.js as your sort of primary engine for your business. And go— going back a little bit about like, how do we sort of end up with this? How do we end up with the fact that maybe you want to use TypeScript, maybe you want to use Flow, maybe you want to use all kinds of different CSS-in-JS technologies? So maybe different CMS providers and, and GraphQL or REST and so on. So And I think actually this is a good thing. So tools are meant to be flexible, especially the tools that developers are working with. So this tweet became viral a long time ago and obviously we all laughed at the time. I probably retweeted this myself, that getting started with React is very, very hard and sort of required a PhD. And yes, I think that React is a technology that has a learning curve. That is difficult. It's also, by the way, it's not just that React is difficult. Here's a sort of a well-kept secret for many is React at Facebook is different from React in open source. That's the reality of the world today, right? So like facebook.com is not built with Create React App. And when you hear about, I don't know, a top Alexa 5 website that implemented React, like Netflix, they also have, in many cases, very complex and proprietary stacks. So the question for you even becomes more difficult, right? Like, I wanna use React, I love the programming model, I love components, I love design systems, I love reusability, I love functional programming, but exactly how do I actually put this into production? And going back to why we have this sort of paradox of choices is that Next.js and tools like it are designed to be powerful. If you're not building something that requires power, I would actually say, well, maybe, maybe actually I should use something like Squarespace, right? At the end of the day, there's ways of putting content online, putting websites online that require no coding and no programming whatsoever. So the key thing is to realize and understand and embrace that if you choose something like Next.js, You want power and you don't want constraints. But what I want to talk about in this talk is how to sort of navigate the power spectrum, how to navigate from your first page that perhaps and very likely will be fully static to 10 million pages that perhaps will be a combination of static and dynamic server rendering and things like that. And when I mean that Next.js is powerful, again, I think sometimes like The word gets used in weird ways, but I want to use it in the technical way, which is I have basically the ability to do unlimited computation, right? So the strict definitional way of saying, okay, it's powerful, it's so powerful that it can use up all your resources, for example. That's what I mean by powerful. I can program whatever I want with it. CSS, from that perspective, is not powerful, right? 'Cause I can't, you know, program data, dynamic data with CSS, but I can with Next.js. So, and both technologies, of course, make the most sense in each place, but Next.js as a whole is a technology that enables lots and lots of computation. And with computation and code really comes a lot of responsibility, and this is sort of the subject of this talk. Specifically with Next.js, because Next.js, by means of being hybrid, allows you to run code at compile time. So the build pipeline, right? Like, you can run code to pre-build pages. Uh, you can run code at two phases within the build pipeline to generate pages but also to compile your components. You also can run code on demand at the edge with server-side rendering or with serverless functions. So more code that can be invoked just in time. Then we ship code to the client side. There's basically code everywhere. With great power really comes great responsibility because those are 4 places where now your code can again use lots of resources, crash, change, mutate, etc. The thing that I've noticed over the years with Power And this is really what has, I think, given rise to Jamstack because Jamstack, especially when you use it with like only static pages, in some ways is strictly less powerful than what has come before, right? So like when you use WordPress, for example, WordPress is computing unless you install caching plugins or whatever, but like the classic usage of WordPress is computing the page for every request. It's executing code in a PHP server for every request. So the obvious question that comes up is, if we didn't know anything about this world, would be, well, then how is Jamstack better? You're literally taking power away from me if you're creating a static page. And you could argue even, like, let's say we're talking to, like, an executive at a company and I'm like, okay, so I'm gonna make you static. And the person would be like, okay, no, my business is very dynamic. Why are you gonna make me static? So static really is a means to an end in sort of constraining power where it makes sense to allow us to be faster, to allow us to render things faster, to allow us to get more reliability. And it has to also be used consciously and strategically. Um, power of course can be so detrimental that it can make us halt forever. And like I said, bring down your entire operations. So the idea of being in charge of this power as developers and make the right decisions for every page that we build is, I think, one of the most interesting things that we're gonna sort of see in the coming years. And because I wanted to tell you the journey that we walked ourselves with Vercel, I wanted to contextualize why we went with some Jamstack choices at Vercel. And it relates to the priorities of our business. So first of all, we put the customer above everything else. This is kind of the guiding principle of a lot of people, like put the customer before your competition, for example. And really, that's what creates the rest of every technology decision that we make, the customer having a great experience. Our technical priorities, if we want to like more technically delineate that, that, you know, customer priorities, first of all, security, second of all, availability, so being online. Third is performance, and four is feature richness. So this is obviously controversial to say, especially for me being a developer, but I will always take, you know, the security and durability of my customer's data over, you know, my ability to have a great developer experience. Luckily for us in Next.js, is setting out to do all of the above. So the take that I wanna give you with this talk is that you're gonna be able to get the three of them, the three of this first by focusing a lot on sort of the Jamstack principles and how do we accomplish those principles? We can do that through Next.js. So in terms of doing more with less, I very much like this quote by the creator of Fortnite, who you might, notice he's been in the news a lot because of his sort of battle with Apple right now. But having been in the industry for decades and creating successes like incredible 3D engines and Fortnite, it's interesting to hear him say that code is basically a bad thing, right? He's saying that code is almost impossible to get right. This has also been my experience over the years. So going back to that example I was telling you, like, why is it better to pre-compute a page and give the same page to a lot of people statically rather than having WordPress, for example, or other serverful technologies compute the page every single time? And one of the reasons is that code, the more of it you have and the more of it you run the greater the liability, the greater it is to make it correct, and the greater challenge it is to make it correct in a universe that is constantly changing. So you might have used the latest code correctness tools that exist in the universe, like TypeScript, like CoQ. You might even have proven your code correct, but something that's interesting is that the universe itself is constantly changing. So When you think about, for example, interacting with APIs and clouds and identity providers and all of these things that are constantly changing as well, and you, and you not always control that change. So when you build a page statically, you've been able to sort of snapshot the universe and all that code that would otherwise run is no longer running. So that's why a lot of what we're going to talk about starts with this strategy of getting rid of all the code. And really, it all comes down to showing up to work this coming Monday and deleting all your code. So you show up on Monday and you tell your boss, I'm gonna delete all the code and I'm gonna check in in 2 hours, check out of work in 2 hours. See you tomorrow. So that's number 1. Number 2 is running less code because in the absence of your ability to delete code, because obviously you don't want to bring your website offline. Let's— I'm going to tell you how we at Vercel managed to run a lot less code. And then again, so like, if you really, really have to use code, maybe you can shift it at build time instead of runtime, which is a really great thing. And then if like there's more code to be run, uh, for really good reasons, and I'm going to show you, uh, good examples of why sometimes it's so delightful to run code on the client side because it enables customer experiences that you would not otherwise be able to do. And really, the strategy in my mind does come down to following this principle of doing more with less. So more complete— concretely, some of the strategies that we implemented at Vercel was one— the first one, I'm going to show you some concrete examples is we switched from SSR, which is running code for every request for certain parts of our website, to HTML. So let's look at an example of this, and I have lots of examples. But so Vercel is a pretty large website at this point, made up of like hundreds, uh, hundreds and hundreds and hundreds of pages. Um, it changes all the time. The last time I gave this presentation, this looked completely different. The content changes all the time. So we're a very dynamic business. We serve thousands of teams that are doing their job every day on our platform. We have lots of teams internally that create content, whether it's comprehensive documentation about our services, whether it's our blog for announcing new features. It's like every time we push a feature to the platform, we update the changelog. Every time we do a— make progress with our infrastructure or blog, we blog, obviously. So interestingly enough, a lot of this used to be powered by server-side rendering, but if you look at it, it's actually quote-unquote static, right? Like, this is a blog post that every time I refresh the page, I'm pretty much seeing the exact same thing. And by the way, this is true not just for me here in San Francisco But it's also true for you that you're watching everywhere in the world. Like, this page is pretty much static. So I'm going to talk about how, like, really it's not static for many reasons. Like, for example, here I have my logged-in session, right? So that means that I'm dealing with a user that is actually logged into a dashboard. So is it really static? And that's why client-side computation is actually a very interesting property to retain. Another interesting one is the date has to be computed according to the time zone that you're in. So actually, we pre-render the parts of the page that make sense to pre-render. So for example, uh, it's Tuesday right now in San Francisco, but at a certain point, maybe, uh, in China, it's already Wednesday, right? So like, we defer that also to the client side. So that is to say that Things that are static need to be meaningfully static for the vast majority of it for me to make them static. So we made this page static, meaning that every time I hit it, um, an interesting consequence by default that I get is that I fetch it always from a CDN. So notice that this page has been cached automatically, it's been served by the Vercel Edge Network. It took 62 milliseconds end to end I'm not even here in a very particularly fast connection because for reasons that I don't want to get into, San Francisco doesn't actually have the best internet in the world, but it's 62 milliseconds to get all the content for this page. And this was basically pre-computed as a static HTML. And that's quite fascinating because in a lot of other scenarios, this would have been a page that every time you go to, goes to an ingress layer goes to a load balancer you maintain in your Kubernetes infrastructure, perhaps goes to Varnish and Redis and HAProxy and NGINX, and then goes to a WordPress server and Apache and mod_php. All of that, why? To give the same page to everyone in the world. So not, not very great. So we went from SSR to HTML, um, and by the way, we did that also, and I'm going to talk about it a little bit, uh, later on not even the pa— not even the pages that are fully static and predictably static, but also pages that contain fully dynamic data. So all of this is changing pretty much in real time. So I deployed my conference presentation earlier to Vercel, um, and you know, this is all very, very, very much, uh, dynamic. But I'm going to show you why it also made sense for us to make that static HTML. We went from CSS in JS, which used a lot of JavaScript code, to CSS, which is code, obviously, but it's not what I— like, Turing complete, powerful, can't halt, can't break, is a slow code. This is one of my favorite things about CSS. Like, CSS can't break, and for the most part, it's hard— it's possible, but it's harder to make it slow. So we actually have a very comprehensive, also Next.js powered component system that the entire company reuses that is basically built of just CSS and people can extend it easily with CSS and it's pretty much a really awesome thing. We went from themes that used a lot of React code to CSS variables and that's pretty wonderful. I'll show you, for example, if I change my theme, I'm just flipping the values of CSS variables. So I believe I can switch here to system theme, and I'm going to go to my preferences and I switch to the dark mode. So every page in our system reacts automatically to the user preferences with just one line of CSS that selects the media theme based on my preferences of theme. Pretty wonderful. No code, I love it. We actually always— and again, I gave you examples of how Next.js will play with so many interesting technologies like MobX and Redux and Apollo, but FervorSell, which again is a pretty interesting website with lots of dynamism, real-time synchronization. You could see that we synchronize the state across all tabs, like the theme and so on. Um, we, we have a powerful feature flags system. It's a pretty complex system, and yet it doesn't use any state management libraries other than React, which is also very compelling. And I'm going to talk about how we accomplish that as well. In terms of data fetching, we don't use code in the sense that we use a primitive that the browser has already created for us. So one of my favorite pieces of technology in the world is Google Chrome, and one of the amazing things that Google Chrome has created is a networking library called Cronet that they reuse across Chrome OS and Google Chrome and Android. The networking stack of Chrome is freaking amazing and you've seen it evolve over time, right? From HTTP/1 to HTTP/2, HTTP/3 is coming. So Google Chrome is pretty much networking magic. So we step, in that sense, we stick very close to the metal. We just use the fetching primitive that the browser gives us and we don't add any extra code on top. And another thing that we kind of learned is in that same paradigm of, let browsers do heavy lifting. And by the way, there's a very good reason for— there's a theoretical reason for letting browsers do the heavy lifting. And the reason is that code loading and code downloading and even paying engineers to maintain code is very expensive. So if I defer to code that Google Chrome has already loaded, that it's already sharing between tabs— so for example, when Chrome is dealing with an input, it has already loaded the code for that input across tabs. When Chrome is dealing with, uh, typefaces, it's already cached the atlas and the glyphs of that typeface across tabs. This is actually why, um, to the dismay of my design team, I not always love web fonts, because I like the idea that browsers have already loaded a lot of stuff and I want to take advantage of that. I want to capitalize on that. Um, but so select boxes are a great example of that because I've been— uh, Phil mentioned I used to be a part of Mood Tools. I reinvented every select box in the universe. You can call me Chief Widget Reinventor Officer, um, in the past. But we've, uh, nowadays we just try to reuse a lot of the things, a lot of the awesome primitives that the browser has created, and then we style them with CSS. So All our buttons are basically native buttons, or inputs are native inputs, or our selects— let's see if I can find a select here. Yeah, cool. So this is actually the native select. Notice, just a subtlety that I'm noticing now by telling you this, is it matches my system theme. So Chrome has already worried about that. And there's all kinds of subtleties, like select boxes can overload sort of the viewport. They're accessible by default. I can, like, type— I'm gonna type S-E and it follows my typing. Imagine writing and being responsible for all that code. So much easier than doing all that is just to delete that code. And, um, and yeah, so when you show up on Monday to your company, you say, okay, by the way, we're gonna delete all this code, red diff, we're gonna use select boxes. 'Cause I saw it in a talk last Thursday. Just kidding, you probably not always want to do this, but most of the times you wanna do it. And yeah, so it's a weird sort of way of saying just use the platform, the web platform, the React platform, and the Next.js platform. So in terms of going from SSR to SSG, one of the advantages that we gained for the blog in particular, and by the way, this doesn't apply to every blog in the universe, This is just our blog that happened to have a set of constraints that made it make sense to compute once and share, basically, right? But we gained a lot, right? Like, instead of being in one region, we are pushing to the edge. So I want to emphasize that because I'm going to show you really quickly that when we work on our blog, we basically sacrificed nothing about the performance and the ease of use and even the ability to change the data for our blog because Next.js has a capability to statically generate pages even after you've built your website. So for example, I have this page, it's called our new edge and dev infrastructure. If I go to my blog backend, I'm gonna open this page, I'm gonna unlock it. So I have my blog data here. Okay, now let me go to another blog post because that's another one. Our new Edge and Netlify infrastructure. So I'm gonna unblock it. So this is the text of my blog post, right? So like I said, it's completely static. Every time I refresh the page, it's the same thing, but let's make a quick change here to show you the power of Next.js incremental static generation. So I changed it. The next time I refresh my page is the change is really not there because it's being generated in the background. Once it generated in the background, it got automatically pushed to the edge like all our other static pages. And then when I request it, you're gonna see that I have perfect edge caching and still end-to-end 60 milliseconds. Thanks to static site generation. It's pretty mind-blowing, right? Like, this is the performance that you would get if you were hosting one of the largest websites in the world. So you're actually— you can be faster than Google. You can tell that to your coworkers on Monday. Okay, so we have these pages built statically and pushed to the edge, meaning that we don't depend on any given region being online. Were completely globally distributed. And all we had to do was instead of using getInitialProps for data fetching, use getStaticProps. And with getStaticProps, you can fetch data from anywhere in the planet, any CMS, whether you use, uh, Dato, Prismic, Agility, Sanity, Strapi, even Notion. Just use getStaticProps and you can use fetch inside and get your data. CSS in JS to CSS is frankly very easy. Uh, with Next.js 9.2, we allow you to import CSS. Themes to CSS variables was also very easy. We just use CSS variables. Uh, SSR to client-side data fetching is a very interesting one because, as I mentioned, um, there is always interesting data to fetch on the client, right? And one of the cool things that we do is that, okay, when we switch from SSR to SSG We obviously lost the ability to render the user state on the server side, but that doesn't mean that we can't render it on the client side in this case, and we can do so in a very lightweight way. So a great example here is if I log out and then go back to my blog, notice that like I'm, I'm rendering— basically this is how it's coming from the edge, right? Like no logged in state. Now every other instance of my application will be synchronized because it's, it's basically fetching the data on the client side, right? So I'm going to log in again, um, to my dashboard, and then notice that now I'm logged in here as well. This is the power of transferring code that would otherwise been confined to the server to the client. It's a very dynamic experience And I can sort of change the data as I go through the system. My apologies. So that was one of the benefits of moving from SSR to client-side, in addition to obviously not running servers for every request, which is absolutely wonderful, saving a lot of cost as well. And it makes a lot of sense to do so when you have private data, for example, like the logged-in state in that page. At build time, we fetch code with fetch. At runtime, we fetch code with fetch and SWR. SWR are React hooks for data fetching. I haven't updated this link, but, uh, uh, swr.vercel.app is a very easy way of fetching data on the client side when you have static pages like the examples that I just gave you. One of the beautiful things about hooks is that they're reentrant. So when you choose your data fetching library, one of the things that I always keep in mind is data is constantly changing, right? So it's not a one-time thing that you fetch data and you're done. So one of the nice things about SWR is that concept of reentrancy. So when you— when, when we fetched user data here, we were able to reenter and re-execute the hook later on when the page gained focus. Which is really nice. And that obviously gives us the best possible user experience, right? There's no global store, there's no global Redux dispatching. The code looks synchronous, which in my opinion is a miracle of hooks, right? You couldn't possibly make this code any simpler, at least for this simple case, right? This easy case where there's not even an await keyword here, right? To me, this is a pretty magical thing. So the code looks synchronous and it works with any backend. So when it comes down to choosing your backend, we built our entire sort of Next.js-based architecture in a completely backend-agnostic way. So for building Vercel, even our more complicated pages, we just use HTTP APIs. So everything that gets rendered Notice how that, thanks to SWR as well, all the back interactions are instant because the data has already been cached and they revalidate sort of in the background. So to show you an example of that sort of real-time synchronization in action, I'm gonna go and I'm gonna delete a project. So I have my project here, it's called Build 15,000. I'm gonna delete it. Notice how all these clicks, uh, they're going through different Next.js pages, but they feel like a single page application, even though these are all individual HTML pages. Notice that like the sort of skeleton when I load this page is unique to this page. There is no global monolithic app with Next.js, which is another really interesting advantage. So you don't see a global spinner. You don't have to download a monolithic codebase. Each page is its own sort of mini universe. So if I delete this page, what happens is I'm gonna focus back on the page that had the project. SWR, upon focus, revalidated the project fetching, revalidated the events fetching, and now everything is in perfect synchrony. So much so that if I go to projects and I go back, the data is also consistent. And if I go to projects and I go back, scroll state is also memorized. All of that is possible with Next.js and this tiny library which is less than 4 kilobytes. Um, you can go to SLA to the Vercel app and then usage with Next.js will sort of guide you through all the things that I just sort of covered here. Um, so where do we go from here? I mentioned in the beginning that, uh, I like the idea of embarking on a journey. A lot of you who are watching are going through, um, perhaps making decisions for a new application, a new website, a new e-commerce front-end technology. So you're choosing, you're making new decisions today, and my recommendation is to go from less to more, to start minimalistic, to start static, to start Jamstack. But over time, you want to retain the optionality— excuse me, the optionality for more. So because the world is not just static, and Next.js lets you progressively become more dynamic. So just like you used getStaticProps, you can also switch to more complex server-side rendering over time if your application needs it. And you can sort of start simple, go more dynamic as needed. So what are some ways of going more dynamic? So I mentioned here that, uh, when it comes down to my blog, it's, it's pretty much the bulk of the content is the same for every single user. If that was not the case, then server rendering would have been a more interesting choice. So for you, it's a matter of switching from getStaticProps to getServerSideProps. So notice how Next.js is basically letting you select on a per-page basis the data fetching hook that builds the page, and with one line of code, you can entirely change, um, how that page works. If you need APIs that do dynamic data fetching on demand, you can create dynamic API pages. So you just create a file inside Pages API and boom, you have dynamic APIs. And then you can even, especially as of Next.js 9.5, you can even— so sort of stitch applications together. Because for a lot of you, you're not necessarily working on projects that start from scratch and you're sort of trying to strangle existing codebases or sort of stitch codebases together while you let Next.js take over more and more and more of your pages. So imagine that, uh, Vercel.com was a website built with Webflow, but I want to build some other pages with Next.js. So starting with Next.js 9.5, you can sort of do this. You can say, uh, Next.js, please serve a subset of pages via my old system, and new pages, like for example, uh, iron-solutions/next.js, I want to build this from scratch, uh, with Next.js. So you can also do this as of Next.js 9.5 very, very easily. So, um, to, to get started with this, uh, journey, uh, that starts with, you know, building your first static page and your first blog and then progressively becoming more and more complex, I recommend the Next.js tutorial. Super cool. Um, we let you with one-click import your any repository with any framework that fits this sort of Jamstack constraints deployed on Vercel. In fact, when I was showing you sort of our dashboard, that's precisely what this is. This is how I deployed this actually Gatsby-based, uh, deck, um, to, to Vercel. And then, um, I think, oh, it synchronized all my slides. And then finally, uh, you can follow me on Twitter where you'll sort of continue learning about our journey on twitter.com/rauchy. Yeah, thanks a lot for following along.

People are flowing in. Wonderful. So that doesn't give you very much time, Guillermo, to take a breath after a lot of words. So thank you for hopping in here so quickly. There's, I'm sure, going to be plenty of questions along the way. But I have to start with my first one. Go to work on Monday and delete all your code. Whoa, that's bold. I love how bold you are with that one. I suspect we'll get feedback.

Yeah, yeah, I really mean it. I think it's obviously a catchphrase, right? And I do think that sometimes deleting code also means putting it in the right place it belongs, right? What we've really accomplished with Next.js is giving the developer— well, I need to run this code at build time and then never again. Or I need to run it at build time and I need to enable— and I need to run it at runtime for previews with my CMS. So, like, take the code and decide where to run it. In a lot of cases, I do think strictly deleting code is a wonderful thing. We've, we've talked to lots of different users of Next.js, and like, it's always interesting to see, like, how much code they invest in things that, for example, add a lot of bloat to the client side and really accomplish the same user experience as another app that we see that has a lot less code on the client side. So that's another great example. Or as I said, not using platform features, right? Like Chrome loads— like, it's impressive, right? Like Chrome has written a lot of code themselves, right? The Google Chrome runtime is absolutely massive and native code has this capability of booting up and running really fast. So when you boot up Chrome, you're basically loading a lot of code into memory. When you use different web browsers and, sorry, web pages, you can get to reuse that code later on. So that's the angle where, you know, just use the platform becomes kind of a thing that's impossible to ignore.

Yeah, I mean, just use the platform is a wonderful sentiment. I totally agree with that. And it's interesting because you quite rightly called out as well, you know, Jamstack isn't really a stack. And yeah, that's fair because, you know, naming things is hard for sure. And I know that when Matt Billman kind of coined the term, he was talking a lot about the stack moving to the client. And exactly as you just described, you know, the runtime that Google, that the browsers ship with now is immensely powerful. And so kind of the notion of the stack kind of moving a bit closer to the client so that you can have the runtime be there rather than in your traditional stack, I think is kind of one of the things that was, was kind of being, being mooted there. But I really am excited. I think in the same way that you are about the things that are possible now that we can bring services in through these APIs. I mean, you, you talked about, you know, bringing things in through Notion and all of the other, you know, so many CMSs that you kind of rattled off so fast because the whole CMS, like headless CMS economy has just exploded. So I'm kind of curious, moving so fast and APIs are such a big part of Jamstack. What are, what other APIs are you excited about? So there are other kind of tools and services that you think are really changing the game and saying, well, now we can start to build things in this model because these capabilities are things that we can pull in from APIs? What are game—

Yeah, for sure. I think two things are happening that are really interesting when you, when you think about the developer tools economy. One is the API side, which obviously has a very interesting explosion of tools, especially in e-commerce. We're seeing it over the last year or so. Headless providers for e-commerce are really exploding. I think it's only gonna accelerate with COVID Obviously, there's an enormous amount of demand for content, so headless CMS is also rightfully getting its deserved attention. The other interesting trend that I'm seeing is kind of, and something that we're exploring with Next.js as well, is sort of like federation of frontends. So, consider this, right? When Stripe came out, you would make one API call to do a charge. That was sort of like mind-blowing first moment with Stripe. Fast forward to today, they can no longer give you that mind-blowing experience. And the reason is simple. The world has become more complex. Payments are now a state machine of payment intents and regulation in different countries and approvals that are necessary by the consumer and so on. And so there's sort of this accumulation of complexity has happened to the payment world. So what I'm seeing from my side is that sometimes APIs are not enough to bring the desired level of simplicity that the developer needs. So I'm also seeing this new trend of we'll give you parts of the front end in a box as well. So we're seeing this with hosted experiences, for For example, Auth0 will give you a hosted login page. Stripe will give you a hosted subscription management page. Fast will give you a hosted mega optimized checkout page. And I think this is kind of this sort of evolution of the frontend world, but perhaps it's not as obvious to developers yet. It certainly wasn't obvious to me because I always come from the place of like, I'm in charge of the entire front end and I've written all of it or my team has written all of it. And that's why the API economy and headless CMSs were so interesting because demand was for people to write all of the front end. That's why we chose Stripe. That's why we chose a headless CMS. That's why we chose a headless e-commerce API. But now I think certain parts of the stack are gonna get more complex. Especially as it regards to user interactions. And it's not gonna make as much sense for frontend developers to always reinvent the wheel. So what's interesting is that Next.js can sort of also become the central place for federation of frontends, not all of which you or your team have written. And if we're able to do that in a first-class way, then I think that's gonna become really interesting. It's gonna propel us into the next sort of wave of reusability. Imagine if you could reuse components that Stripe has written, but not just like in a, in a super opinionated way or like a small way, like really bring entire experiences. The same is true for teams collaborating inside a company, right? Like we talk to like massive e-commerce websites where like there's entire teams dedicated just to the checkout page. So in the future, I think they'll be able to sort of interrupt with one another as if they were customers of one another, which is really cool.

Yeah, and I, I certainly agree. And I think it's interesting that you kind of highlight the front end there and say, OK, well, you know, we're, we're pulling in the capabilities that other people have built for the front end. It still feels like we've, we've got some minds to change a little bit about that at the back end as well. I mean, identity is a great one to call out. I mean, I'm delighted to not have to build an entire identity provision system on all of my projects, you know, as a developer. But I think that, I think particularly I'd be interested in your, in what your experiences have been here, but I think that particularly large enterprises who maybe have got a lot of sunk cost in their infrastructure and their, you know, research and their development before, they're used to saying, well, we need identity for these sites, we'll, We'll build it here. Yeah, yeah. Now to say, well, you don't have to do that. You can get an entire team of experts with all of the support capabilities behind it. You mentioned people like Stripe and Auth0, of course, for identity, and pull that in. How are you finding conversations with particularly big companies where you're advocating for that and saying you don't need to build that here, you can use API services? Are you, are you finding that Is that an easy conversation or is that— do you think we've still got some opinions to change there about that?

I think you've probably seen this with different teams across the Jamstack and serverless space. Different teams have different opinions on what full stack means, right? And like there are people that are saying, well, you have to— you can now do full stack serverless, right? I feel like that is a conversation that is hard to have because it means, okay, now you absorb all the responsibility of every part of the infrastructure with a new endeavor, with a new platform, with a new framework. I like the idea of the incremental approach. I think Jamstack has done a great job there with saying, look, the API can be any API. And this actually allows me to answer one of the questions that I'm seeing, which is like, "SWR will work with any React project." Absolutely. And any API as well, right? Like, you don't have to have written the API. You don't have to have ported your API to be GraphQL or whatever to take advantage of these benefits. I think that's the true spirit of Jamstack that allows you to have an easier conversation there, which is like, "Hey, we already have an auth API. We already have a data API. We already have a payment API," and so on. Let's leverage that investment, not throw it away, not reinvent the wheel, and modernize through reinventing the user experience, which at the end of the day is what matters the most. The conversation is a little easier when you talk to companies that are in the process of their mobile transition, right? Like a lot of companies that had to put out mobile clients like iPhone and Android native applications, already have an API there, then they can use, you know, any of these technologies so easily, you can adopt them so easily. Now the real, the really meaty question is, I do think that there's a future where front-end developers take more and more of the sort of API responsibility. So that's why we built the API sort of routes functionality into, into Next.js, which They become serverless functions when you deploy, et cetera, et cetera. That might be a harder conversation, like, should I be responsible for maintaining my identity service, for ensuring that it's secure over time? There's a wisdom in the security space, which is like, never roll your own crypto, right? Reuse crypto that others have vetted. I think there's a lot of truth to that to back it. Yeah. Don't roll your own identity, right? Don't roll your own data encryption layer, et cetera, et cetera. So that's a very strong case that we're gonna see for hosted backends as well, especially when end-to-end encryption is a requirement. I think that that's gonna be a no-brainer of sorts moment for a lot of people. Yeah.

Totally. Yeah, I never want to have to roll my own of some of those things. It's interesting seeing Carlos in the chat kind of frustrated at the naming, and that's totally fair. And Carlos, I think it even goes even— gets even worse when you think that, you know, Jamstack sites don't even really need to use APIs or use JavaScript really. I mean, you could argue, and I think you were kind of talking about this in one of your examples, Guillermo, I was like, where, you know, where did we come from in the first place? You know, websites were pre-generated at the beginning, at the, at the very start, you know, we, we were creating something that was static and putting it somewhere that was optimized to serve them as static resources. And I kind of think of that now still as a Jamstack site. You know, it's a, it can be served directly from the CDN with all of the advantages you were talking about, being able to serve things directly from the CDN, the things that you can then start layering on top of that. Really mean that you need a bit of a vocabulary to be able to talk about these different type of sites, right? That's— it becomes really hard to talk about static anymore.

Yeah. One of the things that, uh, we did as we sort of endeavored to optimize our sort of static pipeline more and more and more and more is that we realized that, sure, as Carlos points out, these static files are being served by servers, But actually, once you start getting to the, uh, uh, um, details of how to serve static files at scale, you find that the server that is tasked with serving a static file and the server that is tasked with connecting to a microservice mesh and a Kubernetes networking fabric and microservices and so on have drastic different amounts of complexity associated with them. And the static one has optimizations that are only possible once you know that the artifact is static. So there's an easy take to be made about the serverless world that is, uh, you're just hiding the servers, but there is more nuance there, which is when you use modern frameworks like Next.js, when you run the build process, The fact that a platform like Vercel can say, well, these are HTML, I know it, and these are serverless functions, I know it, produces vastly different sort of complexity profiles and optimization possibilities for the edge network, which is a long way of saying that it's hard to beat a platform that knows and optimizes for static and functions. It's very hard to roll that out yourself. It's very hard to expect the same capabilities out of a simple server like the traditional one, the container and all that. So that's one of the things that we don't really talk about that much because it really starts getting very technical. But I think at the end of the day, both developers and users experience it. You feel that, oh, why is it so consistently fast? Or why are deploys so fast? Or there's all this sort of ripple effects of going into this architecture. And I think it's just been one of those consequences of Jamstack, right? Like, it's that kind of ripple effect of like the world reconfigures itself once we say that this is the foundation.

Yeah. And I kind of think as well about it is so common to hear people say, but there are servers in serverless, you know, and And of course there are. And I, I like, I like to think of it in terms of what's in my problem space. So as a developer, as someone who's creating a site exactly as you're describing, you know, they, all of this infrastructure exists, but if I can be abstracted away from it, so I don't need to worry about managing it or even really caring about the notion of it, that, that changes things so, so drastically because of course CDNs are not new. CDNs have been around for a very, very long time, but the, but they were not really in reach of many people because the complexity of managing them is difficult. How do you figure out what's in the CDN, what's cached, what's the cache miss?

One thing I found with a lot of bigger customers is they think they already have a CDN because they went through the journey of I have a Serverful app and then I placed some assets in the CDN. So like they were, oh yeah, I already got, Akamai or Fastly, look, all my images are served through Cloudflare. You know what I mean? And then you realize that that's where they thought it was a checkbox. Whereas what we're proposing is that CDN is a fundamental architecture compute substrate and sort of deployment layer. Like it all starts there. And sometimes you deopt from the CDN, right? Like the case of like when we execute functions, there's nothing that the CDN is doing other than terminating SSL close to the customer, right? But other than that, it's just like the CDN's doing nothing. But even then, the fact that you kind of have this CDN-first architecture, that's what I think makes a huge difference. A lot of people think they have a CDN. We see this a lot with customers where we notice that they were paying large bills for CDNs and then the CDN was just piping traffic to the server and doing nothing. Yeah. Like they thought they had a CDN, but actually they didn't have any sort of acceleration whatsoever. And, you know, like at the end of the day, like there's so much you can do with like letting people know and running lighthouse tests and tweeting, hey, please configure your CDNs correctly. I really wanna leave that world behind. And that's why I like this sort of like CDN by default mentality that we're all pushing for.

Absolutely. Yeah. I, I, I, yeah, I love that mentality as well. There's, um, uh, someone I've worked with in the past who, who, uh, who'd often described his sites as static, static first, kind of similar to CDN first, which is definitely a mind shift, you know, from what we've traditionally been thinking of for sure. And yeah, I, one of the comments you made that I really loved that I kind of jotted down was like shifting code from runtime to build time is a great thing. And so that you can serve things more directly from the CDN without needing to worry about the logic. And so that, That's something I was trying to get my head around a little bit as well, because something that brought me to, to Jamstack was the notion of doing as much ahead of time as possible so that I wouldn't need to worry about it later. And of course that has some performance benefits that you talk about, but I also found that it helped me kind of maintain the logic of where the moving parts were at any point. So you can kind of roll back and do various bits and pieces and deploys could be immutable and things like that. The more complex or more demanding the experiences are that we build on top of that, we start to add other things to it as well. Where do you, where do you see that going? Because I, I think we can start to do really clever things with kind of edge, edge, edge handling, kind of functions at the edge that are serving things on demand at the edge and what have you. There's still no server involved, but the, the logic of the system becomes a little bit harder to reason about. How, how do you see the trends of that working out and how do you kind of reconcile the Do as much rendering as you can to begin with and then augment and enhance. How do you see that playing out?

Yeah, I think that's where Jamstack really will have its sort of second wave of innovation, as you said. There's all kinds of different approaches that are coming to the market, like running more logic very, very close to the user at the edge. There's more capabilities that you can add to CDNs to do differential rendering. Like saying, oh, you know, for this particular cookie, I want to serve this set of precomputed pages. But the reality is that there is sort of a cutoff point where you have to say, well, you know, I have to either render very, very dynamically in the client or switch to a more traditional SSR architecture, right? Our take with Next.js is that I think that cutoff point We have to, as an industry and community and sort of tool makers, we have to push it off as far as possible because the benefits of prerendering first and foremost have to do with customers, right? Like my take has always been SSG, static site generation, is basically just SSR at build time. And if you do SSR at build time, no visitor ever is eating that cost, whether it's cost because it's slower or whether it's risk or whatever, right? So like, it's such a good thing for visitors that we have to try to pre-render and push the limits of the technology as far out as we can. Now, it is true, however, that sometimes, you know, there are limits to pre-rendering. Like, I want to customize a component based on an experiment to a certain cohort of users and then I wanna roll it back dynamically and I don't wanna spend any time whatsoever redeploying. So those are the scenarios where we're working on adding more and more capabilities to Next.js to make it powerful enough that it can suit those use cases that are frankly very, very advanced. I think in this modernization process that we're all sort of going through throughout the world, Most people, I think, will fit— I would say 90% of websites will fit within the pure prerendered, then some will do hybrid prerendered, and then honestly, there's always gonna be sites that need so much customizability, like facebook.com, that need streaming server rendering. So I think the most important thing is that the developer can navigate that power spectrum. And I would say Jamstack first is probably the best way to navigate it.

Yeah, I think you used the words like complexity spectrum or something along those lines in your talk.

Power spectrum, yeah.

Power spectrum, yeah, which I really like. And you know, there's like the principle of least power and trying to, you know, make sure that you use the least powerful thing to solve the problem along the way, which you kind of touched on really nicely. So when it comes to this approach of like trying to render as much as we can out ahead of time and then have these various ways that we can do progressive enhancement either in the browser or somewhere between browser and server. What do you think are the biggest hurdles for convincing big customers of that? Because I think a lot of people have come to this and said, oh, that works fine for my project. And then the bigger the company that looks at it, the bigger investment they've had in a different way of working and they, I don't know, it's harder to turn that ship. What do you think are the biggest stumbling blocks along the way for that that we need to overcome?

I think one has to do with where the business is today. Right? So, like, where are they in the evolution of their frontend, for example? So a great example is prior to the conference, I just had a call with a massive .com where the developer team was already convinced that their site was fundamentally static, right? They had some plans in the future to add just-in-time dynamic capabilities, whatever, but they were like, "I really like this technology because 90% is static. We should make it static. Let's go." And this is a .com which is in the Alexa top 10,000, very high traffic. Very high stakes decision-making process, et cetera, et cetera. So you kind of want to meet the customer where they are, right? Like they already understand what their frontend is like today and they already understand their pain points really well, right? So like a pain point for them was performance, just like they were disappointed with the entire sort of performance spectrum from build to like, rollouts, slow rollouts with containers, to why we've been running containers, Java server startup times, legacy CMS choices, etc. Now you might have customers that are much, much, much further along in the complexity spectrum, and that's where, you know, giving them the tooling for that power to be added on top of the more traditional fully static stack really become stable stakes because it's very hard for a— for companies to regress in terms of where their business is. So great example of this is large e-commerce websites that have chosen Next.js because they have their entire future stake in the ability to customize and serve recommendations and experiences to each customer. Whether it's what they visited before that influences the new recommendations, whether it's ads that they've been exposed to, et cetera, et cetera, et cetera. So in those cases, the justifiability of, oh, let's just go static, in their minds, they're like, sure, but that's not really my pain point today and maybe you're weaker on this side of things. So that's why Next.js having gone hybrid has been a very good sort of solution for covering a lot of that power spectrum.

Yeah, yeah, we're almost out of time, so I'm gonna, I'm gonna shoehorn one last question in if I, if I may. Because you, you showed like that, you kind of refer to styling like browser components, and I think my palms went a bit sweaty when you did because I think I've been down that road before as well. One of the misconceptions I've heard a lot when people first hear about kind of Jamstack is that it's pushing everything into the browser. So you, you're right, only, and of course it can be this, but it's not this and only this. It means that you're doing everything in the browser with JavaScript and it feels like it's kind of getting into some of that territory that you were kind of warning of and saying, you know, we don't need to re-engineer all of these components and what have you. How do you think we safeguard against that? How do you think we, make sure that people do the appropriate thing in the browsers the way that browsers already provide it rather than reinventing things with JavaScript?

Yeah, so, uh, there are two components to framework design that ensure that you always do the performance thing. So one is pre-configuration. So when you use Eleventy, when you use Next.js, those teams have already pre-configured a lot of awesome things so that you're fast by default. But again, we are dealing with code and code is powerful and code is, you know, can be so bad that it halts, obviously, but it also can be medium bad that it's kind of awful, right? Like, I always tell the story of like box shadows used to be the thing that was slowing us down the most for a certain page that we built. The Facebook team For new— facebook.com, there's a great post about their usage of CSS. I believe even in 2020, they still use, like, images for a transparency or a shadow. I can't remember what it was because they found that a bottleneck was in how they were painting something with CSS, right? And this is the thing we're dealing with today. So everything is so powerful. It's almost like if I gave you radioactive paint to paint your home and like all of a sudden like your home is like radiating energy to you. It's like such powerful paint that it's awful. I think that's how a lot of our technologies can be sometimes. So, uh, you can't just do pre-configuration. You can't just do, okay, Next.js gives you great perf defaults, you're done, we're done. No, the other piece of it is conformance. So conformance is you want to stay within your lanes of power and performance. So something that will give you feedback back about what are your Lighthouse scores over time, what are your page loads over time, what are your bundle sizes over time, what are your critical product metrics, right, over time. Like, you know, you deploy a new feature, you deploy a new CSS module, you deploy a new Jamstack thing, What was the time to painting the buy button if you're dealing with e-commerce? So my— as kind of a closing note is that if you as a developer take the most holistic view of performance possible, which is I load a page and then it paints the thing that I need on my screen, and that's kind of your take. Because in the presentation I showed how awesome it is that I can download my blog Faster than you can load google.com. Awesome. But what if my blog has a, you know, while true or lots of expensive CSS or whatever, right? So at the end of the day, we have to not be satisfied with the same defaults that Jamstack or, or these frameworks are giving us and really take this holistic way of, of understanding performance.

As you said in your talk with Great power comes great responsibility. There it is. Guillermo, thanks so much for all of your time and for answering all of these questions and for a great talk. I think we can give you a breather now and we'll head back to the main stage. So everyone, your thanks please in the chat and elsewhere. Thanks once again, Guillermo. Thanks a lot.

Thank you so much. Thanks.