Guillermo Rauch - Vercel + Vue.js at Vuejs Global (Amsterdam)

4 years ago, we were fortunate enough to create a web framework called Next.js, which has become very popular throughout the internet. But what few people know is that the journey of Next.js has been very long and a lot has been learned. A lot has changed, not just about Next.js, but about the world of web developers at large. I'm gonna dive right into my presentation which is called 4 Years of Next.js: Lessons Learned. At Vercel, we've been building this framework together with the community and we've learned a lot. But interestingly enough, this is not just any framework, it's a React framework. So you might be thinking, who would give a React talk at a Vue conference, a React talk at a Vue conference. So the answer is this guy. So my name is Guillermo Rauch and I'm the CEO of Vercel, which is a platform for modern front-end teams to develop, preview, and ship awesome front-end web projects. I also blog at RauchG.com and some of the essays there that you might find later on, those are the ones that I'll be discussing today. So take a look at your convenience. And I'm streaming to you from San Francisco, California today. Follow me later for more tweets around the content that I'm gonna be discussing today. So the main goal with my presentation today is to share lessons because this is a Vue conference and perhaps not everything about React might interest you or even be useful to you. But the lessons that I'm gonna talk about today will be very helpful in how you choose your next framework, no pun intended, or how you build your next framework if you're so inclined. If you participate in open source communities and you're considering building web tooling, some of the things that I'm gonna talk about today are gonna be useful to you because the journey of building Next.js has taught us a lot about building a framework, building community, but most importantly, evolving technology. And evolving technology, as I said earlier, when things change and when trends change and when new information becomes available to you. So why would you be interested in hearing about Next.js from me? Or even just Next.js at all, or even lessons about Next.js. So two quick things. One, Next.js is really big. So over the past 4 years, Next.js has been deployed to production at some of the largest and most interesting websites on the internet today. Over all these logos that you see here today, a lot— Next.js is running a lot of these experiences. Their entire dot-coms, sometimes part of them. But what's interesting is people that have chosen Next.js have taken it all the way to very interesting production use cases. Number 2, and perhaps this is the most interesting part of the talk, Next.js and Vue are way closer than most people think. And in fact, today I'm gonna reveal some details about Next.js's history that perhaps not many people know about that have been super inspired by the incredible Vue community and Vue technology. So this is a timeline of the entire history of Next.js. Started in early 2016, but the first release that made its way to the public domain that we promoted and we talked about happened in October 25th, 2016. So As you probably can guess by now, we're almost at the 4-year anniversary. So it's just gonna happen in a couple days. So Next.js was introduced back then on our blog and we said, we're very proud of open source's thing. We've been using it for a while, it's small. And that was just 4 years ago. The next day, Nuxt, which many of you are familiar with, Nuxt had its first commit. So the story of Next.js and Nuxt sort of begin at the same time as far as public code is concerned. But I was reading the Vue.js announcement of their funding recently as they continue to grow, not just their framework but their company. And I noticed something really interesting. Not only was it released at around the same time, They had been working on what the technology that became Nuxt using a real world application since much earlier in that year. So they were working on an e-commerce website and they noticed that they needed a lot of these advanced features like server rendering and many other things. And they noticed that it was kind of repetitive to build all the tooling, Webpack, Babel, et cetera, from scratch. And we also had a very similar experience because at the beginning of the year in 2016, we were working on the website for Vercel and we also had similar challenges. We wanted to have multiple pages, we wanted to do pre-rendering. And so this thing called N4 kind of came about and you might be wondering, N what? So N4 was the name I gave to Next.js thinking that the 4 was, you know, ext. In reality, it should have been called N3 because it was a code name of what would later become Next.js. And earlier today, I was actually taking a look at npm and I found that we still have all those releases there. This was, kind of at this point, an artifact of history. It's funny that even back then we had our logo and we're talking about some of the same things we're talking today where Next.js makes pages the starting point of development. Obviously, yeah, we had the beautiful logo. We calling it reactive web applications, which is kind of something that was hot for a while. Reactive, React, obviously. But yeah, some of the basic ideas were there, right? And this is 4 to 5 years ago. One small difference obviously is we ditched that dot at the end of Nuxt. So you can just start a development server even easier today. So just like the Nuxt team was building an actual real world application prior to inventing Nuxt that led to the creation of Nuxt, We're using N4 because we need to build pages. So if you roll back the clock to 2015, 2016, this React thing was incredibly exciting, but it was mostly for building components. And as a company that is dedicated to making frontend developers productive and publishing pages to the edge and just making websites go live really fast, it was weird that it took so much work to get a page working with React. So one of the things that it started to make, and you can sort of see the pattern here between Next and Nuxt of what has made this project successful is we're dogfooding our technology with very practical use cases in mind. So for N4 at the time we're building our website, we're building pages, We started thinking about features like code splitting as a result because we're building our homepage with it, we're building an about page with it, we're building our terms of service page with it, wanted to ship the right amount of JS for every page and so on. But there's a lot more than that little snippet that I showed you on the npm description. If you just begin scrolling a little bit, things get a little weird. Kind of quick. So notice that at the bottom there, we have this instruction that not only do you run Next, but you also create an index.njs file. So things are escalating quickly or getting a little weird. So what is NJS? And what is this thing right here? So at this point you might be thinking, ah, you know, that's, that kind of looks like a template. So is that Next.js and what is that thing? So the story goes that I kind of was really inspired by Vue. It had that practicality, it had that sort of feature set that I really wanted, but I was in love with React as a concept. As I said, I was in love with the idea of React as a component model. But I was kind of like, I wanted to move fast. So I didn't want to write a lot of JS to sort of decorate my page. I didn't want to initialize a router. I didn't want to wire up mounting React into a root and all that. So that was kind of a big inspiration for N4 from Vue. One of the big things that has sort of been a theme over the last 4 years of development in Next.js has been this idea that you start with the file system. So one of the big inspirations here was PHP, insofar every PHP file that you drop into a folder becomes a page that you can navigate very easily without setting up a server, without setting up a router, it's just done. But at the same time, Vue was kind of moving forward also, not with just only this idea of ease of use, but templates, which were quite familiar to me from the PHP world. Templates also have this sort of like super easy, super robust approach that creates a really great result. And Inlining.js is sort of our way of merging this world of like kind of PHP style templating with Vue style templating. Another big thing that I liked was, okay, I need to do a lot of CSS. I need to write a lot of CSS. I need to style things a lot. I noticed at the time that front-end developers were actually not spending all of their time just writing logic. A lot of the time went into styling. And that's why we were sort of had this batteries included approach to hot module replacement so that you could type and see the changes on the screen. And I like this idea of also just putting some HTML here, putting some templates here, or sorry, some template tags in there and then putting a style in there. So that idea that has also since then been around the React world as this idea of single file components proposals was present in my mind back then as well. And finally, I wanted to make this really, really easy to adopt. So I was also inspired by Vue's sort of learning curve, which basically starts with the premise that you just need to know a little bit of HTML, a little bit of JS, a little bit of CSS, and then you're productive, just like you're productive with the actual web. But so you might be thinking, so all of that, where is that today, right? What happened to that template system? And so on and so forth. So many things happened, but one particular thing that happened that was really interesting is if you go back to the timeline, we started N4, even we started thinking about it like in late 2015 and some of the early releases happened in early 2016. But by mid-2016, this gentleman, Dan Abramov, an awesome guy, rising star of the JS world, decides to create their own initiative by Facebook of how you create React apps with very little work. So some of the same spirit that we had at the time with N4, with Next.js. So this is pretty concerning, right? We had this big dream of making the web really easy to use and starting up with React really easily. And we had been working a lot on it at the time and we already had a production site on it. We were using it a lot. So you could imagine that considering that from early 2016 to mid-2016, that was a lot of interesting things that happened in our world. Obviously we hadn't released anything publicly, but it was very, very interesting to see this. So you could imagine, okay, like what now, right? Like, do we throw everything away? Do we just like start writing everything in Create React App and sort of stop this effort? And yeah, at the time it was like, oh, whoa. That's interesting. Like, we're obviously not the only ones thinking about this, especially 'cause the Nuxt team was even thinking about the same things, but in your world, in the Vue world. So obviously none of these ideas were totally unique, but there is an important thing to call out here. So like, if we go back to the announcement, you see that create-react-app says that it's a way to create a single page. React application, and it offers a modern build setup with no configuration. If you go back to our announcement that happened later on, we say we're very proud of open source Next.js, a small framework server rendered. And perhaps the most interesting thing here is universal JavaScript web apps built on React, Webpack, and Babel. And also very interesting, which powers this very site So even in the early days, we can start seeing like a fork here in the road. And so far, Next.js is very much focused on powering real-world use cases. It's being dogfooded or it's being used by us quite a bit already. So we had some interesting things going on, but so this is kind of the contrast, right? Like Create React App was focused on single-page applications and us, we're focusing more on this universal server rendering, pre-rendering, and this idea of, okay, I felt like, you know, we had something interesting going on here because we're dogfooding it. And, you know, at the time, for example, the React website, I remember, I am pretty sure that even the React website was not using React at all at the time, which I found to be an interesting scenario, right? Because again, like for me, the dream was to make React just be everywhere and be used in a lot of things. So I was like, I think it's worth pushing forward with this. I think there's an opportunity here. I think there is a market opportunity. I think this thing that we're building will be very, very useful for many people. So one of the things that also changed from that N4 experiment is that we saw an opportunity here to play nice and be a big part of this broader React ecosystem. So we knew that Create React App was there. There were other efforts in the React communities that springing up and to use templating felt a little bit like forking that ecosystem or not fitting in, in a way. So one of the things I think we did really well is that we looked back, we took a hard look at what we were doing and we decided to actually perform a pretty major rewrite. So I'm really thankful here that— and now Yuki was sort of my co-founder at Vercel, but also a person that was very much willing to understand that. And then he went ahead and he rewrote Next.js or what became Next.js by applying a lot of the lessons that we'd already learned. Then he sort of got rid of the template system. And then because he is an awesome person, he wrote a code mod to transform all our templates into what became modules that export React components. But aside from that, the idea of a market opportunity was very much spot on because Next.js started delivering on things that ended up being very critical. So SEO was one of them. So any website or, and most web apps will at some point be accessed through a web browser. And for a lot of people, that web browser is almost synonymous with entering something into Google. And for a lot of businesses, and this is why I mentioned business critical, having great search rankings is a really major part of succeeding. So Next.js enabled that. And also as a side effect, and we didn't know this at the time, but the reason that Next.js also has gotten a lot of large adoption was people that were considering modernizing their frontends, a lot of them already had working businesses, right? As developers, we like to obsess a lot about the technological choices, but when you think about whether my business is working well or not, for a lot of people, their PHP monolith with jQuery, for example, was delivering great results. So if they were gonna modernize their frontend, they needed to, for example, preserve great SEO. The other thing that we delivered on is that as sites grew, this idea of server rendering, static prerendering, and so on were making sense for larger sites. Than just— than what could be done with single page applications. And then two major segments started adopting Next.js a lot. So content websites, uh, and also e-commerce websites where this combination of having lots of pages, needing great performance, needing search engine optimization, that was kind of like the, um, table stakes decision making for them. And also another one that was super interesting is user-generated content. So for example, TikTok.com today is powered by Next.js, where the pages are being created dynamically as a result of users creating content, right? So, uh, a single page application would work there to some extent, but Next.js was also giving some extra optimizations that were super awesome. So one of the lessons here too is that big markets are big. And what do I mean by this is that Sometimes we think that there's only space for one, but there's always a lot of space, especially when the markets are huge. And Create React App is great and Vue.js is doing phenomenally. And also of course Next.js is doing quite well. And the opportunity here is not just to think that there is only one, but also to learn from the others. And that's sort of one of the big things throughout this talk. And interesting too is that single page applications at the time were super popular. So a little bit of what we did with Next.js was go against what was becoming the common wisdom. And it ended up over the long haul being incredibly beneficial, but over the short term, it was not always easy. But one of the things that I always would root myself in is, Before we started a lot of these projects, before I started Vercel, before we started Next.js, I wrote this little essay on 7 principles of rich web applications that you can find on my website still today. And that was a while ago now, it was in 2014. But one of the things that I said at the time was, okay, I wrote down a few rules that I wanted to have for myself. For understanding how to create optimal websites and how to create really rich websites as well. And the number one that was really funny to see today is that pre-rendered pages are not optional. That was like my number one axiom. And the way that I justified this was that pre-rendering or server rendering, it's not even just about search engine optimization. And many of you in the audience might rightfully recognize that search engines are getting more capable of crawling different sites, even though still prerendering gives you a very significant advantage when it comes to crawling even today. But even excluding that, it's about performance, right? So like, if I give you a prerendered page and you're not doing the rendering on your device, then that's going to be faster. And the way that I understood it at the time was regardless of the performance of phones and the fact that in the emerging markets phones are slower, so if you only do React rendering on the client side, you're going to spend a lot of time or downloading a lot of code on slower networks, you're going to spend a lot of time. But even if those things weren't there, even those weren't problems, which they are, the fact of the universe is that we're dealing with a theoretical speed limit. So if I only have to make one hop to get the page and the page comes to me in one delightful stream already of precomputed data, data and code and there's only one trip in one direction, like, that's pretty nice. And this has obviously been well understood that there's a theoretical speed of light and then the speed of light over fiber and then some friction on that fiber optic cable and so on and so forth. And yeah, so those are the numbers that we're dealing with. So for me, even when I was seeing all this excitement happen over alternative ways of doing things, which again, like in big markets and in big ecosystems like we are today, they all have their own place, but it still felt like sticking to the physics and sticking to what I knew axiomatically ended up paying off quite well. However, and I don't know if many of you have read my article back then, um, there was still a big problem. So this problem was that we were relying too much on servers and we're talking too much about servers. So server rendering, server rendering, server rendering. And meanwhile, a lot of technologies were getting a lot of, uh, traction, developers, great results, fast websites like Hugo, Gatsby, Gridsome, Netlify on the Static hosting side. And if, if any of you have read my article back in the day, there's a small caveat here. So notice that the title I've retroactively edited to say pre-rendered. It used to be server rendering is not optional, but pre-rendering feels better in my mind because it encapsulates this other world of awesome technology, which is static site generation. And you can think of static site generation as server-side rendering that happens at build time, right? So the technology is very, very similar, but there are some meaningful differences. And those technologies were also finding amazing use cases and amazing new ideas. And we felt like, you know, we wanted to participate in this world of, you know, optimizations that are only possible with the static site generation. And so what are those? So first of all, static sites by definition are serverless, meaning they're just a bunch of files. We can distribute them around the world and it's just very cheap, very reliable. So if there is no server, you know, like servers crash, server gets overwhelmed, servers get memory leaks, but Static sites are freaking reliable. And because they're cheap, because they're serverless, because they're reliable, they're naturally very scalable. And the physics, uh, sort of thinking side of me, uh, you know, in a physical system we also have to deal with energy expenditure, heat, and all these things, circuitry. So if I've pre-rendered a static site I do no computation. And that, in my mind, seems awesome, right? Like, no computation is always better than computation. So if there is a page that is gonna remain constant for a certain amount of time, I can compute once at build time and then distribute it. And there's a lot of other benefits. Like, for example, if you know that a part of the website is static, then you can automatically cache it. So there's no negotiation that has to happen between CDN layer and server. And this has become an amazing benefit that we give developers today when they deploy to Vercel, because we cache and purge the static portions of their websites without them having to ever think about cache control and servers and all that. And ultimately, another physical matter here is that a longer trip to an origin in a single region is obviously worse from a physics standpoint than making a shorter trip to the edge and getting the response there. So static pages had all these benefits and they were very, very compelling to me. And this is where Next.js evolved to become a hybrid framework. So in mid-2019, we announced Next.js 9 with automatic static optimization. And this has been a major milestone in our evolution. So this idea of automatic static optimization means, so if you're familiar with Next.js or Nuxt, you know that you can declare a data fetching hook or function. So look at the top, you have getInitialProps. We request some data, then we hand that data to our quote-unquote template, and then we render. So this is a— this is just a page in Next.js. Think of it as pages in Exile.js. Boom, super easy way of creating a page even with some dynamic data and even with server rendering. One file is all you need. But here's where automatic static optimization comes in. If you want instead to not server render, and if you want your page to be cached at the edge and you don't wanna do any server computation at all, you just wanna do everything on the client, you just literally delete that getInitialProps hook, which now we also call getServerSideProps to be more clear. But if you just delete it, Next.js would automatically statically optimize. Later, we expanded this to use data at generation time. So what does this mean? So at build time, we will execute your hook, which in this case at the top is called getStaticProps. We'll fetch data at build time and we'll expose it and then we'll generate HTML. So in May 2020, so that was, quite a bit later, we announced the static generation features for Next.js. So to recap, if you don't use the data fetching hooks, you just get HTML as an output. And hosting platforms like Vercel can automatically do the CDN distribution, replication, caching, invalidation, all that awesome stuff. Then if you use getStaticProps or getStaticPaths, This is how you can actually start generating lots of pages. Not just you already have one page in your file system, but we're talking about getting data from CMSs, getting data from e-commerce, headless APIs. And you also get these benefits here. getStaticPaths was inspired by Nuxt in some ways because Nuxt introduced the idea of dynamic routing with the file system. Like for example, like pages/blog and then bracket slug bracket .js. So we connected that idea and then we added on top getStaticPath so that you can, for example, tell Next.js generate 100 blog posts at build time. And then we made it very clear that you can still do SSR, but you have to be more explicit. So with getServerSideProps, You can, for example, do data fetching even directly from a data store. And the really cool thing is that we wanted to retain this serverless spirit. So when you run Next build, what it does nowadays is that it can output both HTML and Lambda functions. So you can now sort of on a page-per-page basis decide if you're gonna do SSR or static. So the biggest lesson of them all, as I wrap up my talk, is that you have to strive to learn from everybody. So everybody has great ideas and everybody has great specific communities and use cases and flavors and different ways of doing things. But I encourage to look at what other people are doing and learn from them. And even beyond that, it's not just about learning, but it's about giving back. So for us, we want to give back to the Vue and Nuxt community for being so inspiring and, and great people to collaborate with. So if you want to deploy your projects, you can do so for free on our platform, and you can deploy for free both static and dynamic. So you can do, you can use Vue CLI or Nuxt. Builds are very, very fast. And this is one of the things that we love to optimize and have made very incredible things with. And we automatically distribute your pages worldwide with the best performance. So we're pretty obsessive about Lighthouse scores as well. So check out Vercel. You import your Git repo with any modern frontend framework like Vue, Nuxt, Next, and it'll just be deployed. So, uh, that was pretty, uh, incredible for me to have this opportunity to tell you a little bit about the history of Next.js and some of the inspiration that we got along the way and how we evolved. So check us out on Vercel.com or follow me on Twitter and looking forward to hearing all your feedback and staying in touch. Thank you.