Rethinking Bundling: Why You Don’t Need Less JavaScript

Thank you very much. It is a pleasure to be here. Thank you for coming away from, let's be honest, the most incredible screen in the world. Have you ever been in such an amazing screen? No, I mean, it wrapped me. I was surrounded by that screen and captivated.

I'm going to be talking about rethinking bundling, and I apologize for the subtitle, because that's exactly what I'm saying. So I have lured you here under false pretenses, and it's not too late if you do want to go back to the planetarium. Because I'm not going to just say about why you don't need less JavaScript. Of course, well, that will come. But first, who am I?

My name is Daniel. I am a full-time open source maintainer, which I've got to say is the most incredible job in the world. I maintain Nuxt. I lead the team building that, which is a full-stack framework for building web apps. I'm also on the team building Nitro, which is a framework for building servers. I'll be talking a little bit about that tomorrow if you are at React Summit. I've also built a few websites and open source libraries that you might want to check out too, including magicregex, Fontaine. You can check your website on pagespeed.dev and so on.

Elk is a client for Masterdone. I'm a Google Developer Expert, Microsoft MVP, a GitHub star. And I recently became a software engineer at Vercel who employed me to continue my work on open source. I live in Edinburgh with my two cats and my family. This is basically a very beautiful view of the city. It is actually very beautiful. It is also very cold and very rainy, particularly as you go on into the winter. And as at least one of you has discovered, if you scan that QR code or go to a row.dev slash live, you can send any emoji on screen. I've given you some emojis to easily send, but you can also send any emoji if you want. So use that power with responsibility. No code of conduct violations, please. Cool. I think.

Yes. Good. You've figured out how that works. Isn't it incredible, by the way, what we can build? This was not complicated. This is not me saying I could do amazing things. This is saying we can do amazing things. So here we are connecting to... This is built on PartyKit and on my website, which is all open source.

When you send an emoji, it goes to a WebSocket server hosted on CloudFlare, which is connected to my slides, which gets to display it on screen. That was absurdly simple to create. And we can just make anything we want. It's cool. When I was developing that feature, by the way, I got rickrolled because I made the mistake of posting on blue sky.

I should say I'm on every social network except Twitter for obvious reasons. Do feel free to connect. You can find my handles on my website, which is row.dev. Feel free to drop me a direct message any time or send me a question if I can help in any way. I'm an open-source maintainer because I love that. So don't feel bad about it. I would love to hear from you.

Nuxt, which is the framework that I mostly spend my time working on, is a full-stack framework. It's progressive. So the idea is that you should be able to start with almost no configuration or previous knowledge required. You should be able to build. And then as your circumstances and needs change, you should then be able to configure it as you wish. It was created the day after Nuxt.js. If you're here because you think that I maintain Nuxt.js, I am also very sorry to say I do not. And you are also welcome to return to the screen of greatness. But it was created the day after it.

The same thing as Nuxt.js originally, but for Vue. And since then, the two frameworks have evolved separately and have quite different feature sets now. We entirely rewrote it for version 3, which was maybe a bad idea. But it ended up turning out quite well. And we have a completely rewritten framework. And we even rebuilt the server backend, which is where Nitro came from. And a lot of other libraries we built. At the time we abstracted into a GitHub org called unjs, which now hosts libraries used in everywhere from Tailwind CSS to Astro, to Angular, to... I could go on.

Nuxt has some GitHub stars. I think that last spike is an artifact of the npm numbers. But actually, I'm much less excited by those metrics than by this one. It's a community-based framework. So, it's been built by over 960 contributors. And it is driven by the community, not by any company or corporate agenda. It's not VC backed, for example. Nuxt is built to solve the needs and problems that developers face. And I originally got involved as a contributor for exactly the same reason. I was using Nuxt, and I wanted to fix bugs and add features. And I pitched in just like every one of those 960 people. And I have come here today with an opinion which I feel is maybe a little bit dangerous to say.

