Guillermo Rauch - The post-Jamstack world and the rise of Hybrid Frameworks

Hello everybody and welcome to my talk, which is titled The Post-JAMstack World and the Rise of Hybrid Frameworks. My name is Guillermo Rauch and I'm the CEO and co-founder of Vercel. Guillermo Rauch, the company behind Next.js, the first JavaScript hybrid framework. As a company that builds a lot of tools for building great experiences on the web, you wouldn't think that we'd start with a slide like this, but I'd like to say that we have a lot of work ahead of us because the web is in jeopardy. When we look at the median web experience on the web, and some of the most popular websites in the world, we still have a lot to do when balancing the ability the web gives us to publish really fast with delivering great web experiences with great performance at scale. So take a look at this example from not too long ago. This developer was just taking a look at what a website with GDPR-infringing scripts was doing in terms of performance. First Meaningful Paint, meaning the first time you got to see the thing that you were interested in on your website, 14 seconds. Guess what? You remove all the additional stuff on the page and you go to a Meaningful Paint of 2.9 seconds. So you go from 45 seconds to 3 seconds and from 500 requests to just a few requests by just removing all the extra scripts you had on the mobile experience. If we look at the performance of the web over recent years taken from the Chrome UX Report, you'll see that things have gotten better but not to the extent that we'd love to see. If you look at just from that tweet, 2018 to today, Things have only just so slightly gotten better. Improving, but I think we have to do much, much, much better. And also when we talk about the web, I think it's super important we all get on the same page, no pun intended, about what is the web and what kind of web are we building for? So I like to start by saying that the web that I wanna build for is global. If you look at the page load times by country, you're gonna see that there's some surprises there. When you look at the data collected from India in particular, you'll see that it's almost twice as slow as what you see from Korea, for example. But on the other hand, India is one of the fastest growing countries on the web and one of the fastest sources of unicorn internet creation. Number 2, the web is mobile. So that example that we just looked at was a mobile example. And I think this is really important because again, when we talk about what is the web and a framework for understanding it, I like to talk about this, what is the average device that we can look at for the web? So the Xiaomi Redmi 9, as Josh talks about here, is the most common budget smartphone in this country, India. What he went ahead and did, which I found really interesting, was he compared the performance of an iPhone and a Xiaomi Redmi 9— Redmi 8 that he got so that you could start to see side by side what it's like to experience the internet in India and to experience it in perhaps the US. You're going to see that to start off, single page applications have quite a different performance profile in terms of like looking at spinners for a long time. And he mentions in that tweet thread, which I found really enlightening, that things get problematic when you visit news sites because of all the tracking snippets and such. He says these sites take forever. He said, you know, Twitter, which is already quite optimized, was quite much slower on a Redmi phone. But if you look at what you're about to look at, I think it's gonna be more insightful and you're gonna get a new appreciation for what it's like to build for the web at large. So noticed he tapped on the two links again at the same time, but it only— it just responded. So again, he taps at the same time, the iPhone's already loaded, and as I'm talking, this mean device for the world. So the average device of the world to like 10 seconds or so. One of the things that he points out is that ad-heavy websites were not performing really well. We're gonna get into that later. And interestingly enough, React apps that were server-rendered or pre-rendered capabilities that come out of the box with Next.js were actually performing quite well. And that the problem, he says, largely goes away. So, and the other really important piece is that the web that we wanna build for is global, is mobile, and it's not evenly distributed. So what I mean by this is we can think of the web as having 3 major cohorts or a distribution of what I like to say, it's a dragon with a head that represents 33% of global page views. So there are 10 websites that represent 33% of global page views. The next— the body or torso of, of this distribution is the next 10,000 websites. So this 10,000 websites also represent 33% of global page views. And then there is a very long tail of up to 3 million websites, and this long tail is twice as long on mobile devices. That represents another 33% of global page views. So when you think about this, you realize that when you build for each of these cohorts, there's a different kind of demand in terms of performance and in terms of engineering resources that become available to you, right? So if you're building for the long tail of the web, you find a lot of smaller apps, smaller websites, and you start noticing some distinctions in the approach that you would take to engineer for these three cohorts. So one thing that I've noticed is when you are building for the tail, you're building something that fits really well the sort of engineering profile of purely static Jamstack static generation. So you have only a handful of pages that are full static, not personalized at all. What happens as you sort of traverse into building for more and more sophistication on the web, start realizing the opposite experiences are more dynamic. There are many pages. They're hyper-personalized. And this transition fits really well what we might decide to use as the tools to build for each cohort of the web. So when we think about building for a web that's global, that's mobile, and for what cohort of traffic and size of website we're building for, we make better decision for what kind of tools to use. So when the site is large, the more likely it is that performance matters a lot. So to Josh's point earlier, a site that is pre-rendered with Next.js will do better when performance matters a lot, for example. And the interesting thing is that what we see is that when we notice these large sites, like the ones we looked at on that Redmi Note phone, performance is actually not great today. And this is why the web really is in jeopardy because the hyperlinks that you get from the most common websites that you're likely to go to is when we notice that performance is not really that great. But you notice that at the top of that distribution, those top 10 sites, Facebook, Google, Amazon, those sites are actually doing extremely well, right? So they've created a lot of the tools that we use, a lot of the best practices that we use. So Facebook created React, for example, Amazon's e-commerce business continues to do extremely well year over year. I think they've been obviously playing with some advantages, right? In a lot of cases, these are the companies that have massive amounts of engineering resources just dedicated to front-end optimization, for example. So there's, there's a delta there, obviously, because those have been performing well. Then you look at this Tours of the Web, you it really has not been performing that well. So what is the delta really? And when we studied that problem, we realized that one of the main issues is that a lot of websites and a lot of teams outside of that top 10, they had never gotten a cohesive front-end development process with tools that were designed with performance optimization in mind or tools that were very easy to deploy such that you could test in production what the end results were gonna be like. So that takes us to the second point that we observed. A lot of those websites were building with the backend in mind, and then they sort of started thinking about frontend as a last, you know, like sort of let's add some interactivity, let's add some jQuery to the pages. So they weren't really thinking from a performance standpoint from the very beginning. And as this legacy codebases would evolve, The developers were having a lot of trouble taking new ideas and new initiatives to production. And finally, whenever you would have something that worked really well, it'd be really hard to reuse that thing that you built that worked really well. And this is where the React component introduced a lot of goodness into the world so far. When you build a React component, when you build a Next.js page, you're very likely to be able to now reutilize it and learn from prior work. So our approach to fixing this is twofold. So on one hand, we have Next.js, which is a framework, gives you an incredible development experience, a lot of the best production practices out of the box, and then a platform that puts into this mindset of constantly being able to test and validate your hypothesis in a production environment. So our take is that development these days cannot just stop at localhost. You need to continuously bring the deployment of your ideas to, to a global cloud. And one of the things that we notice also looking at the data is that the cohorts where Next.js, our framework, is growing the fastest happens to be in the head and torso of the web. So Next.js is a framework that's been able to power very little things like my own blog, RauchG.com, but also scales up really well to power a lot of the largest websites in the world. So it already powers more than 11 of the 100. This data is slightly behind our latest figures, 75 out of the Alexa Top 1,000, and also a growing cohort of the Alexa Top 10,000. And as I mentioned earlier, a lot of what we've done is fix those 3 areas in which we think we can help companies and development teams very quickly and effectively bridge that gap to the tooling and infrastructure that an engineer would have at Facebook, Google, or Amazon. For us, it all starts with this mantra of develop, preview, ship. So we intend to give you a framework that, as I said earlier, you make an investment into, and it's almost like a stock that continues to pay dividends. As you make that investment over time. And we think it all starts with the innovation of React, where you invest in a component and then that component is reused across multiple Next.js apps, multiple Next.js pages, and it just keeps getting better and better. And when you make an improvement to it, kind of like the Tesla approach to cars that teach the self-driving engine how to get better by getting data points out of the world, every time you improve a component, the whole company learns from it. As I said, it's also very important to validate hypotheses with your team in production with the right infrastructure that simulates production infrastructure as soon as you can. So this is where the Vercel side of things comes from. When you push to Git, we give you a preview URL. In this case, it looks like shop, get new checkout, that Vercel.app. Sarah pushed, she got a PR, she got that URL, and then she's able to share it with the rest of her teams— the design team, the marketing team, the product team, the accessibility team. Everybody can really comment on how this new experience is being created or improved, evolves over time. And then we think that performance at the edge, performance in the global CDN in 2021, it really is table stakes. The expectation is, as I said earlier, the web that we're building for is global and is fast in North America and is fast in India. So what we do is we take your frontend, we take your pages, we take your assets, and we automatically terraform the world as you push. And we guarantee extraordinary performance. We make caching automatic. So developers don't have to worry about the hardest problem in computer science, which is caching validation, and everything is just fast out of the box, and the infrastructure that's underlying this continuously improves. So I think it's important to reflect on the fact that frontend development in 2021 is not just an npm package. It's an npm package and it's your ability to wrangle automatically global cloud infrastructure that ascertains that your performance is extraordinary out of the box. And I think we're getting into this point, okay, like, I shipped, develop, preview, shipped, what's next? What, what am I supposed to do next? And I think this is really interesting because we really need to make sure that you get into a feedback loop that allows you to continuously improve and validate hypotheses over time. And this is what we're headed towards next with our new step of iteration. And one of the key ideas of iteration, one of the key principles that informs the design of our framework and platform is this idea that you have to focus on reality to improve. And the focus on reality, we think, is a very important condiment of what we call this post-JAMstack world. And the reason for it is that a lot of the attention and intrigue that went into pure static solutions or static generation and a lot of those techniques was that what we believe to be an oversimplified model of reality. And the idea of this oversimplified model of reality was that in order to be fast and in order to give a great experience to everybody in the world that's running businesses or sites that are attracting lots and lots of traffic. The idea was going to be, okay, if you are able to create HTML at build time, meaning you pre-generate every page and you then put it into a CDN, then the only other variable that you have to worry about is how much JS your own framework or your developers add to the page. So as long as they do static generation, as long as they make sure that I'm not using Moment.js and I'm using date-fns.js, I must be good. Okay, in reality, we find something that completely defeats that oversimplified model. So first of all, CDNs are, as I mentioned earlier, table stakes. Absolutely great. The vast majority of website networks these days support them. Vercel itself has done a lot to automate the CDN so you don't have to worry about it. It's just, again, it's there. But we think that performance starts with a deep, deep, deep list of concerns, not least of which is something as basic as CSS, for example. So I like to give this example because it kind of brings together all the ideas that I was just talking about. So the example is when Facebook was starting to roll out the new Facebook, which was entirely built on React. Previously, Facebook was built on not React, it was built on little bits of React, but also PHP with server rendering, with a lot of other technology on top. And one of the things that an engineer noticed, his name is Ahmad, when the new Facebook was starting to roll out was that, uh, they weren't using box shadow and they were using an image. So like, he was kind of like going around with like DevTools and he knows, wait, that little bar at the top is using an image instead of box shadow. That's really strange. And this is strange because, hey, wait a second, as I mentioned, top 10 site of the web, uh, responsive for up to 33% of page views. And creators of the most amazing technologies in 2020 releasing a background image shadow over the web. Luckily for us, one of the performance engineers at Facebook was there to explain on Twitter graciously that the reason they're using this is because of performance. A box shadow on a floating header like that was killing scroll performance in browsers. And someone asks, and also as a further example of how our models in our head don't always fit reality, he goes, "I know that's a silly question, but how do you guys test that?" And he goes, "Honestly, it was just scrolling around and noticing it." So no advanced technology here, but it was gnarly. It was really, really bad. So I like to call out this example because reality of delivering great performance at scale goes far beyond what a static generator plus a CDN could give you. And you start realizing there's a lot more to do. So web fonts can really slow you down, as we saw with that example of USA Today at the beginning. All kinds of GDPR nonsense can slow you down. And again, I'm not beating GDPR here. I'm talking about Sometimes we try to do the best for a user's privacy and then we kill their performance by doing it with lots of JS, with the navigation bar that pops in and animates in and brings another shadow on top. And then just everything goes a little bit out of whack. Then I think the whole cohort of marketing analytics scripts, product analytics scripts, ads and trackers of all kinds, exception reporting scripts. There's, there's just, uh, tooling for reporting errors and exceptions that is in the dozens of, uh, you know, uh, kilobytes of, uh, min-zipped JavaScript, and it all evaluates prior React hydration, all kinds of issues like that. We've seen session recording scripts do something similar. Images, of course, images are a huge, sometimes literally they're so huge, so much bigger than the page that is being rendered that the browser and the CPU and the browser engine are responsible for processing massive files for tiny viewports. And then of course your JS bundle is there as well. But again, there's no silver bullet when it comes down to like, I'm gonna use this technique, this stack, and then I got performance. Now in reality, it's, it's much more complicated than that. And going back to the cohorts of the web that are responsible for large amounts of traffic, the solution is never austerity, meaning, oh, well, just delete all of that. Delete the GDPR popup that you built. And then obviously you're gonna be in compliance problem— into compliance problems. Or delete the marketing scripts, well then, if it's an e-commerce website, the team that's responsible for running the business might actually not get the intelligence that they need. So I think what we've heard a lot of the time is, well, really a solution is just ship HTML and CSS, then kind of control your JS, delete most of it, and then move forward. And I think the problem with that is that it's gonna be very hard, A, to achieve good results. But let's assume that that's a practical path. Let's assume that it was a practical path. I think we have to be honest too that it might be hard to get buy-in on just deleting everything and starting over because there's a new architecture that, you know, through some certain strict constraints promises to give you results after years and years of work. So I think a more realistic solution is, believe it or not, cloud computing. This beautiful stock photo cannot possibly be wrong. And the reason for that is I think that we can take advantage of a lot of the power that the cloud has such that we don't put that stress on the battery and CPU of devices. And again, going back to that demo that Josh gave us of the average phone in India, you know, you're not gonna— like, the reality is that the J in Jamstack will not be that powerful across the entire cohort of global and mobile devices. So I think one of the really great alternatives here is instead of not doing the work, shift it to the server, shift it to the cloud, and shift it to the edge. So this is where the concept of hybrid of Next.js really shines as a future path forward. And the reason is with Next.js, when you start and you create your first page, it's static by default. It's completely static. If you don't do any data fetching, when we run next build, we output an HTML file. And when you push it over Vercel, for example, because we know that that's an HTML file that was built at build time, we don't need any special caching headers or anything from your server. We can automatically push it to the global edge, which is gonna be incredibly fast. Again, it's gonna be only the tiny bit top part of the iceberg, but it's really nice to have. So what do I do with the rest of the iceberg? I can start turning that more into, for example, as I need, into server-rendered pages with Next.js. Or I can move, for example, tracking scripts into API functions that get deployed as serverless functions. And again, instead of deleting capability, deleting data, deleting useful tooling, I can just shift it around and use the power of the cloud to be fast and capable. So the solution forward is frameworks that are not rejecting the idea of static optimization or static generation. They're embracing it and they're moving it forward. So Next.js, Nuxt, and SvelteKit are just a few of the frameworks that are taking this approach. Of saying ultimately we have to be realistic, we have to give the developers the tools, and they should be able to use them all, not just be limited to a set of constrained tooling. And again, the CDN is not enough. You have to measure continuously in order to stay performant. So one of the things that we've done here is we've introduced a new approach to analytics. So This is not quite like Google Analytics. Google Analytics just tells you, you know, what pages are popular. And that's okay, that should continue to exist and that's great. And this is also not quite Lighthouse because Lighthouse runs only when you remember it. Like you have to remember, oh, like I'm gonna run it now or another issue that we frequently see with Lighthouse, even if it's automated in some fashion, is that Lighthouse is 100% artificial, right? The default settings are Moto 3G. And yeah, that's a great target device, but it's still kind of arbitrary in some ways. Maybe you don't have that many Moto, Motorola's devices across your own traffic in 3G networks. So what this analytics layer does is It takes the information from your device, and this again gets automatically configured when you deploy to Vercel and you enable it with one click. It's also enabled, by the way, for non-Vercel hosted websites, so anyone can use it. It's actually also available for frameworks like Nuxt, uh, if you configure it. And one of the great things about this again is that it's retrieving the real data points from your devices. So again, going to our point about focusing on reality and the fact that this iceberg gets pretty complicated in terms of what could be slowing down your perf, we think that this mechanism of when I sit down to develop, I get the ability to preview really easily, I can ship really easily, and then to iterate, I get the data from the real world and then that informs my next item of development. So as you can see here on the right-hand side of the screen, we tell you, well, Pages/blog has this score, which is Lighthouse-like. We actually compute a similar equation as Lighthouse, but from the realistic data points of your traffic and say, you know what? That's a 100 score or that's a 50 score. You should probably take a look at working more on that. It's available for other frameworks as well. So it's not just exclusive to Next.js and nor do I believe that Next.js could possibly be the only solution to making a faster web. And I think that if we're gonna move the web forward, because it's in jeopardy, we're gonna have to go at it with a lot of different tools and with a lot of different options. And what's nice though is I truly believe that these tools will have to be realistic and they'll have to focus on reality to let you improve. You're not gonna get to where you wanna be by just saying, "Oh, there's a new language." maybe because it uses WebAssembly, it's gonna solve all my perf problems. So does that mean that Jamstack is all bad? As I said, absolutely not. And things like caching are great, especially if they're automated, right? So I wanna stress that when you use Next.js, if you don't do any data fetching, we automatically statically optimize. When you do static data fetching with getStaticProps, we also do static generation and we automatically optimize by caching all your pages at the edge. And then when you use server rendering, you still have the ability to send the cache control header to manage. So CDNs and caching are absolutely phenomenal tools, and I encourage everyone to make sure that you have them. And if you don't have them, check out our service because it's the easiest way to do so. Whenever possible, however, I think it's really important to not let the idea of, I just need to be static to get performance, or conversely, that static equals performance because that's not the case. I think the easiest way to put this all, which was quite theoretical, and sure, I think it's awesome to be exposed to the data that's driving a lot of our decisions. So That's why I gave this talk, but to actually put a lot of these principles into practice, just help yourself to nextjs.org/learn. It walks you through all the capabilities in Next from static to dynamic, image optimization, and it'll give you the tools for— and workflows for how you tackle the entirety of that iceberg of complexity. So as a parting word, we have a generous free tier on top of which you can deploy any Jamstack or hybrid framework on Vercel. And we welcome your deployments of websites and web applications. Let us know how your experience goes and never, don't forget to measure your results. So take advantage of Vercel Analytics And then you'll actually get to see if your hypotheses are correlating with what users experience all over the web. Thank you so much for tuning in and let me know of all your comments and questions on Twitter. My handle is RauchG, R-A-U-C-H-G.