Building a Better Hammer - The Story of Nuxt 4

It's a pleasure to be here today, and talking about building a better hammer, the story of Nuxt 4. My name is Daniel Rowe. I lead the Nuxt core team at the moment. I'm also involved in some other projects in open source. I have the privilege of being a full-time open source maintainer.

Aside from Nuxt, I'm also involved in building Nitro. PageSpeed.dev is a fun little project for querying the Google PageSpeed insights and Core Web Vitals APIs in a shareable way. RegExp.dev. Magic RegExp is a library that makes regular expression type safe, but is compiled away at build time. Fontane helps reduce cumulative layout shift in web fonts and improve your Core Web Vitals. ElkZone is a client for Mastodon. FirstCommit.is will find someone's first GitHub commit, and you can find all these and more on my website, Rowe.dev.

Well, this is where I'm basically standing at the moment. Only Bali, my cat, has been shut out of the room, but yes, she normally keeps me from writing quite a lot of code whenever I'm at home. She is extremely sweet, but very much needs cuddles when she wants them. I'm talking about Nuxt today and building a better Nuxt and looking forward to the future to Nuxt 4. And if you're not familiar with Nuxt, then I think the key thing about Nuxt, from my point of view, it's a framework for building full-stack web apps, and it's built on Vue and on Nitro as a server component.

The key thing for me is that it's progressive. So the idea is it starts with best practice built in as much as we can, and then it adapts to you as you grow. So as you want to change things, you can. If you need to customize it, you can. So it's a platform that hopefully will improve developer experience, make it feel intuitive, but without limiting you as you need to make changes.

And Nuxt was first created in October 2016 by Sebastian Chopin. And you can see a little timeline of the project. So version 1 and 2 came quite quickly after October 2016. We started working on version 3 in 2020. Vue had moved to version 3, which is a big breaking change. Webpack had moved to version 5, another breaking change. And then halfway through building version 3, Vite came out, which was a completely new builder with an amazing DX. And so version 3 took quite a while. It came out in November 2022. And now we're on the road to version 4, which we expect to come out in June 2024.

Nuxt, we're doing these numbers, just to say, are in some ways vanity metrics. They're not hugely accurate because this is just the stat from NPM or GitHub, but we have 51,500 stars, 29 million downloads, and we're seeing adoption increase. So 62% of Nuxt installs are now on Nuxt 3 versus Nuxt 2. These are live figures, by the way. So every time I see this slide, it's slightly different. And we have a huge number of people who make Nuxt what it is. In honesty, this is a much more important figure than NPM downloads because Nuxt is very much a product of the community and ecosystem. So we're not sponsored by a big corporation. All of the team who build Nuxt are open source maintainers, as are our community. And our direction and what we create and how we build is very much shaped by what we need as a community endeavor. And it is honestly one of the nicest things about Nuxt and about collaborating with people from the open source community. And that is the friendship and camaraderie that we have as part of the community. And there are over 680 contributors.

I want to talk about building a better hammer, the story of Nuxt 4. And when I say building a better hammer, you'll probably think, and I intend that, of the expression, to somebody with a hammer, everything looks like a nail. And that's inevitable, I think.

As you gain a skill or understanding or awareness of a particular tool in your toolbox as an artisan of the web, it can become tempting to try and do everything with it. And that's typically speaking, not a good idea. We are fundamentally people who build things for a purpose. And we have tools for that endeavor. So we can use different tools. We can use different libraries, different frameworks. And that is totally fine. By the way, I'm very much not wanting to say that Nuxt should be the be-all and end-all for everyone. But I do want to make Nuxt more usable and more extensible for it to be a better hammer. So you can use it for more things, that it can be used with nails and screws and other different kinds of things. And it should be usable in lots of different circumstances.

So why? Why do I want that to be the case? Well, one is it can reduce cognitive load. So if you know how something works and that tool is flexible enough to adapt the output to your needs, so you don't have to change the input, that very much changes your experience as a developer. You're not having to pick up a new tool because your existing tool is flexible enough to adapt to what you need this time. You can also unlock the power of convention.

So in a project, for example, an enterprise project where you have new people coming on board, you don't have to onboard them to a particular way of making this particular project. It will work as expected. And this is the power of convention, whether that's in Nuxt or in other projects. Tailwind CSS, for example, has enjoyed the success it has enjoyed because of convention, I think. And it means that for a new developer coming into a Tailwind CSS project, no need for them to understand exactly how the CSS has been set up. Pretty much they know. They know how it works. They know how the styles are constructed and how to add them to the HTML, whether that's a React project or a Vue project or anything in between. But very much what I don't want, very much the reason I'm trying to make Nuxt for a better It's very much not to take over the world. This isn't a zero sum game. And we're not trying to sort of defeat other frameworks. And I think that's one of the things I love about the Vue and Nuxt communities, is that that is not what we're like.