I actually think that JavaScript is good. Or... Yes? Yes? Do people agree with that? Okay. There's some people sitting in the back thinking, hmm... And for you, I can say at least maybe we can compromise on the idea that JavaScript is useful. I don't know if you had the same kind of experience as I did. Discovering a website that was truly client-side interactive for the first time. Instead of that long round trip to the server, images slowly progressively loading, text jerkily coming in, CSS loading in a flash at the end. Actually, you interacted with something that felt much more like a native app. And JavaScript, when it does enhance and improve user experience, can be absolutely incredible. And I want to talk particularly about what we can do and share some things that we are doing in Nuxt, which are not unique to Nuxt. And I hope this doesn't come across as a talk all about the one project I'm maintaining. But what we can do as people who use frameworks and build frameworks that make the web more performant for everybody. Here are some of the strategies we're doing.

I think the first thing that you have to do, that you have to start with, is to expand the possibility, expand the scope of what you mean when you look at bundling. So, normally, what we talk about when we talk about bundling is this one line in an HTML document in a website. What are we talking about? The JavaScript bundle. And we think performance is all about improving JavaScript. And actually, if we can get away from frameworks and libraries, so much the better. I could not disagree more. First, we need to expand our view of what a framework or a bundler can do. And of course, it's not just that one line. It's all of the HTML. So, here are some examples. So, style and lining. So, when you build a website, if it's a pretty straightforward, simple, truly incredible site, you will probably have a CSS file and you'll have your text. That CSS file is fine. It is a separate network request, but there are ways you can make that optimized by, say, sending an early hint or something to tell the browser to start downloading it. But as you start building your website, and as you have components that are lazily loaded or are separate chunks, you might find that you actually have more and more separate CSS files. And this is one of the things that is problematic or non-performant with websites that may grow, may become enormous monoliths with thousands of components and potentially hundreds or, let's say, hundreds of CSS files loaded.

So, we found that we could do this in Nuxt. We could inline them. So, we take a component like this, which this is a Vue component. If you haven't come across it, think of it as a bit of HTML, a bit of CSS, a bit of JavaScript. In this case, it's just HTML and CSS. So, we take that CSS. We take that component, we track it. So, this is what it compiles into with a Vue compiler. We're able, every time that component is loaded or renders something on the server, we track what component was loaded or what component managed to render something. Then we're able to take that key and track it with the styles that it had. So, this is something that we do. This is our actual code that we run. And we take all of the styles of that component and then every component that rendered on the server, and we smush them into one single inlined style block that we can actually render on the initial load. We remove everything from the client-side CSS that we're guaranteed will be in the server rendered HTML. And, hey presto, what we should have is more performant websites. There's a cost, of course. Every time you do that, you reduce the cacheability of your CSS, so it's not simply one file. But on the other hand, you have very performant, low layout shift on the initial load. You reduce the number of files that you download. And we think, in general, that is a good default, particularly for Vue components, which are often chunked. So they produce separate files. And we are very well able to track them. In fact, on the flight coming over, I was just implementing this feature. We shipped with it for Vite in Nuxt 3 and 4, but I was just implementing it for Webpack and RSPack. So we should expand that in Nuxt pretty soon.

Here's the second thing that we're doing. I don't know what your favorite core web vital is. I assume we all have favorite core web vitals, right? The poster in the office of your favorite core web vital? No? It's just me? So one of the new core web vitals that came in just in the last couple of years is interactionToNextPaint, I-N-P, which basically measures the response time when you perform any kind of interaction on a website. How quickly does it respond to what you've done? And one of the big warnings that came out, this was actually tweeted by someone on the Chrome team, who spotted that actually of quite a lot of frameworks, when this new core of vitals came out, they would see huge decreases in their website performance results for websites that were using those frameworks. And we found out that this was true for Nuxt.

In fact, we found out that this was true in a very particular case where we were optimizing for performance. So we have this thing called a full static website, or we have the ability to extract payloads where every time you render a page which has been pre-rendered, we extract all the data that that page needs. So network requests, async or complex tasks, stuff think about syntax highlighting. You might want to syntax highlight some stuff of your website based on a request to a CMS. But you don't want to do that every time someone visits the website and you definitely don't want to do it on the client side when they visit a website, right? That would be terrible. So we extract it all in advance and we basically make it so it can be instant.

