Nothing to say, yet
Transcription
Next.js Conf is an annual event where developers gather to learn about Next.js, a React front-end development web framework. The keynote speaker explains that Next.js is not just about building fast websites, but also about creating personalized experiences for each visitor. The speaker introduces Next.js 14, which includes the app router, a flexible and powerful tool for data fetching, caching, and faster routing. The speaker also announces improvements to the Next.js documentation and the introduction of Next.js Learn, a resource for learning all aspects of Next.js. The speaker highlights the collaboration between Next.js and the React core team, as well as various companies that have adopted Next.js for their projects. Examples are given to showcase the benefits of using Next.js and React server components. Overall, Next.js 14 offers a more streamlined and efficient development experience for building web applications. Good morning, and welcome to our fourth annual Next.js Conf. It's so great to see you all here today in San Francisco, and online, joining us from all over the world with watch parties going on right now in London, Sydney, Barcelona, just all over. It's so great to be here with you all today. I started building Next.js seven years ago because I wanted to build a blazing fast website, but I didn't want to deal with all the frustrating tooling and setup and infrastructure around it. And it's been incredible to grow till today to the tune of 850,000 monthly active developers. Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Next.js. How would Chad Gipity describe it? Let's see. An open source React front-end development web framework. No hallucinations. It's awesome. Server-side rendering. And just for sanity check, let's ask Claude by Anthropic. Popular React framework. Awesome. Thank you, Claude. Well, it seems like the AI is in alignment. Good to go. So to me, Next.js is not just about making fast sites. It's about making sites that are personal. Experiences that are delivered just in time to every visitor and remember their preferences, what they've been doing, their card state, their logged-in state. Just a better web that's unique to each individual. So we wanted this keynote itself to be custom. So we built an app, of course, with Next.js app router. You can head to nextjs.com slash vote. I'm going to do that myself as well. And so to make this keynote personalized, we're going to let you vote on what I'm going to talk about next. No pressure. Head to nextjs.com slash vote, and let's see what the results are showing so far. Seems like it's going to be a close battle between Next.js 14 and performance. This is fantastic. All right. Let's get some more people in. Getting really close. All right, I'll do all of them at once, concurrently with suspense in concurrent mode. All right, let's just go with Next.js 14. It seems like the clear winner so far. So the foundation of Next.js 14 is, of course, the app router. And it has three main pillars. Number one, we built this app router on the basis of flexibility for the developer. We want to give you all these APIs, like layout, and nest layout, and the new metadata API. Of course, app router had to be powerful. The most powerful thing is this data fetching system with caching and invalidation built in. And last but not least, we're all here for fast. So of course, app router is faster. And the key thing here is a new foundation built on streaming, and HTTP, and web fundamentals. So most importantly, one of the key tenets of the app router is that you can adopt it incrementally alongside the pages router, even one page at a time. Now, when we look at the public data, how far we've come since that initial beta, it's been incredible that in the top 1 million websites on the internet, we see tremendous growth in app router adoption. This is folks using and deploying React server components to production. We're very, very thankful for everybody that's given us feedback, and battle tested it, and put it in front of amazing experiences in front of amazing users. So thank you. You've entrusted us to build this app router to the maximum level of quality possible. So today, I'm happy to announce Next.js 14. And guess what? Next.js 14 comes with no new APIs. I know. In fact, not only does it have no new APIs, we have a surprise that'll help you forget about some APIs that you didn't ever want to learn. So we'll see towards the end of the presentation. So over the past year, we've completely overhauled our documentation. Of course, a framework wouldn't be great with that incredible documentation. So we have a new API reference docs. We updated the design of the Next.js documentation. Shout out to our design team. And we improved search. So of course, you want to go to nextjs.org slash docs and find things quickly. But we've gotten more feedback about education. We heard feedback from the community, and it turns out you wanted more docs, more education, more to help you learn. And now, I'm happy to announce that we've overhauled and introduced a brand new nextjs.org slash learn, which not only teaches you all the new fundamentals of Next.js, it extends into areas like authentication, databases, everything you need to ship a production-grade, full-stack Next.js application. I'm really excited, because ever since we launched the initial nextjs.org slash learn, I know that it's educated millions of developers that have gone on to create amazing things, some of which we highlighted earlier. So I'm just really excited to see what you all are going to build after you go through nextjs.org slash learn. And in the context of that education, the things that I hear about what you love about Next.js is that ultimately, it's opinionated. It gave you this zero configuration foundation. But Next.js sits on top of React. React is that powerful engine that is there behind the scenes. And one of my favorite features of React itself is its ability to compose into reusable components, whether it's the UI or whether it's the interactivity in the form of hooks. However, up until recently, this composability, this ability to put things into components, was limited to just the client side. And it hadn't gone yet into the server. So Next.js had an answer for that. Because we've used the server more over the years, we added hooks and APIs that sat on top of React itself, like getServerSideProps. But we knew that the React team had also been experimenting with new APIs to answer some of these challenges. Those APIs include suspense and React server components. And of course, as a framework that builds on top of React, our duty was to expose this API to you and help you explore them and experiment with them. To do so, we needed to do three things. Number one, we built a new router that tries to set up itself on top of these React foundations. Number two, we created a new data fetching system that is tightly integrated into that router. It handles things like not just data fetching, but also caching and invalidation. And last but not least, an architecture that is built on streaming so that you can fetch data and make it available to users without blocking experiences. That vision materialized into the app router that we have today. For example, with server components, I can grab data and use it directly in components that are reusable throughout my application. The components themselves are fetching the data. And this is not just data coming from my database. This is any data coming from anywhere in the cloud. And this data fetching components can be shared on NPM. And this power, combined with server actions, means that you can also mutate your data alongside React components and even invalidate it when it's cached. It's as easy as calling that function. It's just a JavaScript function, in this case, called action. Of course, this also works with forms. So just like React server components, these actions can be shared and exported to the community through NPM. With Next.js 14, server actions are now stable. Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! Woo! I'm excited because this was the missing piece of the puzzle. This makes the architecture complete. It means that you can fetch data. And of course, you can mutate it in a very natural programming model. Of course, tightly integrated into Next.js. So selfishly, the best part is that you just write a lot less code. So we have actions on the right-hand side here. The biggest thing is that you're not creating all these ad hoc APIs in order to register mutations. You don't have to mess with all this client-side hooks for data fetching. You don't have to think about two ways of dealing with data. No disk to use effects, but it could get messy at times. So just having all of my data taken care of by the framework is pretty awesome. And while it's still early, we're seeing incredible results from our community. So this luxury brand, Jennifer Fisher, went from a monolithic e-commerce experience and went headless with AppRouter on Vercel and Next.js. And the results that we've gotten are pretty freaking incredible. So not only does it load fast, which I love, but every measure of the performance profile of their page has improved. And this has translated into world results for their customers. It means that customers are happier. They transact faster. And of course, Jennifer Fisher, wherever you are, you're happier. Beautiful earrings. So all of this would not have been possible without the amazing individuals in the React core team that have been incredible partners to make all of this technology possible and all of these glorious results possible. So huge shout out to the React core team that have been working on this foundational technology for so many years. Second, the companies that basically worked with us along the way in betting on React components. So many of you are here today. I want to give a shout out to Clerk, Superbase, Shopify, Payload, Sanity, Octane, so many other companies that are collaborating on bringing their data into React server components. These companies, they're not just helping create examples and templates and documentation. They're becoming part of this emergent data ecosystem. Their SDKs can now be encapsulated as components that are easily shareable. And they will hide away a lot of the complexity that we never want to deal with as developers when integrating data and other headless systems. So I'm really excited of this emergent data ecosystem around React server components. And it'll open up incredible opportunities to many, many companies in the ecosystem. Third, the Chrome Aurora team. The Chrome Aurora team have been crucial partners to every framework in the ecosystem, providing guidance and patches and amazing feedback to make the entire web better. Many of you at the Chrome Aurora team are here today. So thank you. And I look forward to hanging out with you as well. And thank you for your contributions, not just to this release, but over the years in the course of Next.js. Our individuals in our community, I'm incredibly indebted to you all. So of course, this slide is not comprehensive. There's so many folks. But I really want to give a shout out to all the educators, our community members who answer questions, take time out of their day, the helpful friends who give us feedback. It's been a, yeah, let's give it up for our community. It's been a, it's been incredible. Thank you all. So last but not least, I want to give a shout out to the visionaries, the risk takers, the ones who dared to go deeper. You know who I'm talking about. PHP, they had it right all along. More server, simpler programming model, the OG serverless. You deserve your accolades. Love you, PHP. The jokes aside, folks outside of the JavaScript ecosystem have also been giving us incredible feedback about how to leverage more of the stack, maybe go back to some of the fundamentals of the web, and just overall make the internet faster and better. So thank you all. Thank you, HTMX. Now let's talk about performance, which was almost beating Next.js 14 out there. So our goal with Next.js, as far as performance goes, is we always wanted to abstract away all of the complexity to get to a great developer experience. The core idea of Next is that just run one command. You don't have to worry about assembling and configuring all of the tools. And since we last spoke, we made incredible strides in improving the compiler infrastructure in a way where you really didn't have to do anything else other than upgrade the framework to the latest version. So we shipped a 22% faster initial compile, that is booting up the dev server and getting to that first page, and a 29% faster code updates. That's keys on the keyboard, pressing Save, and seeing them on the screen. And it turns out that after shipping this, we went back to the drawing board, and we asked ourselves and asked the team, what should we work on next? The results will shock you. Performance, still performance, which is music to my ears. We're super aligned. And the key question here was, we know that you want performance. How can we deliver this performance updates to you as fast as possible? And you know that at Next.js Con, we talked about rewriting our entire Next.js CLI and bundler technology in Rust. So Rust has been an awesome investment, but it's taken a while to give you all those performance improvements. So my question was, should we rewrite in a new programming language? Should we rewrite in ZIG? What do we do to get you this improvement fast to you? And I'm here to announce that we're still betting on Rust, and we will deliver incrementally and fast. So I'm going to tell you how we're going to do that. So we're sticking with Rust, but we're refocusing our effort primarily in the Next.js compiler. We want to see the Next.js compiler succeed with this new infrastructure and give you the improvements to performance as incrementally as possible. And we want to see that in small, large applications. We want to see that in the pages router, and we want to see it in the app router. And the three things that we're going to be monitoring very, very closely to decide whether our investments are paying off are, number one, a fast dev server, number two, fast code updates from save to screen, and number three, fast production builds. So this is running Next.build, especially when you go to production. So how do we do this? How do we give you all of this? How do we track our progress? How do we measure that we're on track? This, I regret to announce, is not my GitHub contribution chart. It's actually suffered quite a bit in the last couple of years. This is how we're tracking the reliability of our Rust-based compiler. So this represents running the entire test suite of Next.js that we've accumulated over seven years with every bug fix, every reproduction, every race condition. You can keep track of it at rwitturboyet.com. And all these beautiful blue squares represent 90% of tests passing with Rust. So it's been incredible to make this huge strides in reliability. So let's talk about some of the performance improvements that this is going to unlock. Number one, we're seeing 53% faster initial compile with the most recent introduction of TurboPack, and up to 94% faster code updates. Again, these apply to both routers, the pages router and the app router. To recap, we're refocusing a Rust-powered compiler effort. We're delivering to the tune of over 5,000 passing tests already in the most recent release. Everything is faster all around. And the thing I'm most excited about is this is the new baseline of performance. To give you a sense of this, when you run next dev dash dash turbo, we're running everything cold. No persistent file system caching yet. And it already really, really, really beats the previous compiler infrastructure. It's just way faster. So this is the new baseline. We're going to keep getting faster in the future. You can keep track of our progress on areweturboyet.com. So now, the moment we've all been waiting for, simplifying Next.js. All want to deliver fast websites, dynamic websites. And we all want simplicity when it comes down to the programming model. So before I go into how we can deliver on this simplicity, and as promised, with no new APIs, I'll talk about how I measure a fast website. Number one, I want to see a fast initial visual. So this is opening my phone, go to a page, and I want to see it instantaneously. Even though it might not be complete, because there's parts of that site that are dynamic and personalized just for me. So I also care about a fast dynamic visual. This is when, for example, the state of my card streams in, or my recently viewed items on an e-commerce site stream in. And most importantly, in terms of simplicity, I want a great developer experience. So through this lens, through this criteria, let's very quickly revisit the history of Next.js until now, and the rendering strategies that we've shipped. It all started back in the day, young Rauch G, with traditional server-side rendering. So this is the common SSR that you remember from back-end-centric technologies. What happens here is I have a visitor potentially far away from a server. That visitor is waiting until the request lands on that server. That server starts querying that database, and what we're seeing is it took a while to get to the initial visual, and the dynamic visual from that point on happened fairly fast. Let's see how we would rate this. Fast initial visual, I would rate it sadness. Why? Because, well, we saw those four white screens. It's just you're not getting anything, especially if you're far away from the server. Fast dynamic visual, I went to our design team. We settled on slightly smiling emoji face. And the DX was actually great. I hear a lot of your feedback that the beginning of Next.js was really simple. It was just get server-side props, throw some Node.js code in there, you're done. So DX was the inspo for what we're going to see today. The next step is the community gave us feedback that some of their pages, some of their workloads were fully static. So we added static site generation capabilities, and Next.js became a hybrid framework. It could do both on an entry-point basis. So let's look at a static page here that actually turns out later on I have to personalize. So what happens is I give you the initial visual nearly immediately, and then to actually get to the final state of personalized data, that's where it gets tricky, right? I have to download lots of JS. I have to fetch the data. I have to render. There could be waterfalls. So as you could imagine, fast initial visual is lovely. We rated fast dynamic visual deadly. And the DX was okay, but keep in mind that in this model, you were juggling two ways of fetching data. For example, get static props and all the hooks on the React side to fetch data on the client. So not fully satisfying. Let's now look at the bleeding edge. What do we have today? We have streaming, absolutely incredible technology. We have things like the Edge Runtime. We have the ability to put the compute right next to the visitor. So the initial visual gets better. Dynamic also gets better, but it really depends on how you configure it all. It really depends on whether the data is close to the compute or not. It depends a lot on what ecosystem of packages you're using. It's kind of like not fully satisfying on every dimension. The initial visual could have been as fast as the static, for example. The dynamic visual could therefore have happened faster, especially when you're juggling your compute being far away from your data and waterfalls. And the DX, well, don't get me started on the DX because now I have to figure out runtimes, figure out regions, figure out what packages work, what packages don't work. So if I do all of this, the situation was good, but again, we're in the quest to simplify Next.js. So this is where we're gonna end up. We're gonna end up in a fast initial visual, fast dynamic visual, and great DX. And I'm happy to announce today that we're introducing a technology in Preview to make this possible. And it's called Partial Prerendering. Partial Prerendering is a technology that gets activated at build time and it works into the Next.js compiler. So what happens is this. When you build your Next.js project, we will extract a static shell for each entry point of your application, including all of your dynamic pages. In this phase, Next.js can extract all the static parts and prerender them. So for example, here I'm prerendering the logo of the page, the navigation. And very interestingly, I'm also able to prerender the fallbacks of the dynamic slots of the page. So notice here I have this banner that I'm reserving for a promotion that is tailored to each visitor. And of course I have my cart and my profile picture. So those are the personalized parts. What Next.js can do is it can give you this shell immediately and then stream in the dynamic parts. If we look at it from the lens of the experiment that we ran earlier, we can see now I can get my initial visual as fast as static. And then the server starts streaming and there are no waterfalls. Most importantly, this is really easy and I didn't have to learn or adopt any new APIs. It's a win, win, win. We all win. So having accomplished this, and again, this technology is in preview, you're gonna be able to test it really soon. You're gonna be able to ship this dream of what we call dynamic at the speed of static. Not having to worry about runtimes nor regions. So let's recap what we covered today during the keynote. With our refocused effort on the Next.js compiler, we're seeing an amazing new baseline of performance while also doubling down on correctness and reliability with over 5,000 tests passing, which amount to over 90% of our test suite. Number two, we have this incredible new Next.js Learn course that not only teaches the fundamentals of Next.js and the App Writer, but it extends into databases and auth and everything you need to build a production-ready app. Server actions are now stable, which means that you can mutate data with the native React data model. So this was the missing piece of the entire architecture, so we're really happy to make it stable. And last but not least, with partial pre-rendering, we're delivering on the dream of dynamic at the speed of static without having to learn any new APIs. You can upgrade to Next.js 14 today or head to nextjs.org slash 14 to learn about all these great improvements. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you.