We don't want to do that. What we're trying to do is create something cool and amazing, and make people's lives better in the process. It's not about taking other people down or squeezing them out. I very much hope we don't see ourselves as identified with the tool we use, but I do want to make Nuxt a better tool for all kinds of purposes.

So on the road to Nuxt 4, actually on the road to Nuxt 3, I will say that mistakes were made. Actually, that's not a great way of putting it. Let's say instead we got some things wrong. And I think probably if you just take one look at this little chart of our major releases so far, you can probably see what we got wrong. Most obviously, we took far too long to get to version 3. And in a way, that was no one's fault as such. There were lots of reasons, good reasons why it took us that long, but I think it's still something we got wrong and we recognize as a core team that that's the case. And I would like just briefly to pull out some things that we learned from that.

So one is that scope and time are not both deliverable. You can't both deliver the full vision of what you want and do so in the same time that you forecast for it. Oh, I guess sometimes you can, but if you can't, you have to pin one of those. You can't deliver on both. And it can add a huge amount of stress if you try and do that. That's one of the reasons why we now have a fixed time-based release schedule. Every week, we have a patch, pretty much. Every month, we have a minor release with features. And every year, we aim to have a major release. That's why we're coming up to NUXT 4 now.

We learned about the importance of ecosystem and bringing downstream libraries that depend on NUXT along with us. So the Vue major upgrade took a long time because of all the packages dependent on it, among which was NUXT. And then NUXT itself had lots of packages and modules dependent on it. And they all had to come as well. We very much learned a lesson that depending on the internals of a project like NUXT makes it very difficult to change it because those internals are the first things that change when a breaking change is introduced. And it means that whole swathes of the ecosystem are broken, which is why we introduced NUXT Kit, but more on that in a moment. And we learned that repairing a moving car, so changing the engine while still trying to keep it moving is maybe a bad idea. So all of those are things that we very much are trying to change about NUXT 4.

And I hope these are things that are relevant for anyone on a project aiming to make major changes. These are things we've learned the hard way.

So here are a few things that we're aiming to do. And the first is we rely on the modules ecosystem. And there are a couple of things I want to pull out about the modules ecosystem that help us as we move towards NUXT 4. And the first is that it is deeply hookable. So it can hook into every part of NUXT and Nitro from the build to runtime code. And this is all powered by hookable, which is really an amazing API developed by Puya Parsa. Do check it out. It supports a lot of different things for Go DX, including developer tool integration and integration with console create task, which very much helps browsers display logs correctly.

And NUXT is also pluggable. So the different things that you can use within NUXT are all swappable, if we can make it so. Whether that's the bundler, I'm hoping to see RSPack support landed soon for NUXT, or even the ad hoc modules we build that are still the core NUXT modules. They are actually pluggable and could be swapped out, or the layer architecture that we expose at the end of the day to end users. The aim is that quite a lot about NUXT should be able to be adapted and moved depending on your needs.

And all of that we aim to make it possible to build easily on NUXT. So modules can be created and distributed, either in a local mono repo or in an internal registry or published to NPM. We provide tooling to make that possible to build them. They're queryable from the NUXT modules dataset, which is just a repo on NPM. We have an API for it as well. And we have a composable NUXT SDK. So people can build a module for NUXT 3, and when we release NUXT 4, that module should continue to work as long as it's still using any composable utilities that come from that kit SDK.

That's some stats. So the modules are sort of modules that have been registered with the registry. We have over 205 of them. We have 170 maintainers, over 1,000 contributors, 130,000 stars, and 12 million downloads as of today, I guess. And you can look at the stats yourself that way. Just a quick demo of what that looks like for developer experience. So if I fire up a project, which I've got running here in the background, and I open the dev tools, I can see a lot of things about my project. And I won't go into all of these details, but I can open up the modules panel and say search to install a new one. I can install fonts module, which is relatively new. I just built it probably about a month ago, a couple of months ago, and a number of contributors and I have been sort of pushing it forward quite quickly. So we can install the NUXT fonts module in the background, NUXT will restart itself, the module has been added to my config, and now I can do something. You'll see also I have a little dev tool panel here, which shows that we have no custom web fonts being used. I can enable, say, poppins. And then instantly we get dev tools being updated, we have some information about the fonts that will be used in this project. They're also now proxied locally into the project. And when you build it, it will be part of your project, there'll be no third-party requests. And we also inject some magic CSS so that we get zero or as little as possible layout shift when the page loads. And so that whole experience, we aim to make that as simple and smooth as possible for people using NUXT.