So if somebody navigates from one page to another page, we have this payload.json which exists. We use a cool tool called dValue which was originally created by Rich Harris and it takes json data and turns it into a richly reactive object which can use stuff like view shallow reactive or could actually even embed island components within the payload. And so we do that, and what we found was when people enabled this fast mode, people were navigating from page to page and they had high interaction to NextPaint. Can anyone guess why? No? Well, maybe. I didn't entirely hear it. Waiting to download? No, this is the thing.

We downloaded everything in advance. But it was worse than if you clicked and then it went away and had to download stuff. And the reason was because it was all there, the JavaScript thread was blocked because it immediately started re-rendering. Whereas if you at least had to go away and make a network request, you got a chance to give feedback to the user before the request finished. So we actually added at the framework level the ability to automatically inject a request animation frame to allow the browser to respond to the user by, I don't know, focusing or unfocusing the button they clicked or whatever it was that needed to happen in the browser.

And at the cost of some eight milliseconds, so non noticeable probably to the end user in the sense of the end result of loading the page happened just as fast, but the point was they got an interaction sooner, better user experience. And that was something we were able to roll up at the framework level to improve performance for users. And this is also faced by other other frameworks. Malte Ubi, Vercel's CTO, wrote a very, very interesting article on exactly the same challenge they faced in Next.js.

Here's another core web vital. Cumulative layout shift. If you ever been to a website that does this, you visit it, and then it flickers around and the font loads. It's terrible. It's absolutely awful. And I hate it most. This is my least favorite core vital, personally. Or my favorite, I guess. Because the point is that I try and collect something and I click a different thing, right? It totally messes with me.

And this would be a much better experience, right? To be able to load that web font but not have a layout shift. And this is actually something that we were able to build in Next. We spotted that there were all of these problems and issues when people use custom web fonts, which are all solvable but require additional effort from users. And so, we were able to do this. We were able to take that same kind of view component, spot font families, extract them, download the font.

So no third-party connections, no privacy issues. Actually download it into their project. Download the CSS so it's not an additional resource to be loaded. Check the metrics of the font. So see exactly how big it is compared to the fallback that the user is using. Inject using font face overrides a, like a, it's basically a bed of procrustease that moves the fallback font to be as close as possible to the shape of the custom web font so you don't get layout shift. And we were able to ship that as a Next module and zero config custom web fonts. You just use it.

I have a quick question. Are you using Next? And I just want briefly to point out how clever I am. Not really. Because I've given you two options and they are yes and not yet. And I will say, by the way, I'm really honored that so many people who are not using Next have come to hear me talk. So thank you. Well, this is a gift for you if you are not using Next and also do not plan to use it. Because we have extracted everything about Next fonts into an agnostic library with zero runtime overhead that does all of those things and is usable in any Vite-based So, enjoy. I appreciate the miming of the clap. That was a very because there's nothing worse than being the one person clapping, right? It's like you have to wait for a critical mass. And so, anyway, it's a difficult thing. You clap whilst also looking around. That's what I do.

Here's another thing that we're able to do. We just shipped this in the last minor of Next. It's still an experimental feature. But imagine you have a static website that does stuff like something that's costly, syntax highlighting. And it does that in this async data state. We're actually able at the compiler level to identify that, extract it into a virtual file, and only load that when needed. We were actually able to reduce the total JavaScript used on Next.com by almost 40% and reduced unused JavaScript by 66%, doing something, an optimization that no user would be able to easily do in their own project. We recently shipped, in the last year, something called Next Scripts, which is an integration around third party scripts, which are the biggest problem in terms of web performance.

