(audience cheering) - Welcome, welcome, welcome
to Next.js Conf 2022. I'm excited you could join us today to hear updates across three
major areas of web development. It's amazing how much Next.js has grown since our start in 2016 with
over 2,400 contributors, over 200 million downloads, and the global community of developers, including those viewing
Next.js Conf right now from London, New York, San Francisco, (audience cheers) and the tens of thousands watching online. The Next.js community is
stronger and bolder than ever. Each year, more of the top
applications on the web are built with Next.js, particularly in retail, SaaS, media, drawn by its balance between
great developer experience and great end user performance. Next.js had its origins
as a React framework for dynamic server under sites. Instead of optimizing for
single page applications, we designed Next.js for
teams building ambitious, complex applications, but being dynamic has always
come with a lot of limits. You've wanted to be dynamic, but it's meant at the expense of costly, always on infrastructure, requiring manual provision
and extensive operations. You've wanted to be dynamic, but it's meant juggling
two sets of runtime APIs, no JS in the server and web
standard APIs in the browser. You've wanted to be dynamic, but often only in a single region origin, depending on legacy, static, CDN caching to try to perform and scale. Let that sink in. Unless you were one of
the giants of the web, like Google or Facebook.com, the only way to scale a
dynamic global application was to downgrade a static. The downsides of static become apparent when faced with dynamic requirements. Your cached or static generated page is at odds with granular
user personalization, experimentation, or even
showing the number of items in a shopping cart, so you turn
to shipping massive amounts of client-side JavaScript. We knew that the answer
was never in optimizing within those constraints. We're ready for a new paradigm. Today, we're releasing
Next.js 13 to enable you to be dynamic without limits. Next.js 13 ships innovations
across three major categories. First, compiler infrastructure. Originally, way back in my day, we built Next.js on top of
Webpack, an open source bundler that revolutionized front end development. While Webpack has allowed JavaScript to go from sprinkling interactivity on a page to building entire web applications with just JS or TypeScript,
it's time for a major upgrade, the successor to Webpack. Second, routing and
rendering infrastructure. We'll introduce a redesigned
approach to layouts, data fetching, and server rendering. Building on React's
multi-year investments, we're delivering on the dream of shipping dramatically
less client side JavaScript, while making the most
ambitious applications, not just possible but easy. Everything you love
about React and Next.js, absolutely everything gets simpler today. Third, our component toolkit. A true web SDK would not be complete if it didn't address the
most common artifacts that you see on the web, like images, fonts, scripts,
and even social carts. So pushing the web forward requires this comprehensive
investment across tooling, runtime, cloud infra, the ecosystem in our community as a whole. That's been the journey of
Vercel for the past six years, to enable developers to create
at the moment of inspiration. Let's watch how Next.js 13 is
making this vision a reality with Lee Robinson. (crowd cheers) - Today is a new beginning
for compiler infrastructure, in Next.js, and for the
entire web ecosystem. Next.js provides the right
defaults for your app with zero configuration. Our job is to curate
the best tools for you so your team can iterate faster
and ship better products. In 2016, the natural thing to do was to write JavaScript tooling in JavaScript. That meant tools like
Babel, Terser, and Webpack. As front end applications
grew in size and complexity, this tooling struggled to keep up. We hit the limits of what was possible with the performance of
JavaScript-based compilation. At our last conference,
we began our transition to native Rust-powered tooling. We started by migrating away from Babel, which resulted in 17 times
faster transpilation. Then we replaced Terser, which resulted in six
times faster minification, but what about bundling? Webpack has been downloaded
over 3 billion times. It's become an integral part
of building for the web, but just like Babel and Terser, it's time to go all in on native. Tobias, the creator of
Webpack, joined Vercel and assembled a team of
world class engineers to build the web's next
generation bundler. This team has taken the lessons
from 10 years of Webpack combined with the innovations
in incremental computation from Turborepo and Google's Bazel and invented an architecture ready to withstand the next 10 years. We're excited to introduce Turbopack, our Rust-based successor to Webpack. On large applications, Turbopack shows updates
10 times faster than Vite and 700 times faster than Webpack. For a really large application, the difference is even greater, 20 times faster updates than Vite. These speed boosts aren't
just for code updates but also for starting up
your local dev server. Let's take a look at an example. As you'll see, Turbo Pack
starts up in 1.8 seconds when handling a large
application with 3,000 modules. This is faster than both
previous versions of Next.js and other popular tools. Turbopack's performance comes from its highly optimized machine code and low level incremental
engine built with Rust. Once Turbopack performs a
task, it never does it again. To start, Turbopack is focused on your local development experience, including React fast refresh. Eventually Turbopack will
also power Next.js production builds both locally and in the cloud. Just like with Turborepo, we can share the work
that's already been done, not just on your local machine, but also from teams across
your entire organization. Try out the Turbopack Alpha
today by upgrading to Next.js 13 and running next dev --turbo. While optimized for React
and Next.js code bases, Turbopack is the new foundation of high performance bare metal tooling and is now open source. Check it out on turbo.build
to see the benchmarks and supported features. With Turbo Pack, we're continuing to reimagine the foundations of Next.js. Let's go back to Giermo to
hear more about Next.js 13. (audience cheers) - Thanks, Lee. With Turbopack, we're
creating the fastest compiler infrastructure for JS
and TypeScript projects. We're moving to a world where
running your app locally and making an incremental
change can happen in as little as 10 milliseconds. Building for production,
even for large code bases, will happen in single digit seconds. These instant updates
are not just for you, but thanks to Vercel remote cache and our build infrastructure,
for your entire team as well by ensuring automatically that we don't do the same work twice. This remote cache has already
saved development teams at companies of all sizes
decades of build time, decades. Our mission doesn't stop at a
better developer experience. To push the web forward,
Next.js 13 is also re-imagining how pages are structured, rendered, and delivered at the edge. - One of the most loved features of Next.js is our file
system based router. Drop a file inside a
folder and you're able to instantly create routes
in your application, no configuration required. Over the past six years, our
router has helped view some of the largest web
applications in the world, spending billions of daily page views. This has helped us identify
some incredible opportunities to continue delivering on
the best possible router. We can make it easier to
co-locate data fetching inside components, enabling
global data fetching in your application. For example, when you have
dynamic data requirements that are shared across pages, we can make it easier to
co-locate your application code with your routes, like
components, tests, and styles so that you and your team
don't have to come up with your own conventions
and configuration. We can make it easier to
lay out complex interfaces that maintain state across navigations and avoid expensive rerenders and retriggering of animations. These opportunities for
improvement in combination with Reacts multi-year
architectural investment into concurrent features
created the perfect environment to upgrade the web's most
popular file system based router. That is why, today, we're
introducing a new Next.js router that we know you're going to love. Our new router starts
with the introduction of the app directory, which can coexist with the
existing pages directory for incremental adoption. Let's take a look at an example. It's still just one file,
page.js, to create my homepage. My product has a list of
dynamic popular topics tailored to my interest in a sidebar
on the left-hand side. Let's create the individual topic page that the sidebar links to. This uses the same syntax
you're already familiar with for nesting and dynamic routes. I want to reuse the
sidebar and the navigation from my homepage on the topic page. So I can refactor my component
into a layout.js file that shares UI between the two pages. Not only is this more convenient for me, but as I navigate, only a small portion of the screen rerenders
streamlining the work, both on the client and the server. Notice how the search
field preserves state and the animations continue
despite the route changes. This product has dynamic requirements. The topics in the layout
are user personalized. This isn't a static page. So how do you fetch and
stream data from the server while preventing large
amounts of JavaScript and waterfalls on the client? We've worked with the React core team to deliver new solution
to simplify fetching for all of React and Next.js,
and you can try it today. This is what my data
fetching code looks like for the sidebar using the
brand new data fetching API. It's extremely simple and in-lined right inside my application code. The best part, I can sprinkle
streaming data fetching throughout my entire app, layouts, pages,
components, and even hooks. Our shared UI between the home and the topic page can
now fetch and reuse data. Let's now define a new loading stage for our topic page with loading.js. Notice how when I transition between pages we serve and render an
instant loading state while we're streaming
the rest of our content. Similarly, we allow custom error handling with the error.js convention. To preserve the flexibility and
scalability that you've come to love about Next.js data fetching, we're extending the
run time with additions like built-in caching,
deduplication of requests, programmatic revalidations,
and granular purging of data. Let that sink in. This means that all the benefits of ISR, static data fetching,
service side data fetching, and even SWR are now all
in one hybrid solution. Because our router builds
on React server components, everything we just
defined for this product is now server first. You can maintain rich interactive
client-side experiences all while you're shipping
dramatically less JavaScript by default. Thanks to the new React primitives, we're enabling ergonomic
ways to handle loading and error states, streaming
UI as it's rendered, and in the future, even mutate data. This new API is made possible
by years of investment into the React ecosystem. Incrementally adopt the
app directory available in VITA today. Go to Next.js.org/13 to learn more. (crowd cheers) - (speaks in a foreign language) I'm so excited about these
innovations in routing and the power of both dynamic and static data fetching coming
to every component thanks to React server components
in one unified experience. You can start adopting these features by introducing the app
directory into your new or existing code bases. This transition can be done
incrementally even one page at a time while the pages
directory remains fully supported and maintained, and thanks to Turbopack, developing on both the pages and app directories can be turbocharged. Next.js 13 doesn't stop there. Let's hear from Lydia about
what other innovations are coming to our toolkit. - Making a site fast is complex. We tend to think it's just about how you render your own components, but it's also about getting
third party assets right, like fonts, images, and scripts. When you don't get these right, you'll suffer from jarring layout shifts, frustrating input delays,
and confusing content delays. This is why Next.js isn't just stopping at building better compiler
and rendering infrastructure. We're also giving you
solutions to these common, higher level problems. Let's start with images. A huge chunk of the web
is made up of images. They account for 44% of a
page's weight on average. Getting images right is critical. The introduction of the
Next.js image components in version 10 was a crucial
step in the right direction. When we surveyed the Next.js community, 70% of respondents told us
that they used an Next.js image component in production and in turn, saw improved core web vitals. Since Vercel augments this image component with our global edge infrastructure, we can optimize images on demand for even better performance. This cooperation between
framework and cloud infrastructure has now delivered billions of
optimized images on the web with no developer effort,
but our work is never done. Next.js 13 brings substantial improvements to the image components,
both in performance and developer experience. The value of the React
component abstraction is its ability to encapsulate complexity while still providing a
simple HTML-like interface. With improvements on the
web platform available across all major browsers,
like native image lazy loading and CSS aspect ratios, Next.js
13 is shipping a better image component that uses less
client side JavaScripts that performs better and
maintains its familiar interface. Try out next/image in Next.js 13. We're excited to see the
next billion images you ship. The strength of the web
is its diversity of design and ability to personalize. The web at its best is a
hackable malleable medium for anyone to build on. Using custom fonts is a
huge part of that story. Custom fonts are great but
extremely hard to get right. You're probably used to seeing
fallback fonts causing layout shifts or even long
delays from invisible text before the right font is
painted through the screen. With Next.js 13, we are going to prove that customizing your brand's
type faces can be easy while your site stays fast. Last year, we added font
optimization to Next.js. This improved performance by
automatically inlining font CSS during the build,
reducing the total number of network requests. This was a small step
to making fonts easier. Today, we're reimagining
how developers use fonts with a brand new font system developed in collaboration with the Chrome team. This built-in module, not
only optimizes your fonts, but also removes any
external network request for improved privacy and performance by eliminating connection setup
times to third party hosts. This means you could import
a font from a registry like Google Fonts or your
own custom font files, and Next.js can automatically
deliver it for you, your custom brand identity
all on your own domain. We've also eliminated
layout shifts by building on the web platform's
size adjust CSS property. The new font module can
automatically avoid 99% of layout shift caused
by custom fonts and 100% of visual disruption from missing fonts. Try out next/font today in Next.js 13. Every time your link gets
shared across the internet, you have a unique opportunity
to make an impression with social cards. Social cards, also known
as open graph images, can massively increase the
engagement rate of clicks on your content with
some experiments showing up to 40% better conversions. Static social cards are time consuming, error prone, and hard to maintain. Because of this, social
cards are often lacking or even skipped. Once again, it's time to go dynamic. Until today, dynamic
social cards that need to be personalized and computed on the fly were difficult and expensive. Today, we're announcing
Vercel OG Image Generation, a new solution for
instantaneously generating dynamic social cards. This approach is five times
faster than existing solutions by using Vercel edge
functions, web assembly, and a brand new core
library for converting HTML and CSS into images and leverage to React component abstraction. No headless web browsers,
no costly infrastructure, and no more cold boots. Once again, the combination
of simple components with global edge infrastructure
enables amazing experiences on the web. We're so excited that
we're making things easier while also saving so much compute time and freeing up developer
and designer hours. Try out Vercel OG Image Generation today. We're committed to continuously
improving the toolkit developers have for working
with reusable React components and integrations for the
most common building blocks of the web, images, fonts, scripts, links, and even social cards. (crowd cheers) - (speaks in a foreign language) Next.js 13 ushers in a
new era of web development with major announcements
across three categories. First, we introduced Turbopack,
the successor to Webpack. Making incremental changes
during development can happen in as little as 10 milliseconds as we push towards the future of single
digit second production builds. On Vercel, this is a
compounding investment as teams collectively
save literally decades of build time thanks
to Vercel remote cache. Second, routing data,
fetching, and rendering. Next.js 13 introduces
the new app directory with built-in support for layouts and powerful new conventions, all of which you can adopt incrementally alongside your page's directory. When deployed with Vercel, your
React pages become optimal, serverless, and edge infrastructure,
which delivers dynamic at the speed, availability, and cost effectiveness of static. Finally, we continue
to expand our toolkit, which reaffirms our bet in
web platform fundamentals. By partnering with the Google Chrome team, we're giving you the best of both worlds, simple abstractions that
unlock powerful personalization for your brands. Everything we've shown today is possible by upgrading to Next.js 13. Head to Next.js.org/13 to
learn more and try it out. Now before the Q&A with the team that we're all looking forward to, let's hear from Loom about
how they are going dynamic without limits on Vercel. - Hi, I am Tatiana Mac, and I am a software engineer at Loom. (upbeat electronic music) Loom is a video communication
platform that really helps us to work more seamlessly, collaboratively, and asynchronously. My ideal developer experience
is one that removes barriers for me to create not at
the sacrifice of our users. Sometimes good developer
experience sacrifices user experience, and tools like
Next.js and Loom make sure that we're not sacrificing
the user experience for the developer but that
we're also not leaving them out. Vercel and Loom have this
really symbiotic relationship where we both wanna make
sure that we're able to provide new features to our
users with a lot of velocity and speed, but ultimately
empowering them to create where they want to at
the point of inspiration. Our entire marketing site is
backed by Vercel and Next.js, and the reason we're such
big fans of having it all in one ecosystem is that
we're able to focus on a lot of experimentation and iteration. Being able to use tooling
that prioritizes some of my personal ethos as an
engineer of accessibility and performance is so important to me, especially when it's
integrated into the tooling, so that at moments where I forget or there's something I don't know, that I can find the resources
to make those accessibility and performance fixes. At Loom, we had this project
called Learn to Loom, which was pretty open-ended in brief. Essentially, we wanted to create a product that could help people
understand the many ways that you can use Loom across
your day in work and in life. Vercel was critical in making it so that we could ship iteratively and to show key stakeholders
our progress throughout and to just really take
tooling out of consideration and allow us to focus on
ideation and experimentation within this project. We reach for Next.js for Learn
to Loom because we trusted that we didn't have to think about all of the technicalities
of the build process that, with a project
with such a large scope, with such important eyes on it, we could really focus on
coming up with great ideas, testing them, and taking
them to market quickly. Next.js is one of the few
tools that's at that sweet spot for the amount of
scaling that we wanna do. A lot of tooling becomes
outdated so quickly because technology is changing, and I think that's something
you've all done a fantastic job of maintaining, and I would
love to see that continue caring about our users who are
the most marginalized and at the fringes, creating
great experiences for them, and building an amazing future web. One of Loom's missions is to
allow people to work anywhere in the way that they want to, and Vercel's mission of
making that easy and seamless and efficient ties perfectly together, because together, what we are
able to do is allow people to work as seamlessly and
efficiently as they want anywhere. Let's continue to build a
faster, more performant, and accessible web together. (rhythmic electronic music) (crowd applauds) - How 'bout that keyout? That was great. All right, I hope you are
all as excited as I am about the future of Next.js. We're now gonna kick off the
Q&A and bring out members of the Next.js and Reacts teams. So why don't you all come on out, and we're gonna be answering
some questions here live in San Francisco, as well
as in London, in New York, and online for all the
developers tuning in on the Next.js discord. So please ask some
questions in the discord. We'd love to answer them right now and get some questions
answered from the team. So bring 'em on out. Woo, welcome the team. (audience applauds) All right, let's kick things
off here with a question here in person in San Francisco. Don't be shy, raise your hand,
and we have some mic runners who will come over, hand you a mic, and ask you some questions. So why don't we start with a
very excited person right here. We have Sam who can bring the mic over. Thank you, Sam. - [Young] Hey, thank you so much. This is Young from the Storebook team, and I'm really wondering about all of the new things you're bringing and how it will impact
the integrator tools such as testing in Storybook. So do you have any thoughts on that? - Yeah, Delba, do you wanna talk about how we're gonna grow the
ecosystem of tooling around-- - I actually think Tim would
be better for this question, cuz he's got the whole
roadmap in his mind. (laughs) - He does, he does. - Yeah, so, yeah, at this point, Storybook and other tools are
obviously not integrated yet, like for an alpha state for
Turbopack for server components, there will need to be some
changes to these tools. Same for tools like
Jest, like test runners, that kind of thing, but the plan is to have everything deeply integrated so that the whole ecosystem
can leverage server components and Turbopack under the hood as well. - Any other commentary? All right, we'll do another question. Anyone else here in the
crowd wanna take one? Up here in the top right. - [Sam] Right here. - And then we'll take
one from Discord next. Thank you, Sam. - [Reka] Hi, this is Reka. So if with the Turbopack it
says the API is not one-to-one with Webpack and we use Webpack heavily, also this server question,
where server use Webpack, and we using Monorepo and microphone.end, everything uses Webpack, and yes, and feels like a rug being
pulled out under from my feet when you're saying like, oh,
the Webpack is out of the door. What are your thoughts on
compatibility moving forward when we migrate all of
the infrastructure we have from Webpack? - Yeah, I'm happy to take
this from the DX perspective and then I'd love to hear Maya's thoughts, but from a DX perspective, we wanna make sure that we can make this incrementally adoptable for everybody and not make it a jarring transition over, but Maya can can add some more flavor. - Yeah, I would say, I
mean, we are selling it as the successor to Webpack. So a big goal is bringing
the community along. We don't wanna leave this
huge ecosystem behind. So we do plan to have some
sort of migration path. We might not be able to use the plugins that you're already using,
but there will be replacements that you can migrate over to. - One of the things to
add there as well is that from an extra side of things, we're not switching from
Webpack to Turbopack today or anything like that. So we're still maintaining
Webpack as well. We're still using that
in like if you upgrade to Next 13 today, you
don't add the turbo tag or the turbo flag to Next.js, then it'll not boot into Turbopack, and it will just use what
you had before, basically. Just back by Webpack and SBC, yeah. - Right, yeah, it's gonna be a long road. - Nice, it looks like we
have a question from Discord. So thank you for folks tuning
in online asking questions. I think this might be
a good one for Andrew to talk a little about. With these new ways to fetch data thanks to some upstream innovations in React, what does that look like for the future of the React ecosystem? - So yeah, this is a long time coming for React, not just Next. We've been looking into
things like suspense and some of the concurrent
features we talked about last year with React 18. I've been thinking of Next.js 13 as really like this is the real React 18 release, because even though we have a
lot of primitives in React 18, you can't really take advantage of them unless you have a framework
that it builds on top of those architectural primitives. So on facebook.com, Facebook
has an infrastructure that's based on relay and some
other routing concepts that, I mean, one way to think of it is that Next.js is an open
source implementation of that. In some ways, it even
goes a step further now with server components. So I'm really just excited for the rest of the React community to
now be able to take advantage of all of these improvements that we spent so many years
researching and building. So that's one thing. Then looking forward, I
think once everyone can get onto this suspense driven, server components driven architecture, there's so many things that we can build on top of that stuff. Just a few of them
we've announced already, like on our blog, is we're
working on ways to do, kind of, background pre-rendering of content. If you go to a website, I'll
use facebook.com as an example, and you navigate away from
newsfeed, for example, and then navigate back and
newsfeed is still loaded on that screen, it should be one component that lets you do patterns like that, and when you build on top of
things like server components, that level of abstraction
of really rich functionality with just a drop in component,
that becomes possible. Other things like animations,
I could go on and on. It's like this is a
really exciting milestone, because it lets us move on
to that next level of polish. - Yeah, I'm super excited. In the early testing I've done,
it's been fantastic to use for the new app directory and the new upstream React changes. So very excited for that for everyone. Another question from Discord here, how are the docs looking? When can we expect docs
to try out all this stuff? I think Delba knows a couple
things about the docs. - Yeah, yeah, so the docs are live. We can definitely go and check
them out@beta.next.js.org, and yeah, we have dark mode. - [Lee] Yeah, I know
that's a community request, dark mode, yeah. - (laughs) And yeah, they're
looking really great. They're not finished. Let's set the expectations,
but over the past few weeks, we've had a lot of help from our engineers and from our writers, and it's shaping up. It's looking really good. I do hope that people
will give us feedback. Oh, do you wanna talk about that? - Sure.
- Yeah? - Yeah, yeah, Delba's been
doing a great job writing a lot of these docs, but we made
it really easy for everyone in the community to give
feedback on these beta docs. The beta docs specifically
are for the app directory if you wanna try out all these
new changes we talked about. If you go to beta.next.js.org and you try to leave a comment, we have this new functionality in Vercel called preview comments. It allows you to comment on
the screen, you can log in, leave comments on specific pieces of text. You can put emojis on there. You can leave screenshots. So I think this will
hopefully make the process of streamlining feedback
for the community, giving input on the docs, really seamless. So definitely do that. Please, give us all your feedback, and we'll be furiously
making docs changes. Let's do another question
here in person, why don't we. We got one right here in
the front row in the middle if Sam wants to take that. - [Audience Member] Hi, so I
had a question about routing. In the past, whenever I
had a complex modular page, I had to predetermine what
components were available and in get server side props, I had to collect data for all of them and then pass it down to
the modular components. Has anything changed in
that with the new router that I can actually have
each one of the modules on the page fetch their own data? - Yeah, absolutely. Tim, you wanna talk about this one? - Exactly as you said,
you can now fetch data in server components, which means that you can
do more complex UI as well, like deciding what to render
based on props, for example. So fetching some data comes
back from, like a CMS, for example, that's deciding
what layout to render or like what UI components you use, and because of leveraging
server components, you can now decide to
sprinkle interactivity on the page based on what
that data fetch decided should be rendered, and at that point, basically means you can now
create like a really large, like say a page that has
an object holding hundreds of components that could
be decided by props, and if you don't render them, they don't get shipped to browser. So there's no extra client
side JavaScript for that. - [Audience Member] So sever
components is the key to, kind of, getting that feature? - Yeah, yeah. - [Audience Member]
Okay, thank you so much. - Yeah, thank you. Yeah, and when you use the app directory, it uses server components by default, so it's definitely worth checking out and giving us your feedback. Thanks for the question. I see a question here. What does it look like to upgrade an existing app to Next.js 13? Are there breaking changes? What can we expect? I'm happy to take this one. So if you go to the Next.js docs, we have both an upgrade guide for folks on the stable documentation
just on Next.js.org, as well as in the beta documentation, which is specifically if you
need to move things or you want to try out things in the app directory. So you can upgrade the Next.js 13. You don't have to use the app directory. You can use images, fonts,
all the new things we talked about, and kind of incrementally try out these new features as you're ready. So definitely check that out. Another question from Discord here. What is possible with Turbopack today? And what is still coming? - Yeah, so it is definitely
an alpha release. We wanted to announce this at Next Conf so everyone could fall
along with what we're doing. So yeah, immediately just stabilizing, adding support for all
the features for Next. We will move into Next
build production builds, and we're building it inside of Next.js to, sort of, prototype it, but it will be more than
just a Next.js build. So again, it's the successor to Webpack. You should be able to
build anything you want that you could build on
Webpack, on Turbopack. So looking at getting
that into more frameworks and, yeah, more people. - Nice, let's do another
question here in the crowd, maybe somebody from up top. Anyone excited and wants
to raise their hand? Got one over here, come on. - [Luis] Hello, I am
Luis, VP over at REPPI, pretty excited about all
the new announcements. If you remember, I gave a
talk at ISR, SSR, and whatnot, NWTFOMT, what's going on with there? So with next layout, my
question is I think it's a good improvement, but my question is around are we simplifying things
based on just one function versus doing ISR, SSR, SST,
or SR and wherever it leads? What does that look like? Are we going to still consider all of these acronyms or whatnot? Or is it going to be just one function that simplifies everything? - Anyone wanna take this one? - Yeah, I can take it. So ISRs, SSG, SSR, what they did is they provided
an abstraction for people to do data fetching and rendering. It was good, and it worked. However, I feel like the
abstraction took away from a lot of developers
having the opportunity to learn how the web actually
works, how caching works, how revalidate works. So with the new React RFC, which if you haven't had
a chance to see it yet, I would recommend reading it. It really does bring it
down back to the foundations of the web, right? So we want to teach developers
about caching, revalidating, fetching, but in a way
that aligns with the web and also that it's also
simple for them to understand without the additional a increments. - Yeah, yeah, and I think to your question about the patterns, like if you still wanna
have some static data, you can absolutely still
have some static data. If you wanna have some dynamic data, you can absolutely still
have some dynamic data. We're still allowing
the same functionality. We're just streamlining
the developer experience of how you write that and enabling you to do it at the component level, especially when paired with layouts. It's a very powerful way. I mean, I know just ingesting all of the community's feedback
for many years now, I know that people have
been looking forward to this for a long time, and I think there's probably
50 GitHub discussions asking for things like this. So I know everyone's very
excited for all this stuff. We'll take another
question from Discord here. How would the new caching
and fetching changes, how does this work with
the Next.js ecosystem, with the React ecosystem? How can we work with those library authors to help bring the entire ecosystem along? Maybe we can talk about
it from the React side and also from the Next.js side. - That's good? - You wanna go first? - Yeah, yeah, so, yeah,
there's a few things, new APIs that are being added. You might have seen use
and async components. So async function and
then that returns Next.js, that works in server components, and that is fundamentally for being able to await a certain fetch. However, then at that
point, you get this problem where say you have the
same data at two points in the React trees,
like you want to render in your layout the current
user and then in your page, you want to render the
current user as well or like some variation
of that that requires you to get logged in state
or something like that. Traditionally, that would
be really hard to do, cuz the moment you call
get user, for example, it would do a fetch, and that fetch would then return
some Jason that's on parse, and you can use that in tree. However, if you do that a second time, there's two fetches on the page. So you got a waterfall of sorts,
and the new thing in React and Next is that fetch
automatically does this, the dupings, like if you
do the same fetch twice, and Andrew will talk more about that, it will dedup that in the same tree. So if the same React
server components page is being rendered, if you
call fetch API.forsale.com with the same URL and then
you do that a second time somewhere deeper in the
trees, like in your page, for example, then it will
just give the same results so you don't get two fetches. That's one part of it, and then the other part is
there's a new cache API, which is literally called cache. You import it from React,
and it works a bit like memo. So if you used that
before, you basically parse in a function and get a
component back, caches, you pass in a function, and you
get a memoized function back that if you called it in the React tree, it will automatically dedup if the same perimeters are parsed in, and now this will allow you
to, like outside of fetch, which automatically does this, to have external data fetching libraries that do database queries
or anything like that to also have that deduping logic, but you might be thinking like, okay, that's a lot of extra work. Basically what we expect is
that the broader ecosystem will adopt the cache automatically
like as part of the SDK so that you don't have to do that, and it will work automatically. At this point, obviously, it's just out. So you'll still have to
add a cache yourself. - Yeah, and then on the React side, that was a great explanation in terms of what place open source
libraries fit into this. I'll just say that for the last year, every React developer that
I talked to has expressed in some form how hard it is
to do data fetching in React. If you're using Next, it's
obviously a lot easier. If you use something like
use SGWR, it's a lot easier, but everyone's, kind of,
wondering when is React gonna have built in data fetching solution? One way to think of this Next.js release and server components in general is this is the data fetching solution. It's not a complete one necessarily. There's a lot of other things that React doesn't offer out of the box. Next.js layers those on top, but I imagine things like React query are still gonna be incredibly important. There's been a lot of innovation in the open source ecosystem, and that's actually one of the
reasons we've been reluctant, on the React team, to
offer a built in solution, because if we had done
that five years ago, it would've been face
time classes or something, and it would've been based
on use effect or whatever. So we've been like very diligent. If we can't offer something
that is good enough, then we don't want to lock people into a subpar architecture. So the fact that we're coming
out with server components now and we're partnering with Next, I think that's our endorsement. That this is the data
fetching solution for React that everyone, I think,
has been been waiting for. Doesn't mean that it
is gonna snuff out all of the innovation that's
still happening in ecosystem, but you can think of them
as like the primitives that we think unlock the
next layer of innovation that can happen for everyone's React apps. - Yeah, I'm extremely
excited to see this next wave of community and ecosystem
libraries that are built for server components in mind, with client components in
mind and just are enabling all of the existing library
authors to, kind of, upgrade and provide these new solutions. It's gonna be really fun. We have a question from London. Will Turborepo be part of Turbopack? What is that relationship between
all of these turbo things? - Right, well, an exciting piece of Turbopack is this
incremental build engine. It's reusable. It's written in Rust since
Turbopack is written in Rust and Turborepo is written in Echo, but we are looking at
incrementally moving that onto the same core architecture. So yeah, sharing that core architecture, we're also looking at how
they can work better together again with that incremental build engine. There's a bit of an inversion
of control where instead of the build system, kind
of, controlling the tools with the CLI commands, the tools are controlling the
build system with a library. So I think that'll help
a lot with the DevX. We're excited for the future
and where that will go. - Nice, another question from London, then we'll come back
and do a question here. Do layouts in the app directory, how does that work with context or state? And I think it could be a
good time to talk a little bit about just if I have a nested layout, and I go to another page, does that state, does the page rerender? How does that work? - Yeah, yeah, that's a good question, and one way to think about it, It's not so much in terms of layouts but what type of component it is. Is it a server component
or a client component? And in the app directory by default, layouts are server components,
because there's lots of optimizations that we can
do with server components, like shipping dramatically
less JavaScript to the client. So one thing that you need to
be aware when you're thinking about layouts is, okay, how
do server components work and how do client components
work, and server components, you can't really use state inside them. So how would you tackle
this if you have a layout that is interactive, for example? And what we would recommend
in this case is to extract out the component that is interactive, like for example, it
could be a search bar, and then make it into a client component that you pass into your layouts. So that's, kind of, like
how you can handle state in your layouts, and then,
of course, you can always opt into client components with
the directive, use client, and then for context, context
is a little bit more complex, (laughs) and to be honest, I'm still trying to, kind of,
like wrap my head around it. So maybe Andrew can
help us with with that. - Yeah, so there is a
feature called server context that exists. It has some limitations. You can't just freely willy-nilly mix and match client context
with server context, and there's a technical
explanation for why that you can read. I'm not gonna try and
spill it out right now, but I think in practice, what
we're expecting is that a lot of the things that you would
use context for on the server don't necessarily need to be
contextual like per subtree and that instead, they can be per request, and so those don't need to
come in the form of a hook. So I think in Next.js, y'all
can correct me if I'm wrong, there is a way to get the
current request parameters, and it's not a hook, right? It's just like a function
that you can call anywhere, and it gives you, which is quite nice, cuz you don't have to obey
the hook rules, for example, but I was gonna mention
a little bit about the, I do think there's gonna
be, maybe, a period of a learning curve for people to get used to this server-client distinction. So I'm really curious to
see how that shakes out over the next few months as
people start playing with this. One of my colleagues who used
to work on React named Sophie, she had a really great
way of explaining this in a tweet once, and I'm sorry, Sophie, that I'm not gonna
express it as eloquently as you did in that tweet, but when you're thinking
about server components, just imagine if you do a mental audit of your existing React application, think of all the components
that only ever update when you do a navigation
or when you do a server, like a form mutation or
submission of something like that. It's a shocking number of
components that exist just that only ever update in those scenarios when you're already doing
a server round trip, and if you can just move all
of that code to the server, it's obviously way better. You don't have to download
all of that client code. Again, I'm sorry, Sophie. Go look at her tweet. It's a lot better. It's like 140 characters instead of that giant spiel I just gave, but I think that really
crystallizes, at least for me, forms a good mental model
of why server components is so exciting and why it makes
so much sense for Next.js to default to server
components until you need to add an extra layer of interactivity. - Yeah, and I think, too, if people go try out the app directory, they
try out server components, and they're feeling like,
oh, these are new concepts. I'm still trying to
figure all this stuff out. Rest assured that there's gonna be plenty of documentation education
materials from us trying to help everyone, kind of,
just bring the community along, cuz it's new. Everyone's gonna be learning
it at their own pace trying to grok these new concepts,
and it's something that we, kind of, wanna incrementally
move the ecosystem forward towards. Let's answer another question
here in San Francisco. We have one in the top middle. I haven't answered anybody on the side. So we'll take your question. I've taken a couple from the
middle if we wanna have one of our mic runners hop over there. Don't worry, people in the middle. I will also grab your
questions as well, too, but wanna make sure you
got your question in. - [Audience Member 2] Yeah,
I've heard a lot about servers, and I've heard a lot about the web, right? Keep mentioning Webpack
replacement successor, eventually. I'm curious about how you're thinking of the mobile form factor and
the React native ecosystem and lots of innovations and
things happening there as a part of all of these advancements
and this progress. - Yeah.
- That's a great question. - [Marcus] By the way,
I'm Marcus at MongoDB, if anybody needs a database. (everyone laughs) I'm in product. - Great shout out. Yeah, I'm sure Andrew
could talk a bit more about the React native side. That's a great question. - Yeah, I'm really glad
someone asked that question. I have had many conversations,
even among my colleagues at Meta, where people seem to think that server components is just, oh, that's a web only concern, but although Next is a web framework, they don't have a React native story. Really, I don't think of
it as being not relevant to native platforms. I saw Evan is here today
from Expo, and I would love to see Expo adopt server
components one day. We should really have server components for React native as well. There's no reason that
architecture doesn't make any sense in that environment too. So that's what I'm hoping is
the future of React native. It's this all of these
improvements we're talking about, like they're starting with Next, but I'm hoping that, in the future, any React app, like it's not, oh, does it implement server
components or not? It's just that's gonna be a
given for anyone writing React. So that's a really great question. We're not there today, obviously, but hopefully that's the
direction that we're moving in. - Nice, there's a, yeah, thanks. There's a question on Discord
about Tailwind CSS support. I'm assuming this question
is in relation to Turbopack. So we can probably talk about that. - Yeah, so we know Tailwind
CSS is very popular. So that's gonna be top
of the list of things that we're trying to support very soon. So I don't have an exact answer, but we are looking at supporting
some layer of JS plugins that would allow you to use other tools, and I guess right now, you can, kind of, there are workarounds
where I think you can just add a script tag. So yeah, in our layouts playground that I think should be public now, you'll see that that it is using Tailwind. It's not the most optimal,
but that should work for now, and we're working on a better solution. - Nice, another question from Discord here just around how we can
use this new architecture in the app directory which
uses server components to do AB testing or experimentation. How does that help make
my application faster by running these things on the server? Tim or Delba, do you
wanna talk about that? - Yeah, it's similar to
what we've talked about in the previous question,
which was about can I, now, do data fetching
in any place, basically? And basically deciding
what component to render in a server component
allows you to do AB testing of separate trees or anything like that. There's also more advanced
routing cases that we're working on and namely parallel
routes, which allows you to basically create two trees that fall under the same router and then
you can switch between them. So they can still create pages
in the file system that map to a certain spot on your page, basically. So yeah, it's definitely
possible we'll be creating more examples and best practices around what you can do here very soon, yeah. - Awesome, let's do another question here. I'll come back to the question
in the middle that I missed if Sam potentially wants to run it over or Kylie wants to run. Oh, Sam's got it. Thank you, anyway, Kylie. (laughs) - [Adam] Hi, I'm Adam from Spotify. A question for Andrew
between the data fetching that you were talking about
and the RFC, which looks cool. What are the big missing
pieces that you're most excited about that's coming to React,
if you care to talk about it? - Yeah, so in that RFC, I
really apologize for people who maybe haven't read that,
because we keep alluding to it, but I think Tim gave a good overview. In that RFC, the biggest thing
we mentioned hasn't quite worked out yet is the cache
API that Tim talked about. We have a general sense
for how that should work, and I think, on the server, it just works without very many caveats at all. It's really how should that
work on the client where once you start doing
things from the client, things like cache invalidation
become a real issue that you need to solve. Nowadays, libraries like React query or use SWR implement patterns like that, but there may be room for
React to have some level of caching built in. I'm not sure, yet, how it will layer with these other solutions, but I think it's like a
common enough use case that even on the client,
React should probably have some built in solution for this. I'm not too worried about
it right now, though. I don't think it's a blocker
for us to start using these APIs on the server,
because even in the future, it's really best to do as much
data supply chain as possible in your server components, and another thing is I think people are gonna want to anyway, cuz
it's a lot more convenient if you can just access
your data sources directly without having to go through
this extra API layer, but yeah, I think that's probably
the biggest missing piece. We're also looking at how
do we make it just ergonomic and avoid some foot guns
where people are doing, you can do a cache to get
request in your component, but you shouldn't be sending
off server mutations directly inside your component. So we're still trying to figure out what are the right patterns
and guardrails we can put in place to prevent those common mistakes, and then also, I guess, I'll just say about the the use stuff. I think people are gonna
find it very exciting, but to me, the much more exciting thing is that you can just use async
await in server components. - [Lee] Yeah, that's pretty cool. - That is what I think is really cool. Use, it's neat, but honestly,
it's a compromise, right? We would like to just use
async await everywhere, and I don't think it's out of the question that maybe one day, you will just be able to do async await directly inside your client components as well, and that could be quite nice, but in the meantime, I think
use is pretty nifty as a way to bridge those two worlds,
and if you're scared by the concept of a hook called use, that's really how I
encourage you to think of it. Just in your head, sub out the word await every time you see a use, and
that's basically what it is. - Nice, that's helpful. Another question here in SF. We've got one right here on the end. Sam's putting in great work. - [Adam 2] Hey, I'm Adam
from Wonderman Thompson. The previous video
referred to accessibility on the web a number of times, and I don't know if that
is CAG or core vitals, which is probably still predicated on CAG, or something different. Can you just talk about what
that means for the tool set? - Yeah, so I'm happy to take
this on the accessibility side. So in the pages directory in
the Next.js router right now, we've added some
accessibility features to help with route announcements
for screen readers as well as just trying to
build in common foot guns that people might have
building web apps directly into the framework. So for Next.js 13, for
example, the image component now requires an alt tag, which
I think is just a good move for the web in general. So we like to talk a lot about trying to make the framework more
accessible in terms of people who can use it with a screen reader or other assisted technology, but then also to your point
about like core web vitals, we, kind of, look at that as a way of just helping uplift the performance of all Next.js apps on the web. We want to understand the
real impact of these sites on potentially multiple
different types of devices, multiple different types
of internet speeds, and how that actually
is impacting page loads in the real world in the field. So that's another thing that we care about a lot as well, too. Thank you for the question. We'll take another one here in the row. Dan, thank you. - [Fuad] Thanks, hey, Fuad from Indent, and curious for the teams who
already have very complex next steps, maybe one CSS and
JS Bingo and have a lot of different things
going on in their apps. What would be some of
the features or pages of their app they should look
to migrate first to Next 13? - That's a good question. Anyone particularly wanna take it? - I'll take it. Yeah, so the important thing to know is that you can just upgrade to Next 13. There's a few breaking changes. You'll want to check the upgrade guide. That all relates to pages as well but also app if you enable it. So example of that is we're
upgrading the default browser target, which now it use modules, the link component much
requested feature was not having to add the ATAC as part of a link. That is no longer required. It's very important that you
run the code mod, though, if you have an existing app. So definitely look at that. It throws an error if you don't. So it should be fine, but in general, that code mod will fix every single case. It will opt all your links
into the old behavior as it's called legacy
behavior, basically as a prop, and it allows you to incrementally move all those links over, and then
for the story for how you go from pages to app, which
is something that a lot of people want to do, I assume, that is a much larger migration overall. We've started this for forsale.com and the for sale dashboard,
which for their apps, and what we've seen work
the best is basically like sorting page by page. One of the benefits, right now, is that you don't really have
a layout system in pages. So you can just copy over
the page that you have today into the app directory, just
put in all the components, but maybe you have an underscore app, and you always have to add a
route layout, which is HTML, and that can just live
there as a client component, and then at that point, the
app will just run, basically, and you get some additional
features from that as well, like being able to import
global CSS anywhere in pages or layouts, which right now, is only in underscore app. So you can move some
of those into the page if it's page-specific. Yeah, it's like there's a
bunch of other things as well, like use router is no longer next/router. It's called Next Navigation. We'll have an interrupt story there where you get the same
object back from use router that you get in the app
directory in pages as well, but it's just using
the old router instead, and that's mostly so that you
can just upgrade individual components as well while still
maintaining functionality in the pages app. Really, the way to see it
or the way that I see it is that pages and app are
like two separate apps. They don't have clients and
navigation between them as well. They'll just do a full page navigation, cuz everything under the
hood is different for app. So yeah, besides that, there's
like some other behaviors in the new router that
we're not in the old router. So yeah, definitely the
recommendation is to go page by page so that you can like solidly
verify that it works, yeah. - And you brought up a very good point, which is client components, right? So the page, when you
migrate, is a component as of we have now. It's a client component,
and then from there, you can decide, okay, what
are you going to pull out for your layouts and the use router, how does the behavior
change from pages to apps so that you can migrate
those features as well. - Yeah, so the way to think about it is client components are the
components that you have today. There's almost no difference there. It's just that there's now a
new concept of serve component. So the thing that we had
before is now a named thing, which is called client
components, and because of that, if you add use client to an
import or to the component that was like your branch
component, for example, they will mostly render in the same way. - Yeah, for those who are more curious about the upgrade path and the code mods, we have documentation on code
mod for the link component, code mod for the image component just to automate the whole process
of upgrading as well as some documentation on the
breaking changes in 13. It's like we updated the
node version, I think, the supported browsers, just
some couple things there to check out as you're moving
your applications over. Two questions on Discord here. One, some folks have asked about another announcement
Vercel made today. I'll just quickly mention that, and we can get on back to Next.js, but Vercel acquired a
company today called Split B, which is a privacy focused
first party analytics company, and you can start using that
today on Vercel if you want. So check that out on our blog
if you're curious more about that, but we'll get back to Next.js. There's a question about
using API routes with Next.js and how we feel about the
breakdown between the front end and the back end. I know that Delba and I have talked to a lot of developers about this. They wonder should I use API route? Should I not use API route? Should I put my entire
back end in a Next.js app? What's the right architecture? And I think the answer is, it depends. Depends what you wanna do, yeah. - Yeah, yeah, I think it depends. It depends on whether you're,
kind of, fetching directly from your API or you're using
an ORM like Prisma, right? - Yeah. - And that's where React comes
in where you have to choose, okay, am I going to use fetch
or am I going to use cache and maybe, perhaps, an API route. So I would actually love to
hear more from team in regards to what are we thinking
in terms of API routes, cuz people will probably have
a lot of questions about that. - There's something coming. So app doesn't have API routes right now. The main reason for that is that we want to carefully consider like
what the API for that is, no pun intended, and it
will be like a mix between what you can do today
and some new features, like there's some stuff that
server components also unlocks, which is, for example, what if you want to individually rerender a
single component on the page that is backed by a server component, and that's like still things
that we're looking into, and we basically want to
make sure that that all ties in well with the layouts
and what we announced today, and a part of that is also
how do you handle a mutation and forums and things like that. So we're looking at the total
package for how to do it. - Exciting, that's a big update. We'll take one more
question here in the crowd. Anyone, anyone, question? We have a question over here? Okay, let's take that one. I'm sorry. (laughs) - [Brian] Hey, there's a lot
of excitement about server, oh, I'm Brian. - Hey, Brian. - [Brian] A lot of excitement
about server components and a lot of talk about
ergonomics and stuff, and I'm wondering what's the
experience that Next so far for early adopters and folks
playing with server components for things like debugging or
profiling or things like that and what are your thoughts
about tooling around that? - Yeah, I'm happy to talk
about this a little bit. Delba and I have been
in the weeds, kind of, building some examples, trying things out, and we've had some
amazing community members also give us some feedback
on some of the early stuff. So thank you to everybody
who's helped out with that. I think the, kind of, blunt answer is it's still pretty early. There's still things we're
trying to figure out. We really want to have
a great debugging story and make it easy for people, not only when it's the good path, but also, when it's on the unhappy path. So I think working with our
community and other tools that are in the community to
help make that process easier, I think, will really simplify things, but I'm excited to see
that progress further, because as we move into this new world, we wanna make sure the tooling
and the debugging tools come along for the journey. It's a critical part of
building your app, yeah. Any other comments on that? - Well, for folks who
don't know, that's Brian. He created the React dev tools,
and now, he works on replay. So we will also be adding
it to React dev tools that support post React
dev tools at some point and maybe replay will
have integration as well. - He knows a thing or
two about this space. - Yeah, he knows what he's talking about. - Yeah, so we've got about a
minute left before we will go and cut over to the community
talks for everyone tuning in, but just wanna quickly also do a shout out to check out the Vercel Twitter today for a special swag drop from KidSuper. You saw him before, and
you'll want to check that out. There's some really cool
gear dropping there. Thank you all for asking the
questions here today in person in London and New York and online. With that, we can wrap
things up here for the Q&A, and we can head back
to the community talks, and thank you all for joining. Everyone please give it
up for your speakers. (audience applauds)
