Tim Neutkens details the new tech in Next.js 10! At this year's NextJS conf, Vercel announced killer new performance features that came from their partnerships with Google and the React Core team. Tim shares shares what these improvements mean for users and developers alike.
Tim Neutkens — Twitter, GitHub, Website
chantastic — Twitter, GitHub, Website
Join the discussion Discord 🎉🎊🥳
Listeners of React Podcast are chatting on Discord!
Join us Friday at 10am CT for a friendly chat thru the latest episode.
It's fun, interactive and all are welcome!
When you push code with errors, and those error makes it all the way to a user, you want Honeybadger monitoring at your back.
Get 30% off for 6 months Honeybadger by mentioning React Podcast at sign-up. There's no credit card required.
Just visit Honebadger.io.
In over your head with a React or React Native app?
Infinite Red can help.
They are React Native core contributors who've been designing, building and shipping apps for over 10 years.
Learn more at reactpodcast.infinite.red.
Please join us in donating to the Equal Justice Initiative
Thank you Ben Myers for supporting this week's transcript!
Chantastic: Tim, welcome back to "React Podcast."
Tim Neutkens: Hey, thanks for having me.
Chantastic: [laughs] I'm excited to get you back on the show. Last time we talked, it was maybe Next 9 was the release. I don't remember exactly how long ago. It's been a minute and you all have done some amazing stuff. Do you remember what it was that we covered last time?
Tim: Last time we talked about automatic static optimization. That was something we introduced Next 9 and a bunch of other features. That was one and a half years ago or so. A lot has happened since then.
Chantastic: [laughs] Totally. A lot happens in 18 months for sure. Amp was a pretty big headline feature at the time because you had just started working with Google, with their teams to figure out what it was that they wanted to see in this static site generation and how you can better optimize for things a company like Google cares about.
Tim: Yeah, exactly. In Next.js 8-point-something, we released AMP support, which was a first collaboration with the Google AMP team to basically make it easier to alter AMP stages which is this format that use Web components. It's basically a component framework where you can import certain components into AMP pages and then use those instead of creating your own mainly.
Later on, we introduced collaboration with the Google Chrome team which is completely separate from the AMP team, where they basically are helping us improve performance for all Next.js applications but also build on top of existing Web standards and bring optimizations that were previously not possible because you did not have the end-to-end solution for it basically.
Chantastic: I love that. It is funny you mention the Google Chrome and the Google AMP team are two different collaborations. Oftentimes, we have a mental model of...Even though these companies are huge, they work together on everything. No, it's two different teams.
As you've been doing this, it sounds like you've been working with two different sets of people but in the same organization.
Tim: Yeah, exactly. Large companies like Google, and Facebook, etc., they all have so many teams in there. They could be not working together, or they could be under the same org, then working together, but side-by-side. There's a lot of intersection between AMP and Chrome, for example, because they try to optimize performance in certain ways.
There's also many teams inside of Chrome itself that are completely focused on other things, like people building Lighthouse, and people building Chrome Dev Tools, and all that. Those are like different people from the people that we're working with, for example. They're all in touch of course because they are in the same org.
Chantastic: Interesting. It must be fun to have reasons to go through the different parts of the org chart, as you're developing Next.
I wanted to ask, so you had just put on a huge conference. You have Next.js Conf. There was a lot going on there. A lot of really cool releases.
Before we talk about the things that are specific to Next 10, I want to get a sense of what putting on that conference was like? Were you surprised by anything? What's the Next community look like these days?
Tim: Definitely. Two weeks ago, 27th of October 2020, we had a conference at js Conf. We had 70,000 sign-ups with about 35,000 people attending.
Chantastic: Damn.
Tim: It's 50 percent. We had a keynote and in the keynote, we announced Next.js 10. Not just Next.js 10, we also announced Next.js Analytics, which is the new service that allows you to measure performance. We introduced Next.js Commerce, which helps you get started building an ecommerce site really quickly. It's like a starter for building an ecommerce store on top of Next.js.
That was created together with the big commerce team, which is a surface-to-surface ecommerce provider.
Chantastic: Nice. It's really interesting. This is a really fun event to watch from my perspective because it seems like you are building...So you have the next platform, and it is pretty stable. Spoiler alert, Next.js 10 doesn't have any breaking changes. Has a lot of new features but not breaking changes.
It's cool to see that you've started doing more to augment Next. Whether that be Next Commerce, etc. Tell me a little bit about how you see Next in these coming years and what it will look like to develop on Next.
Tim: First of all, like you were saying, there were no breaking changes in Next.js 10. The thing that we're basically trying to do is make it as easy as possible for people to upgrade to the latest version, be that a fetch version, minor version, or a major version, even.
Even if a major version would deprecate something, we would always, give you another way to do the same thing, but probably more efficiently or in a different way that is better for bundle size or for other metrics. Really committed to making sure that you're not getting awful upgrade path where you spent months upgrading, then figuring out, how all the new things work and all that.
It's pretty stable since we released Nexus 9. We actually spent a lot of time in the first two years or so Next.js is now four years old. We released many major versions, mostly to upgrade underlying dependencies, that are major version of greats like Babel and webpack, and all that.
The core API is still very true to what the first version had. You still have pages directory. You still have file system routing. You still have the link component. You still have NextTab and all that.
We're continuously augmenting incrementally towards a better way of doing things or integrating a way that people are already doing things in their own application, than making it easier for them to not focus on those specific bits when they start a new application, or they can cut down some code in their current application, basically.
Chantastic: I love that. Now you touched on something that I like to talk about on this show and have very few opportunities to talk about, is versioning. It's interesting, because you're on version 10 right now. There's no breaking changes.
You mentioned a little bit about how you think about versioning. How if you have an underlying dependency change, you'll make a breaking change for that. Are there other things that tie into major versions for an API that you own that doesn't have breaking changes?
Tim: Yeah, for sure. It could be that like an example of that is Next.js allows you to configure your Custom Webpack Config. If you want to add in, Custom Loaders, or Custom Plugins, that all is possible. If you do so you lose out on us being able to know that your application is going to work if you upgrade.
You make some edits and maybe we change something in our the Built-in Config, and then, things could potentially break. You're making some edits in an object that like we didn't know about. Then, those could be like, "OK, we know that the majority of Next.js apps is fine to upgrade."
If you're going to upgrade and you have Custom Plugins like Webpack Plugins that could break, we're still going to do a major. For example Webpack 4, or Next.js Webpack 4 that doesn't have Custom Webpack Config, is going to run final Webpack 5 as well.
We made sure that it's completely backwards compatible. Even with breaking changes in Webpack itself, we go for those as well as a backwards-compatibility layer. Then, we don't know for sure if it's going to work for all Next.js app. We don't release it as a minor or a fetch version.
We also have many integration tests. Pretty much all our tests 99 percent or so are integration tests that run against Next.js apps being booted in continuous integration. Actually, the tests are written against a browser instance that is accessing pages in the same way that you would do it as a developer.
Chantastic: Interesting, I like this, because it stands in pretty interesting contrast to the way React versions. It's like we've been on the version 16 of React for about three years. That's one of the reasons I asked. It's really interesting to see different people take different strategies for how they want those versions to communicate.
This is kind of a social contract of "We want you to feel comfortable" and versioning allows us to communicate these groupings of features, these groupings of capabilities and mental models are all in this version. They may or may not change in a way that impacts you in this next version.
Tim: Yeah. React does a pretty good job at versioning. They also have a lot less scope because it's only rendering UI and doing all that stuff around it. It makes sense that they're on a major version for a long time. You would expect a React 18 that has concurrent mode enable by default or something like that or some compatibility layer. That's all expected, let's say, right?
Chantastic: Sure.
Tim: React 17, for example. There's no breaking changes, but there are some nuances to it. The new JSX transform that works slightly differently from what people have been doing before. The compatibility of running multiple React applications in the same page under different routes and all that.
That's important. Incremental migration stuff that they put out in React 17 that you don't immediately need per se, but it does allow for new approaches to be taken.
Chantastic: Yeah, I love that. One thing I wanted to touch on is that...Go back to just a little bit, you mentioned earlier on that Next.js have had 70,000 people registered, and you were supporting peaks of like 35,000 attendance at a given time. I'm curious.
This streaming conferences is a fairly new thing given coronavirus and how we've been thrust into this. It's interesting. I know a lot of people who expect the audiences of sub 10,000. There's probably a lot of platforms that are designed for that. What was your experience putting on a conference that was going to need to support about 40 to 50,000 people?
Tim: Going in, we knew that there were going to be...There were 70,000 sign-ups at the day of the conference itself, so that could be a key goal of 70,000 people watching at the same time, right?
[laughter]
Tim: In reality, there's always some dropout rate of people that can't attend, or it's too early or too late for them in different countries because this is all over the world because it's online. We start evaluating a lot of the...
There's a bunch of fast providers that are now going into the virtual events space, building out virtual events and all that, but we weren't sure if we could handle that many people. In a general conference, it's not going to be like, "OK, we have a peak of 30,000 people." It's a few thousand people. There's a huge difference between a few thousand people and 70,000.
We set out and we knew that we had to build something ourselves, so we went out and we started...We dogfooded around our own platform, set up a self platform where you can host your Next.js applications and Next.js itself. The conference platform for Next.js comes completely built on Next.js.
One of the cool things about that was that we could dogfood all the new features in Next.js 10, like the Image component and a lot of other new features. By doing so, we know Next.js scale to millions of people because we see it every day with really large companies, but we also had this case to verify. We can run these types of conference on the Vercel platform, no sweat. We didn't have to do any like SRE type things.
It all just like riptide on itself. That was a nice thing to see. The other cool thing is that we're now wrapping up the code that we built for the conference, the conference platform itself. We're going to release that as a separate example, or like a starter kit for building your own conference.
Chantastic: Nice.
Tim: If you want to create a React podcast-conference, you can do that.
Chantastic: I wouldn't have to sustain nearly as many people as you did, but yeah, absolutely. That's interesting. You're starting to make more of this predefined starter kits for Next. It seems like Next itself is becoming a little bit of a platform where you start with Next, and then you can build on to it like these tailor-made things, whether that be commerce, whether that be a conferencing solution.
It seems like more and more of the effort is going into these tailorings of Next towards a specific need.
Tim: Yeah, for sure. A lot of roadmap is based on either issues that we run into every day like people having problems with a certain approach inside of Next.js. An example of that is in Next.js 10. We announced that you no longer have to use a href and s on the next/link component, so you can just use href. We'll automatically resolve that to the correct dynamic route.
Reduces a little friction if you ever used Next before using dynamic routes, which is like the path segments. You had to manually provide like, "This is the page. This is the href that I want to go to." Those are two different things. Now it's just like, "Provide us the href, and we'll figure it out for you automatically."
Chantastic: Nice. This ties into a little bit of a thesis, or a design perspective that I've been flushing out over the last year, which is in React having a strong migration story as you go from lowercase i-components to uppercase I-components, and how there's a natural tension...
We've seen a lot of Reacts to libraries that go full-in on React and do wholesale replacement of some type of long-standing Web links, right? It seems like, with href, with what you're doing with images, which we'll talk about soon, it's like narrowing down on how to make that migration path from the lowercase HTML element to the uppercase component element a lot more, I guess, virtuous, or a lot easier to switch those things on and off as needed.
We're seeing this a little bit with href making that a little bit more like a regular href, but also with image. Could you talk a little bit about the design in making that migration, and those mental models a little bit easier for people who are transitioning?
Tim: Yeah, for sure. When we released the Next Link component initially, that was back in 2016. The end of 2016 when Next released, the very first version had Next Link. That was using the standards at the time like React.cloneElement, nested child, render props for another thing. Hooks are another thing.
Pretty much all the things you know today are another thing. Out of that came, you have to write link, then nest tag inside of there. Href has to go in the link. Then the tag is a tag without any attributes. It was fairly normal at the time.
Over time, we added dynamic routes. That basically allowed you to say, "I want to have some path segment going into..."Say you have /blog/slug or something like that. Then you want to replace "slug" with "Hello World", or "My Own Blog Post," etc.
That is something that we introduced later. Then we had to add in this property called "s," which is, the href is the page and then "s" is the route that you want to go to.
They have to link to the page name instead of the actual URL that you had. The writer knows this is the page I need to render this specific URL. It also allows to map different things to a certain page.
Over time, we realized this is adding a lot of friction to the end user, like the developer using Next, because either they forget and they get a different behavior than they wanted to.
That's like full page transitions. If we can find a page, it would do a full page transition. Would still work as a transition, but it's not the same thing exactly. We want to reduce the friction that you have as a developer coming from like, "OK, I'm going to do a link component with href to a dynamic URL."
That was something that came up quite often. We knew it was a pain point. We had to fix it. It required some architectural changes as well, like inside the Next.js core. We spent a few weeks preparing towards that point, as it unlocked other features as well.
Now we're actually driving into the direction of, we're going to have that same experience as your native pay tag, for example. It will work for you automatically. We're lifting a lot of the brick out of your hands.
Same with the Next.js Image component, which we haven't talked about yet, which is a new component that was introduced the Next.js 10, where you can replace the IMG, HTML tag inside of your JSX with image. It will generally work if you have a width and height set.
I'm saying if you have a width and height set, because it does a few optimizations for you. It allows you to prevent layout shift. Layout shift is this new Web Vitals. Now, like turning on words that you might not know. If you go to web.dev, and you look up for Web Vitals, you'll see that it's a new standard that Google is going to use to index pages.
Chantastic: Interesting.
Tim: It checks for performance of a site. If your Web vitals are good, or Core Web Vitals are good. It's certainly an indicator of your site has a good, fast experience. That includes Largest Contentful Paint, First Contentful Paint and Cumulative Layout Shift.
Cumulative Layout Shift is just jumping around of items on your page when it's being loaded. We've all seen this. Everyone that has used the Web has seen this before, on any site, not any side but on many sites, where you load the page, especially a mobile and you start scrolling. It's like I wasn't here when I stopped scrolling.
Now it's at the bottom of the page for some completely new section of the article. That's because of layout shift. Ads come in later. Images come in later. Then, they take up the space that they wanted to but the browser didn't know that it was going to take up that space when it was being requested. The developer had it marked like, "OK. This is the space I'm going to need to render this image in this specific page."
That is what Next Image helps you with. It forces you to set a width and height, but then, it allows you to...That's the width and height that you would want to expect, but it's not like width and height on the image element because it's not going to rip out of idea for example or something like that.
We have different layout options that allow you to choose which layout you're supporting. If you want to have responsive images, you say layout responsive, and it's going to stick with the aspect ratio of the image, but it's not going to scale down or scale up in a way that you wouldn't expect it to.
Chantastic: I really like this and the Web Vitals is a really important tip. As far I know, the way Google index is pretty heavy on the performance of a site or at least that's taken into consideration quite a bit. Maybe even more so than people would think.
Knowing what the standards are and what the things are that the Google Crawler is looking for in terms of a fast site could really provide a lot of value to people who want to optimize but don't really know what the most important things are. I want to talk about a little bit more about the image optimization techniques specifically.
I know it can be a little bit of a weird mental shift to think, "I'm putting these specific numbers in for width and height but it's not actually going necessarily be those depending on my layout and whatnot." What are some of the things that you're doing for people to optimize images? Also, what is WebP? All of those things that happen at the optimization phase of the image component.
Tim: For sure. The Next Image component is like a layer on top of the normal HTML image element, but we tried to add in all the things that you would generally forget to add if you're building a site yourself. Even if I would go and be like, "OK. I'm going to build a simple HTML page like the defaults of the image element. OK, we're not going to lazy load. Everything is going to be requested immediately."
It's all sent to the browser and it's going to display them all even if they're way down in the page. Maybe your site is [inaudible 26:04] unplug and it has all the images loaded already. That has some downsides because it's going to take up network when you don't want to because other resources have to be loaded first. Also, too many ads and layout shift because you don't have width and height set.
You're probably also not serving the images in modern format like WebP or AVIF or something like that. This is what we aimed to solve with the Next image component where the defaults are there to help you get better performance, better Web titles and then, specifically, layout shift and Largest Contentful Paint.
Going back to Web titles, just to give an example of that, Largest Contentful Paint is generally measured as the largest element in the viewport when a page loads. The large element, in general, like if you go to most websites, it's going to be a really large image of something. Could be a person waiving or something like that or it could be...
I don't know if you go to my website. There could be a picture of me and all that. That image has a really big impact on that Largest Contentful Paint metric. If that image loads in fast, the Largest Contentful Paint is going to be fast. The image component actually allows you to...If you start using it, it's lazy loaded by default.
That means it's only loading images that you can see or that you're close to seeing. Then, images that are in the initial viewport, you can say like, "Oh, this is a priority image." When it's a priority image, you don't get the lazy loading via a query. You get the immediate loading.
We also inject a preload into the head of the page. This allows it to be, basically, loaded as fast as possible. We've seen big improvements in Large Contentful Paint up to 50 percent in some cases, but in more cases, then not, basically so that's a good ADCOM there.
For all the other images on a page like the images in the footer or the images in your blog posts that are down in the blog post. Those are all lazy loaded. Then, the width and height is needed to calculate the aspect ratio to make sure that the space needed for the image is there when you're loading the page, instead of when the image is loaded, basically.
Chantastic: This is fascinating. I've done a lot of design in front-end development. Images are one of those things that you have the best intentions about, but when push comes to shove, you just get it up there, and you're like, "Yeah, I'll fix it later."
I like this notion that you have a nice migration path, just using the small I-component to get it up there. You can upgrade it to the large I-image component, and then have all of this capability to control the size, quality, and speed of that image being loaded to users.
Tim: Yeah, exactly. So far, we've only covered the component itself. Like, "This is what the component does." It's like throw in any image. It will do that for you. There's another aspect to this whole image component, which is...
Because Next.js is likely to handle the end to end or that we handle the end to end basically for you, that goes from compiling your death server, your production server being started, and all that. It allows us to add in extra functionality as well.
What we did was we implemented a image optimizer that works on demand. It doesn't increase build times, for example. It runs in development. It runs in production. It works anywhere, basically, and that allows us to do more optimizations.
You give us a URL like /profile.png, for example. That's a PNG. When your browser tells us...Because then, what we do is we automatically prefix that URL with our image optimization POT. Then, what we do inside of Next.js, the production server is take that URL, fetch the image, check what your browser support.
Basically all browsers, they publish in their accept header. This is the format that I support for images. That could be, "I support WebP." It could also be like, "WebP is not there, so WebP doesn't work."
WebP is this format that Google created, which is a phrase like a lot smaller than the general PNG or JPEG, but without quality loss. If we convert those images from the original format into WebP and then serve that to browsers that support it, we reduce the amount of bytes that have to be sent. You get smaller images, but without any of the downsides, basically.
Next.js has that built-in. We detect like, "OK, You support WebP. Here's the WebP image, instead of the original image." Then, also, we support resizing the image.
We have this default set, using srcset on the image element. It's all like Web standards, basically, that allows you to...When you create this image, and you just put in the same URL that you did with the normal image stack, it's going to create smaller versions of that image for smaller browsers, for your phone, for your tablet, for your laptop, and then also for desktop.
It does it automatically. You don't have to configure anything. You don't have to go in and know about all these different things like srcsets and all that, but it will just work automatically.
Basically, what this allows us to do is, surf smaller images across the board. If you're on the phone, the image being displayed is generally smaller than if you're on your laptop.
Generally, we forget to do all these optimizations, because they're hard to do. You have to set up these different build tools. You have to know about srcset. You have to configure srcset that makes sure it happens for all the images that you're using on a page.
This could be different components, different layouts, all that. It becomes pretty hard. Then, what Next.js allows you to do is, just use next image. A lot of stuff work is abstracted away from you, allowing you to focus on just like, "OK, I need an image here," and that's it.
Chantastic: I do think that's super interesting, especially that it's integrated in that full-stack next framework, because there are services that do this, but that the handoff is not always delightful.
It is nice to just, have your images where you expect them to be, and then have next to the framework figure out all of the benefits.
Specifically with WebP, I know a lot of people have wanted to try embracing that, but doing that is so complicated. It's almost never worth the time. To get that for free is interesting.
Tim: Yeah, exactly. We did some research on HTTP Archive. It has some data on images. It's basically 0.3 percent of images, it's using WebP currently. It's still quite a few websites, but it's not enough if you're wanting to optimize in that way.
Even newer image formats like AVIF, which Netflix is adopting. The Chrome team is also pushing for now is even smaller than WebP, but with even less quality loss.
That's the format that we're going to support in the future. All you have to do is upgrade Next.js, to leverage those. You don't have to know about what AVIF is. It will automatically know if your browser supports it. Then, it will serve it to them, where possible.
Chantastic: Awesome. Now in terms of deployment targets, I know that, obviously, all this stuff is going to work with Vercel. Are there other deployment targets, at this point, where features like this are going to work right out of the box?
Tim: Yeah. Next can be deployed anywhere that supports Node.js hosting. That means if you're running Docker, or you're putting it on Heroku, or like anywhere else, it's going to work. You're using the Next of Node.js server. We set the correct cache-control headers. We do everything the same way that you would do it on Vercel, for example.
On Vercel, you get a few benefits there, which is that you don't have to manage your own infrastructure. You don't have to worry about like, "OK, can I actually scale these thousands of images that I have on the disk that I put in into my Docker container?" Also, you don't have to worry about scaling up the application because all the Next.js pages become serverless functions, which can scale infinitely.
The [inaudible 36:40] basically becomes your database, not so much the platform you're hosting the code on. You can host Next.js anywhere you want. Many companies hosted on their own private infrastructure, or some other cloud provider.
Once you host them for sale you basically get a complete workflow from end to end, where if you do a commit on your [inaudible 37:10] branch, you should get a automatic preview deployment. You can review that and then put it into production, basically. That is being done by some really large companies as well. I'm not sure if I can share which exactly, so I will not say right now.
Chantastic: Sure.
Tim: Actually, I can put that into the show notes. The image optimization works anywhere you want to host as long as it's not using Next export, so static exporting. Because we don't do the image optimization at build time, like I explained. It runs on demand.
The reason for that is that we didn't want to basically make your builds slower even for static generation of pages because image optimization is quite resource-intensive. Especially, if you want to optimize all images at the same time, like in a build pipeline, for example. We don't want to make your build times, 15, 20, 30 minutes because you have many images, right?
Chantastic: Right.
Tim: That's especially true when you have a CMS bar in your website and like people are uploading images and all that. You never reached the limit of the amount of images on your side if you have dynamic content. Say you have a blog, you keep adding blog posts.
So every blog post you would add in more build time and we're trying to avoid that basically by doing the image organization on demand when user requested and then we cash it automatically.
Chantastic: I think that's super important because so much of this goes back to things that are difficult or painful you know you're not going to do. I really like this as a design constraint of Next is trying to find those places to make it as easy as possible, do it in that way, and keep things fast and ensure that we will do them as a result.
You mentioned something that I wanted to touch on. Because of these full stack solutions there's a differentiation between static content and dynamic content, and images kind of sit at the intersection of that. I know we're kind of careening towards the end of our time today, but I wanted to talk a little bit about how Next is handling that.
How you can kind of take just certain trees and treat them as like a very statically generated part but then keep other parts perfectly dynamic. Could you talk to those APIs for a little bit?
Tim: Yeah, sure. Nexus 9.3 we introduced [inaudible 39:57] props and [inaudible 39:59] props. [inaudible 40:01] props allows you to do service rendering, which Next has always been able to do, so it prerenders content for every single request that comes in. Then the opposite of that is [inaudible 40:13] props which allows you to prerender content at build time and then serve the same generated content to end users.
Then in Nexus 9.5 we actually introduced incremental static generation which means like you deploy your Nexus app and you can generate some content at build time but you can also generate static pages on demand and that's only like a single property that you have to add which is [inaudible 40:42] that allows you to set a timeout for, "OK, I want to regenerate these, this content for this page every so many seconds," basically.
Chantastic: Nice. I love that. Cool. We're getting to the point in the show where I said I'd let you go. I want to ask you before we let you go. What are you most excited about in the next, two, three, four years timeline?
You've been chugging along and doing some really good work in incrementally getting Next to a place that has great developer experience, but then also amazing ergonomics for customers and people experiencing the Web. What are you excited about coming up on the horizon?
Tim: Our focus has always been on end-user experience and developer experience. We focused a little free resources this year on improving end-user experience by producing the amount of JavaScripts and also improving developer experience by giving you things like fast refresh, which was developed inside the Facebook.
You couldn't use in the open-source React space. We set out, and we built the fast refresh report. They're all the bits needed for it to exist in open source, and then implemented it inside of Next.js and ship that, which is showing great results in developer experience space.
Say you're making some edits inside of your code, it's going to keep the state and it's also going to be resilient to errors. Maybe, you make a typo, it's going to preserve the state across typos as well.
If you make a typo, it crashes your app, and then you fix the typo, it's going to be right back where you were. If you were...
Chantastic: Nice.
Tim: ...typing something in a form, for example, you have set in state. The state will still be there. It makes you more productive that way. It also is more reliable because it's hooked into React itself which makes React aware of like, this is a hot update. You're going to refresh the codes of this underlying component.
We work with the Facebook team -- to a Facebook React team -- on this specific bit and that's showing some great results. Looking to the future, we're going to keep improving this. We introduced a new error overlay that has some more accurate errors when something happens.
Say you make a typo in your srcset, that's now a very nice error. Importing the wrong module, maybe you made a typo in the module name, this is going to be shown in a better way now and things like that. We're going to keep improving those.
We're also going to help you achieve the things that you wanted to do anyway but in a faster way. An example of that is the image component. Maybe you wanted to have some nice images, but it was really hard to do that. We introduce features for those specific cases.
Another case of that is, for example, in Next.js 10 we internationalized routing. Internationalized routing is not the full solution yet. It gives you the routing part of internationalization.
That means that you can use any React translation library, and then use internationalization routing to handle the deriving bit of that, in particular for your Next.js application. We're planning out to provide more resources for that.
Improves this developer experience of internationalizing your application even more by providing the tools for translation loading, for example, is a big issue. It requires a lot of custom code and know-how. "Well, it's like, this goes here and then it has to go [inaudible 45:16] is hydration and hold that."
We're going to provide more resources for that in examples and also building features. We're also always listening to the community. If there's many people saying, "I'm running into this every single day when I'm working on the Next.js App," we're likely to fix that.
Besides that, we introduced another interesting project as well, which is a Next.js Analytics, which is a service from Vercel that you can use for any Next.js application. Even if you're not hosting on Vercel, it allows you to track performance over time. What I mean by that is, Google is going to use Web Vitals to rank inside a search.
They basically refer to real user experience. Real user experience is calculated by CrUX, which is C-R-U-X, which you may want to look up. That basically hold the core Web Vitals for general pages, from general Ntusers. That is something you can't reaccess and measure yourself over time.
Next.js Analytics allows you to keep track of these performance metrics in a very easy way. All you have to do is enable it if you're using Vercel or set up a single key inside of your Next config. Then, it's going to keep track of your Ntuser experience over time.
We will give you scores. The score is the real user experience score. It is basically something that you can improve over time and then also stay fast overtime. Maybe, you spend a full week with your team on improving performance. You want to know if your Ntusers are benefitting from that.
Next.js Analytics allows you to track those types of improvements. Another is, maybe, someone does a per request that introduces a massive image on your home page. All your Ntusers are suffering from this because the state of the image takes some time to load so the metrics of that specific page are going down.
Next.js Analytics allows you to see the score going down, and it's also going to introduce alerting on that. It allows you to make sure that your site is going to be fast over time, which fits into the vision of...Next.js is helping you to be more performant and allows you to focus on keep improving your application over time as well.
Chantastic: It's wild to see how much you all have been up to. Something that we have barely even scratched the surface on is the value of Next, being this project that sits in between Facebook and Google, which is a place where a lot of Web developers sit. [laughs] They're sitting in between React as a build tool or a UI development tool.
Google who is ranking their pages, directing people to them, making sure exposing some of the information that makes those pages fast and rank well.
Next is sitting at the middle of that holding the hands of both parties and developing solutions in a way that makes that easy for people who want to make a site, want to make a commerce platform, want to put on a conference, [laughs] whatever you want to do that you might need to build a website for.
You all are taking the things that you learn and the new tools from both parties and building those into Next, and I love seeing that.
Tim: Yeah, definitely. We collaborate very closely with both of those teams like the Google Chrome team. There is a team inside of the Chrome team that is working full time on Next, so they're directly helping provide this large performance improvements like the image component.
The reason that they do that work is that, obviously, you can introduce a lot of new standards and try to push people towards these new standards and all that. People are still building React applications or applications in different frameworks.
Basically, inside of the Chrome team, they decided like, "OK, maybe, we need to continue the standardization process." That's working out. The Chrome team is big. They're basically like, "OK, maybe, we also need to spend some resources on the framework ecosystem."
They can push [inaudible 51:12] large site, for example, builds on top of Next.js to implement all these improvement that are effecting the whole ecosystem. An example of that is, can you improve what webpack gives you out of the box?
An example of that is, in Next.js 9.2, we introduced better code-splitting. We made the webpack chunks algorithm smarter through many hours of testing and figuring out lab data, and all that.
Someone on the Chrome team did that. Eventually, they sound like, "OK, if we changed these setting inside the website convert, it's going to reduce the amount of JavaScript being loaded by 30 to 70 percent depending on your application," which is massive. On a large application with no code changes at all, it's a large improvement.
All the Next.js users had to do was upgrade their application and then would get this improvement in the performance of their application without doing any work. That was like, "OK, that's a nice improvement on Next itself," but how does the rest of the ecosystem improve based on this?
They also worked with other frameworks to introduce this improvement like Angular and others. The new webpack 5 chunks algorithm is more so based on what was built into Next one and a half years ago or so.
Chantastic: Interesting.
Tim: There is a big ecosystem sector into doing these types of improvements of figuring out what is a good improvement. The image component for seeing some big performance improvements for other small apps, but also large apps that have a lot of images.
Even if they have many images, it could be that the developers didn't think about like OK maybe you have to lazy load demo or maybe we don't have to lazy load the top row.
Maybe you want to display all these images fast because they are critical for the experience. I don't know if I go to IKEA. I've been spending a lot of time on the IKEA website, because I'm moving and you...
You basically see these large images in the initial viewport. I'm generally waiting for those images to load because I want to see what's on them. Then I'm going to go into the website. The faster those images load, the faster I'm going to the website. That's one example. There's many different layouts and many different ways that the images are being used.
That's basically something that we're seeing that we can actually make a really big impact. Then also because Next is being used in such large applications, like the largest news website in China, many free large websites in the US, all over Europe, region-seeing government corona dashboards.
A fun one was the Dutch government. I live in the Netherlands. I'm Dutch. The Dutch government is using Next.js to show the corona statistics.
Chantastic: Nice.
Tim: We're seeing everything from small sites, like one pagers, like a corona effort, to massive sites, billions of users every year. It's a large surface of impact, basically these smaller changes that are seemingly small can make.
Chantastic: They have really big secondary effects and a huge impact across our understanding as an industry about how to navigate these important things but with the tool that we have, webpack, React, serverless, etc. If people want to know more about Next 10 or Vercel or your work, where are some good places for people to learn more, get involved, etc.?
Tim: If you want to learn more about Next.js and you haven't used it before, I would recommend going to nextjs.org/learn, which is our interactive learn course where you build out a Next.js application interactively. You can follow along and try it out.
If you do have used Next.js before, you can go to nextjs.org/10, which will send you to the Next.js 10 blog post. If you're more so official watcher, you can also watch the Next.js Conf keynote, which we'll put in the show notes.
Chantastic: Yup, we'll link that.
Tim: That is more like a conference keynote type, like overview of the Next.js 10 release.
Chantastic: Awesome. Now, where do people find you about the Internet?
Tim: Just my full name on pretty much any platform you can think of. That's on Twitter, on GitHub, etc. That's about it. [laughs]
Chantastic: Perfect. We'll link that, too. Awesome. Tim, thanks so much for your time today. I really appreciate it. I know that a lot of people will be really excited to have a little bit more in-depth look at the things that you've been working on and all of the effort across organizations that it took to get us here. Thanks again.
Tim: Thanks for having me.