We recently shipped, in the last year, something called Next Scripts, which is an integration around third party scripts, which are the biggest problem in terms of web performance. Sometimes people look at the performance of frameworks like Nuxt or Next in terms of core web vitals, and it looks like they perform very poorly. In fact, this is often because of the correlation between people using these frameworks for things like marketing sites and then throwing huge quantities of third party scripts onto the website. So it's not really something the framework is to blame for, but it is something we can help fix. So we shipped Nuxt Scripts, which provides better facade components for lots of embeds that people use, as well as replacement for things like Google Tag Manager, built-in cookie consent, SSR support, and lots more. And we also are able to actually bundle third party scripts in some cases so you don't even have a third party origin and we can actually optimize the script using the compiler options of the end users project.

I promise I'm going as fast as I can, I'm so sorry if I'm taking a little bit long. Another challenge that we are shipping experimentally is to be able to take lots of async chunks embedded in an initial request and actually rebundle them into a single chunk of JavaScript using some magic with import maps. This, by the way, is extremely cool, you'll have to take my word on it. It even works with caching because we're able in the input map to rewrite all subsequent requests to those initial files into re-exports from the rebundled file that we created. It's very cool, I love it so much. Sorry.

We built another tool I want to shout out, E18E, which is an ecosystem cleanup initiative. It is phenomenal cleaning up the dependencies that are installed in our projects day by day and we actually are able to remove polyfills that are no longer needed in JavaScript at build time. So you can check out unplugged and purged polyfills. And why use JavaScript if you don't need it? So you can build a multi-page app with no JavaScript with Nuxt with one line of code and that is not just on the entire app basis but you can do it on a per route basis if you want to. And we're looking at where we go next. So we are just about to ship, we have just shipped, just open-sourced the first version of Nuxt hence and we have a new version of Nuxt Accessibility which I'm just very briefly going to show you because I can't resist it.

We have a new DevTools panel. Oh no, what have I done? I think I've killed the dev server. Okay, I'm not going to demo that for you. If you're interested we can do it later. But we're looking at what we can do at the framework level using experimentation. So we have an opportunity, a huge opportunity as a framework to learn from experts, figure out best practices, ship those to users who may or may not already be experts in those things, and iterate, experiment and iterate, which hopefully makes the web better for everybody.

And on the subject of experimentation I have just a very quick study that I've been conducting throughout this talk. I want to know emoji usage... There we go. I'll analyze that later and adapt the talk. If you're interested in any of the things that we have been talking about in Nuxt or some of the other techniques, feel free to get in touch. I would love to hear from you. You can find out more about Nuxt on our website. We have a discord if you want to ask questions. That QR code will take you to a BlueSky starter pack of people in the Nuxt ecosystem team, which is about 25-30 people who are building core Nuxt modules or contributing to the framework itself.

And I should also say I have an open diary. If you go to rho.dev chat you can book a call with me anytime. I would love to talk. If you want to get involved in open source, whether that's Nuxt or not, I'm more than happy to answer any questions. And particularly I will say if you feel any hesitation, if you feel like maybe your background isn't exactly the same as people involved in an open source project you'd like to be involved in, I can tell you from my point of view you'd be extremely welcome. And I can maybe smooth open some doors or bridges if that's something that would be helpful.

Please feel free to book a call. It's been a real pleasure to talk to you. Thank you so much for coming to hear me.

This first one is from me. What was your first PR to the Nuxt repo? You talked about like that's how you got into open source. So I think it'd be cool to hear how did it happen. I don't know, but I can tell you that my first involvement wasn't really in creating PRs. So I would go with a question. So I was facing a bug or I didn't know how to do something. And so I went on Discord and asked and people answered. And then I found that because I was now in the Discord, I would see someone else asking the same question and I now had an answer. So I answered them. And that was amazing. Like the hit of being able to help somebody else. And it was just great. And so I did that more and more. And then I started contributing to a module. It wasn't in the Nuxt core. It was called the Now Builder. The old days when Vercel was called Zite and it had a platform called Now. I was running a SaaS and our main thing was using that. So we deployed Docker images to this. And so I started building this Now Builder and then I eventually started maintaining it. So probably my first PR was to want to maybe to Now Builder. Nice. Cool to hear it.