And so any module that can be created, whatever provider it integrates with or feature it aims to solve, we want it to be improving developer experience and reducing that cognitive load and friction as much as possible. We also very much want to prioritize user choice.

So one of the things you notice when you start integrating with NUXT or building on it is that we have lots and lots of swappable integrations. So whether that's our NUXT image component, which supports over 20 different image providers, whether it's the KV and cache integration or database integration, which themselves support lots and lots of different backends.

The aim is that NUXT wants to expose single primitives that work in a consistent manner no matter which provider you use. So we have over 90 providers and the aim is that users can pick those based on their needs but not based on any constraint that NUXT gives them. This is really very much in our DNA. I would never want the choice, the answer for any user asking me which provider to deploy to or which database to use to be dependent on NUXT. It should always be dependent on the user's needs and what they want to do, whether that's pricing or DX from their point of view, but it shouldn't be NUXT that limits them. And so we always want NUXT to be focused on user freedom and independence. And I think that is very much where we're aiming and where we want to be as a project.

So looking forward to NUXT 4, the danger is NUXT is an established framework. We have a long tail of users depending on us. That includes enterprises who don't want their products to be broken and that includes agencies or indie hackers who need to build quickly and they want things just to work.

So one of the ways we make that happen is that we focus on stability. So we have that reliable release schedule I spoke about and we can test before every release against Ecosystem CI, which is taken from the VEET project. Dominic pioneered Ecosystem CI, which is a way of testing downstream dependencies to make sure that the latest release will not break them. And so we do that before every release.

That means we can quite happily launch things that are, we hope, groundbreaking, whether that's server components or build caching, inline root rules, or NUXT module federation. We can aim to build these, test them, and make sure that user projects won't be affected, but that people will be able to opt in to them. We also have the ability to expose a lot of the testing features that we use in NUXT via test utils to our end users. They can actually test them as well. We're collaborating with Ecosystem CI, so we improve the experience for NUXT, but also Vue uses Ecosystem CI and NUXT is included in that. Or VTest uses Ecosystem CI and NUXT test utils is included in that. We're deeply integrated with each other.

And when we're releasing some of these features, we do so in the future and features namespaces, so people can opt in to future improvements and also opt back into previous behavior. I'll soon be releasing a downstream testing action, so people can benefit from the same kind of Ecosystem CI experience, but without needing their repository to be open source. And our aim is that we can expose incremental code migration.

For example, when we spot a breaking change with a possible improvement, we can roll that change out via PR across the entire modules ecosystem. It will be forward and backward compatible, whether users are using NUXT 3 or NUXT 4. We've already done that for three different changes coming in NUXT 4. We would expect the same to be true for other breaking changes that we plan to release. It's easy to opt people in. And we also aim to ship with code mods when we actually do release NUXT 4, to make the migration straightforward and simple. If you maintain a downstream library, please feel free to open a PR to add it and a test against it to the NUXT Ecosystem CI, and we'll guarantee we won't break it, at least without telling you first. And we aim to commit to the baseline standard. The web platform DX is a great project. I do recommend you check out what baseline looks like on MDN, for example. And there are some exciting new things that we plan to build that I won't go into right now. But all of this is built on the platform of our stability guaranteed by Ecosystem CI and other projects. We're also able to look and see how many people use some of the new features we build.

And that does help us make decisions about what we prioritize. That's all purely opt-in, by the way. You'll have to consent to that if you want us to know. But I would highly recommend that you do, because it's really helpful as a team. We value that.

So what about NUXT 4? I think the first thing to say is it is not about the hype. So the aim is that we follow SEMVA, which means that we fix bugs and patches every week. We add new features in miners every month. So NUXT 4 isn't going to be features we've been keeping back. They ship every month.

NUXT 4 is about thoughtful, breaking changes. So the opportunities for us to change the API when we need to in a way which hopefully is opt-in and opt-out. It's changing defaults, but not breaking your project. And so as much as possible, I want NUXT 4 not to be about the hype. I want it to be an opportunity for us to focus on a good migration experience and in a way proving that we can deliver a major release without the pain that many here will have experienced in, say, the version 3 release.

There will be some things that I can spoil. So we have a new directory structure coming, a default directory structure you can opt back in to the previous. There will be more performant defaults on things like shallow reactive payloads, non-reactive runtime configuration, perhaps, using the native browser cache more and implementing some best practices. So absolute parse and build a watch hook or removing the pending Boolean from our data fetching composables. If you're interested, you can find the coming changes with a 4.x label on the NUXT repo.

If you want to help, we would love that. So hopefully we've released a better documentation experience recently. Sebastian and Anthony have been very involved in that. You can come on Discord. There's a contributing channel where you can message me directly. And if you are involved and want to be, there's a nuxters.nuxt.com that will give you a special role on Discord and a little card you can share. And if you are interested or want to get involved in open source, whether that's Nuxt or another project, please do feel free to contact me. I make a calendar available for 10-minute chats. And particularly if you think you're not sure if you'd be welcome or maybe you don't look like some of the other contributors already in the project and feel like you might be coming in from the outside, please, please don't feel that way. And please book a call.

I would love to tell you in person that we would love to have you and that you would be very welcome. And if there's anything I can do to help you in your journey, whether that's in Nuxt or in another project, I would love to do that. So do check out the Nuxt docs. Follow us on Twitter. Join Discord. And you can expect a Nuxt 4 release coming very soon, aiming for June 2024. Thank you very much. It's been a real pleasure to be here today.

First, let's try to discuss the poll results. We can see that 88% are excited about Nuxt before. But 12%, I think I'm on that one, is excited about 3.12. So what is your expectation from this? Well, honestly, I thought there might be more people excited about 3.12. Because honestly, that's where we're going to be shipping the... And to be fair, it was unfair to ask this question before my talk, because hopefully afterwards, you're now thinking that 3.12 is maybe where the features are going to come. And so that is what I'm... I think I'm pretty excited about 3.12. That's what I would want... I want to see more people excited about that. Because... Yeah.

Yeah, but actually, I was thinking the same. It's like Nuxt 4 for the future right now, the new version that will stabilize everything that we have. So that's really cool.

And let's try to discuss some of the questions that we have from the audience. The most polled one is about, how hard is it to learn Nuxt if I have experience with Vue single-page apps? What do you think, Daniel? So mostly, what you'll have to do if you want to migrate an existing Vue single-page app to Nuxt is remove code. So if you have an app.vue file, you can just basically copy it across. If you have page-based routing, you can just copy them into your pages directory. And Nuxt does a lot of things on top. But it's pretty much all opt-in. So if you're not using it, if you just have your existing setup, it should work fine.

If you experience any problems with that, ping me, because I'd be really happy to help. But I think it should be a very, very straightforward migration. And then you can basically use other Nuxt features as you want. So it should be a very straightforward migration. It adds stuff, rather than shouldn't disable any functionality that you're using. Have sense. Yeah.

Let's see if the people that ask this question can try it, and let us know how it went. And we have another question that Kishu asked, actually. Since most contributors in Vue and Nuxt are not sponsored by companies, do you think that they could still achieve full-time open source software by not depending on a company? Of course. I mean, one of the things I would say, you know, if you're working in open source, whatever your avenue is to make that work is good. So I don't want to put any kind of judgment on how that works. We are all making our way in lots of different ways. So if that is being sponsored by a company, that's great as well. It happens that the frameworks are independent, which I think is fantastic. That doesn't mean individual contributors need to be. And is it possible to achieve full-time open source? Yes, I think it is. So it's possible for me, and I think for others as well. But I wouldn't make that the main objective. So I mean, I don't aspire, my objective isn't to work full-time in open source. I'm doing that, I'm delighted that I can do it, but that's not the thing I'm trying to achieve. And I would say for anybody making the sort of the possibility of working full-time in open source, your objective might not be as satisfying as pursuing something that you really enjoy and doing that as much as you can. I think you're more likely to achieve the sort of possibility of being sponsored that way.

Well, let's follow with the next question. So we have one about the talk topic basically, they ask about hook-based systems are known for being opaque, since it's hard to track what's being registered, or how do you plan to prevent improve these problems in the next four years? So one of the things we do at the moment is that we expose hooks in DevTools. I think I had a little screenshot of that. Now, it doesn't give the benefit of where the hooks are registered. But one of the most amazing things we have in JavaScript that's coming into wide usage is async local storage. We already use this in Nuxt with the tracking logs that occur while rendering a page. So you'll have noticed if you have server-side logs that are triggered while rendering a page, we wrap them up and log them on the console.

And we can use the same technology to track where hooks are added or registered, in what module perhaps or in what part of your app. And so if there's a misbehaving hook, we can actually track it back to its source. And that would be something I would love to see, probably in DevTime at least.

Nice. That's really cool. Well, Backstage is telling me that we are out of time. So thank you so much, Daniel, for all your answers. And of course, we have you in Discord answering the other questions, I'm pretty sure. So thank you. I'll be there. Bye. Thank you.