This next question comes from Code Witch. Does building a meta framework feel more like front-end or back-end engineering? I think it feels more like back-end. We ship very little CSS.

We ship very little CSS. No production CSS. And we're not really opinionated as to how you build your interfaces. So a lot of it, building a meta framework is an exercise in discovering how little you know. Because you're facing loads of things. You have to discover how Webpack works and how Rollup works. And then you have to understand how Node works and Bun works. There's constant entire separate fields where people are experts, where you are obviously not an expert. And you're having to to encounter those, learn, be corrected, and iterate. And nothing will more equip your imposter syndrome than maintaining a meta framework. I'll tell you that for sure. Definitely.

Cool. Right. Next question comes from Igor. Is it safe to bundle third-party scripts? I mean, they change often and it's the reason why they're not in the bundle. So it depends, absolutely, on the third-party script. Some of them will absolutely not work, even. They expect to be served from a certain origin. Some third-party scripts do, they work absolutely fine. And it's one way of getting around the issue of cache headers for those third-party scripts. But yes, you have to take it on a case-by-case basis. Yeah, that makes a lot of sense.

This next one, I think, is probably applicable to a lot of people to try to figure out how they can apply what you talked about in your talk to what they're working on. So how can I enhance the legacy React apps created seven years ago like those built with Nuxt? So how can they get some of the features that you were talking about in a more legacy app? So I think one of the first things you can probably do is switch to Preact, which would be... In compact mode, it's often a drop-in replacement, particularly if you're looking at a legacy React app and you just immediately want it to be smaller and more performant. You can also write your own bundler code. So probably, you're looking at Babel. You're probably using a webpack Babel setup with a legacy React app seven years ago. And I would start by identifying code that doesn't need to be there. So look at your tree analysis, find code that shouldn't be there. It's probably not used. And you can actually write a quick plugin. By the way, LLMs are great for this kind of thing. So you have no experience, say, writing a Babel plugin or a PostCSS plugin or whatever. It's very constrained and it's very testable. So you can prompt an LLM to help you do something like that. Write some code to tree shake stuff out that you don't need, for example. It's so difficult to know without seeing a specific example. But I have done that plenty of times in legacy apps.

What was your motivation for rewriting Nuxt for V3? And why was it maybe a bad idea? It was, in general, rewriting something from scratch is a bad idea. Just by default. You have to have a really, really good reason to do it. Because we all want to. We all love the perfectly pristine, fresh project. There's nothing more amazing than starting from scratch. It feels great.

Just by default. You have to have a really, really good reason to do it. Because we all want to. We all love the perfectly pristine, fresh project. There's nothing more amazing than starting from scratch. It feels great. But there are lots of problems, because you miss all the edge cases, all the bug fixes that have existed for years. You lose context on a lot of things. So in general, you really have to have a very strong reason to do it.

We did it because there were so many breaking changes. There was a switch from Webpack to Vite. There was a switch from Vue 2 to Vue 3. There was a need to build websites that were optimized for serverless and not for long-running servers. We switched from 300 milliseconds cold start on a minimum zero-dependency Nuxt app with Nuxt 2 to less than one millisecond in Nuxt 3 because we rewrote it from scratch. And so there were lots of good reasons. I think the thing that we did worst in the whole process was we were too slow. We prioritized completeness of our roadmap over iteration and timeline. And we also didn't communicate well enough with the community while we were doing it. And we're working really hard now with our major versions.

We just released version 4. And we'll have version 5 coming up, I think, probably in the new year. And we're really working hard to make the migration as smooth as the migration from 2 to 3 wasn't. Nice. This question comes from netscape. Is your emoji slides integration open source? Can they find the code for that? It is. So my slides repo isn't open source, although my slides will all go up on my website. But the code on my website live.vue, which corresponds to that live page, has everything that you need. I think if you just copy and paste that into Slide Dev, you will be able to have exactly the same thing. Cool. We're pretty much out of time. But last question here. How are your talks always so good? You can definitely come again. That's nice of you to say. Cool. All right. Thank you so much, Daniel. Thanks.