Double Trouble: The Nuxt Surprise (with Daniel Roe)

Welcome to DejaVue.

It's your favorite Vue podcast out there. And as usual, this episode, I'm with my lovely co host, Michael Thiessen. Michael, how are you doing?

I'm doing great. And I have no idea what's gonna happen this episode, So that's going to be lots of fun. Daniel Roe here is our surprise guest. So, yeah, looking forward to seeing what's going to come in the next bit.

Hi, it's nice to be How much of a surprise was it to find me on the podcast? I feel like there would be other guests that were more surprising.

Like who?

I feel if Joe Rogan appeared, there would be more

I would be shocked in many ways. Of all, did you get in contact with him? And

but why?

There would be a lot of you would be asking a lot of questions. Let's be honest.

Okay. There there could have been a more surprising guest, but would there be more surprising guests in the Vue ecosystem? Possibly. Maybe. But topic wise, I think I mean, it depends when people watch or, like, listen to this. It could be that they already like, okay. Yeah. It's all clear. But right now so from you, the listener, in the past, well, some of us have no idea what will happen in the future as we don't have a

Most of us have no idea what will happen in the future. True.

Don't have a crystal ball that tells us.

Yes. We're talking about the release plans for Nuxt four and the release plans for Nuxt five.

Oh. Woah. Nuxt five.

If you want to see someone's mind I don't know, Michael, we should have a reaction video. Michael should be like, This is what I'm thinking at this moment in time. Have you gone mad?

Well, I suspected that there that it might be Nuxt four related because I saw some, you know, some tweets and I was like, what is going on around MadVue? And then I I look to see what's the topic of Daniel's talk here? Oh, beyond Nuxt four. That's confusing because Nuxt four isn't even the present yet. So how can we talk about the the future?

Which questions? Bring them on.

Well, what are the release plans?

That's a good start. Very specific. He's not asked anything about Nuxt five. I hinted at NUXT five, and Michael is just not picking up the bait. It's like, no.

I want to go chronologically.

There's been enough hype. There's been enough hype. I want dates.

Don't give me two major versions. Just give me one release date. Yes.

Exactly. So basically the idea is we have been over a year delayed from the original planned release date of Nuxt four. And that release date was based on a Nitro release date. So we planned to bundle the breaking changes for Nuxt as well as the breaking changes from Nitro into one version and release that. And for lots of good reasons, I should say that Alex and I and others on the Nuxt team are also on the Nitro team.

Every new version, I guess.

Exactly, you have to treat it you're on the edge if you do this. But all of this means that basically there is a set of changes that people have been testing, people have been using for over a year, which represents our original plan for the next part of those breaking changes. And our plan was originally one major a year. So it shouldn't be too massive of a set of changes. So rather than continue to delay, could be out very soon.

Okay. So basically if you've been opting into the compatibility, then in a way you've already been using Nuxt four and we're just making it official.

Nuxt four was the friends we made along the way.

Yeah. Exactly.

So on that sense, I think it's a that's a good chance to remind us two episodes. We once had the year in review episode and also actually the hot takes for 2025 both of Daniel Roe. And he said it will be the year of Nuxt four. Or did I say that? In in any case, we talked a lot about their the Nuxt four and, well, future releases as well.

So I think our aim was always with NUXT four to reassure people that major versions don't have to be scary. And we've spent so much time doing that, like carefully thinking about backwards compatibility flags, helping people opt in that And in fact, someone even said to me, Well, it's such a small change. Why even ship it as a major version? That was a very nice thing to say. True.

Yeah. Also, in terms of, like, I don't know, certain dependencies going EOL, like, Node 18 is now EOL, that would be a breaking change to just say, like, okay. It's gone. And at least depending on who's here. But I think then once a year, especially set with like reasonable changes that ideally you could test out before if you want to because the compatibility version flag that will still continue to exist for future major versions, right?

Exactly. So you can set it to five with release of Nuxt four. You can all be able to set it to compatibility version five and opt into any changes that we make between four and five. I think it's a really good strategy. And I know you've always been a big fan of Alex.

True that.

Actually, who originally proposed compatibility version as an option, but whoever it was, it was a good choice and it could easily have been you.

I also I don't even remember. I only know the fine grained part that I was very keen on making sure that you can disable certain parts if your app can do everything except that one change and you want to work on that but opt into the rest. That's the only thing. And I also still think this is a very good practice for the future just so we have always the option to say, it's just this PR. I know exactly what I might have to take a look at my application and I can deal with that step by step.

From what I've seen online and different people in the community migrating to the the compatibility version of Nuxt four, it seems like it's been a lot smoother and people seem to have really good experiences with it. Like I haven't seen people complaining or upset. Maybe those people who have like the bigger, more difficult apps haven't tried yet to migrate over as much, but I think there's a lot of, especially with like the the different granular flags and stuff like that and the the code mods and other things like that. It it makes it a lot smoother to do that migration.

Well, that is music to my ears. That's nice to hear. In general, I think the pattern has been reassuring. I was giving a workshop in Tampa last week. And as part of it, we migrated Elk to the Nuxt four compatibility version. And we did it in about fifteen minutes, it was a

Fifteen? One - five. That's very important to notice. It's not it's not a small app.

It's a it's a big app. And actually, there's a lot of custom stuff that's been done with it. A lot of custom stuff. So it's not just renaming directories, but it was a pretty straightforward PR and actually fixed some bugs in the in the app.

Even better.

Exactly. Even better. So that was nice to see. I really, really, really, really hope people aren't putting months well, certainly not months. I I hope I hope people don't even bother putting a weekend, you know, except if they have internal processes they have to follow. Like, I I I think that the migration should be pretty straightforward to make.

Also, if anyone's interested in the PR, link to that is in your show notes or description to really see that it could be done in in fifteen minutes. Also by you, not only by Daniel. I remember like when you when you told me that during a conference, like, I have to look it up. I would be so curious. And I checked and I was like, that all seemed very reasonable.

I think so. Exactly. Because part of the thing is if people upgrade to Nuxt four and they experience something like a behavior change, we can clearly identify it as a change that's happened in Nuxt. And then if they upgrade to version five, I think we can again we can clearly start looking at at Nitro. We'll be also needing that that opportunity to test the Nitro changes separately just because it's such a significant refactor of the server layer.

Good points there. In terms of Nitro, I remember that the original goal, maybe still case of Nitro is to be backwards compatible from a framework perspective. That while if you use NitroZen alone, of course, you might have to cater with some breaking changes that you have to change some things, switch things over. But from a framework level that might be able like, the Nuxt and also other frameworks based might be able to mitigate that and say, okay, for our current major version, we could just say we we've pony fill things or set certain things up. Is that still the case?

If that's the case, so it will we'll see how it ends up happening for Nitro three. If that's the case, we would adopt Nitro three sooner with any polyfills or polyfills that we we need if that's available. What Pooya and I are talking about maybe having an API compatibility layer for Nuxt version five and Nitro version three going forwards, meaning that future Nitro major upgrades don't necessarily require a Nuxt major upgrade. That would be quite a nice thing. Nice.

That's why I mentioned it like depending on how you see the perspective. I also know that for Vite, for example, Veed seven is also coming out very, very soon. And there's also the point of like, okay, you can drop node 18 now finally. But I agree that it always depends a bit while semantic versioning is in fact very clear. It can be taken out a very literal or a bit more deliberate depending on also what users expect and what the benefits are.

I think the key thing for me, I mean, the idea of breaking changes, it's about documentation. The question isn't, does your project still work by only updating the Nuxt version or the version of the dependency? It's does it still do what it was documented to do? Because I think there are a lot of situations where So for example, if a package specifies a peer dependency and they bump that peer dependency, so saying we need a newer version. Is that a breaking change?

I think the most important part is to be clear with that. I think with Nuxt, I think in documentation this is pretty clearly written. So that's always good to know for everybody who didn't know it out there yet. Now you're aware. And that means if you're still on Node 18, you better upgrade soon.

I think Node actually released, controversially, released security advisories for all versions of Node. Basically saying there are no specific issues that we are aware of, but you need to know if you're continuing to use an end of life node version, you are putting yourself at risk. And that is, I think there were people who said, well, is an abuse of the security advisory system. But I think one thing it did send was a clear message that you should not be using end of life node versions. It's such an essential thing in terms of fundamental layer, running your code, controlling a lot of things on your computer that you just should not.

For the next version of Nitro, what are the main breaking changes, new things for that? And for the people who maybe don't fully know what Nitro is and how it fits in with Nuxt, can you give like a brief sentence or two about how that works?

So in Nuxt two, we had Connect. We used Connectors as a sort of node middleware type API with request and response objects coming in very powerful framework, similar to express, but a little bit more lightweight. And in Nuxt three, but basically in Nuxt two, when you built your Nuxt server, you still needed Nuxt around to run it. And so even your Nuxt config was still processed in production and Nuxt modules were loaded. And we did some things to optimize that.

I think that's a very good summary in terms of what Nitro is doing. One little addition is, of course, as mentioned before, that you can use those standalone as like another HTTP framework to build your APIs in or whatever you want. And we talked a bit about it in, well, more than 50 episodes ago, episode three of the podcast. So I I think that was that was a really nice summary, Daniel. Thank you so much for that

50 episodes ago. That is incredible!

More than 50.

That's amazing.

Yeah. It's been a while doing this for more than a year by now.

Happy days.

I'd like to also point out that Nitro is used in other Nuxt like meta frameworks for things beyond Vue. And I'm blanking on what the names are.

Analog, TanStack Start, SolidStart, Yeah.

I would love to see more frameworks in that list, honestly, because the fact is that we're all tackling very similar problems in terms of adapters and different providers. And yeah, it feels like a shame to split those kinds of efforts. And I think that is happening actually. So it's a very, I think, very optimistic time to be looking, be building stuff with Nitro or H3 or any of the other underlying libraries. So, I mean, you asked about breaking changes, Michael, and I can't talk about all of them.

On that note, a question regarding the format. Is this also what you mentioned regarding WinterCG or now WinterTC in terms of the common foundation that can speak with all the runtimes?

So it is designed that way exactly. So there's a new if you haven't come across srvx, it's a new and interestingly named universal server API, which uses this new request response format, which you can very easily deploy to any of those runtimes. And it actually uses sub pass exports in its package JSON to ensure that the actual code that you're running is natively optimized for each runtime. So don't have lots of polyfills. This was something we did with Nitro originally.

That doesn't hurt to mention. Even though benchmarks are always flawed. Yeah. But people people love them. People love numbers. People love, oh, performance. And it's also good to mention because you don't want to make things slower necessarily.

Even if you just look at it as benchmarking, not even not they look good across different equivalent servers and runtimes. But I mean, even if you just look at it from a point of view of our own performance, it's really nice to see new major versions coming out that significantly improved performance as over the previous one. That's the right direction to be going in.

I love the take off just comparing to yourself, first of all, because that's the benchmark people measure you as well. And then other frameworks, but still comparing yourself is important.

Yeah. No, it's very helpful. And I think that's also the point of a lot of other things. So for example, a Lighthouse score isn't that helpful in comparing one website against another website. It's very, very helpful though in comparing your own website over iterations as you seek to make it better and prove it.

That checks out.

A lot of methods like that, I guess.

Mhmm.

I think another question that came to to a few people in mind who maybe have read the announcement blog post that is probably out already when did episode airs is maybe it's also answered there. We Don't know yet. Why now? Like, why now? Why now?

So it's not that we're at a sweet spot. If I knew a year ago what I know now, I would have released Nest four then. It's not that we finally gotten to a point where we're ready to do it. It's more that I feel that this will be the best experience for users upgrading. Basically codify what exists.

It also somewhat reduces risk and like the effort to upgrade. Think if it's split over two major changes, because you can do the upgrade to four and then, okay, that works. As you know, a few things that you maybe had to fix maybe. And then a little bit later, then five comes out and then you can do that upgrade and it separates it out and you don't have to necessarily tackle them all at once to fully get onto the next major.

Exactly. And honestly, people could, if they wanted, choose to wait and just go straight to five. But I do think that that intermediate step is just gonna even make the migration more straightforward. Even if you're on three and version five is out, I would still do it first four, then five because it just makes it hopefully quite logically clear which bits of your code you're changing. So you're upgrading three to four, great. Don't touch the server directory. You don't need that.

Except moving it out or like moving everything else, the app folder if you wanna do the server structure.

That's right. Yeah.

Maybe don't touch the server directory if you don't move that and all the rest. It's not wrong.

Yeah.

It's also given the migration guides, it will help a lot. It's like, hey, here's a clear cut from three to four. And then you go through that and then you go through one to five.

The plan is for Nuxt three to get a minimum of six months of support. That was what we've been saying for a while. And the plan will be, even though we're expecting Nuxt four to be very quickly eclipsed by Nuxt five, so we're not expecting for it to be the active release for very long, but we'll do the same. So we'll give that again a minimum of six months of support, even though Nuxt six. oh Nuxt six, Good lord.

Another announcement, Daniel.

Woah.

Just it. We're firing through it. Our new release schedule is one a month, right? Oh, yeah. Not the plan. So even though next five will be the focus, we'll still be back putting features and bug fixes to three and four. So it's going to be it's gonna be some work on us as the team. But I think it will make people's lives easier and better in the upgrade phase. It's worth it.

Sort of, let's say, worst case as a maintainer, that means you port things back to four and three at the same time. Yeah. And how about bridge?

I mean, honestly, I've been doing this for a year, maintaining both the main branch four.x and three.x. Like we've been cherry everything is cherry picked back to three.x. That's not the active branch.

True.

Yeah, doing it one more, think it should be doable. Bridge, Alex, Bridge. Well, so I think the scenario for Bridge is that it's a tool to help people migrate from Nuxt two to Nuxt three.

And that would mean next to to next bridge, to next three and then four five.

So, I mean, if you're migrating from bridge, I'd probably go straight to version four, honestly, or straight to to five.

Or whatever we have when you listen to the episode in a couple years.

But, like, the differences between the whole point, I think, the difference between two to three is a huge difference. The difference between three and four and five are not that significant. So there should be very little different that you need to do. So yeah, you can migrate to version three and change it to version four. But I would just go for version four. It shouldn't make that much difference to the migration process other than a different directory structure.

Makes sense.

You're not asking about the dates though. Or maybe you did, Michael. Maybe you're just thinking, don't know.

I did ask about the dates. But before we get to that, I have a question about if you ever consider just skipping four altogether and just sticking with prime numbers as the version release, the major numbers?

I have now. And I think it would start off very promising. And if Nuxt intends to keep going as a framework for some time, it will rapidly become more difficult.

That's true. But actually, the the idea of skipping for people in the community have voiced that multiple times. Oh, yeah. You can align with the number of the year, 2025, get max five, and this might still happen now.

You know?

So maybe that was just Daniel's approach to get back on track in terms of aligning that. But yeah. I mean, would be the benefit in skipping four straight away like PHP did with, well, we all know which version?

My favorite version hack that we did was 3.14.159. That was that was that was basically, you just added additional digits of pi to the That was really good. Version number rather than increment in a normal fashion. That was great. I loved it.

Same. That will always stay in our heart and probably end up as a view trivia question in some quiz.

Exactly. Yes. Probably.

I will tell you, though, one thing I would like to do, maybe I should do it for version four, is have code names for our minor releases.

Like Vue has as well.

Yeah. Like Vue has because I feel like this is a missed opportunity. So you you get thinking.

But what would you name them off? Like, what would put your name after, not off?

Well, I'm not an anime watcher, so I I don't really play video games. So if if you're looking to me, like, I I I'd I'd be having to do stuff like, I don't know,

Bouldering Gyms

Books of Anthony Trollope, maybe? That would be Barchester Towers. We could do something like You're not amused. Well, we could have a discussion about this.

No, no, Daniel. We do a poll. There is no discussion. We do a poll. We let the

The community can decide, and Boaty McBoatface will be the next minor.

Yes. Like, most liked comment on all platforms. We end up with we end up with horrible names, but it's fun.

I think it should be something like obscure so people don't don't immediately get the reference. And then they have to like look it up or something. I think that would be

How about favorite karaoke songs, Daniel? What do you think about that?

Favorite karaoke song. So the first one would be Row Row Row Your Boat because that is going to be the next song that you and I sing at karaoke. Right?

Definitely. So then we have the codename.

And then you can have when you install it, it plays that minor version's theme song.

Oh my god. That's A little animation in the in the terminal, like, a little boat that's oh my god.

This would be so bad. This would be so but also genius at the same time. True. We would have to play it in a very, like, video arcade way.

Yes. Like a low fi, like an eight bit version or something. Yes. Yes. Yes. Yes.

Like, it doesn't matter. We even if we have the capability of playing it high fi, it has to be as low fi as possible.

100%. If you could do it on the landing page or the blog post or something, that you'll link to the platform.

I think it'd be fun. You could actually while the dev server the dev server would be ready, but before you're allowed to develop your site, you have to do a little platform game. You're like, jump. Then Like the Chrome

Dino. Yeah.

Exactly. Have to go. That would be fun.

These are all fantastic ideas.

Yeah. We should win them all.

Coming and jumping over mountains and collecting green triangles. Oh,

You should do this, Alex.

What did we get us into here? What did we get us into here?

I think we were talking about the the fact that we should have released names. But really the question is what are the release dates? I should be asking that question.

Wanted to ask at the very end. So everybody is still intentioned the whole episode over And they don't just skip to the chapter mark that it says, when release date? Mark. Ah, I see. Yeah. Daniel, drop us drop us the dates. Tell us now. It's time.

So alpha of Nuxt four is already released as of Monday. Oh.

Isn't it already released as in future a compatibility version four?

It's not released as of the moment I say this. It's released as of the moment you hear this because it will be out on Monday with the blog post, alpha of Nuxt four. That's my plan anyway. And then the aim is to have Nuxt four stable release out by the June. So quite an aggressive release plan.

Wow.

That's tough. Okay. I'll block the June

How does that sound, Alex? Because I'm aware that this is the first time we have actually talked about it.

Yes. Well, I mean

You onboard? Should we delay?

Let's do it. Let's do it.

Let's do it. That's fine.

I've blocked the rest of the month. It's fine. I only have one conference that we attend together. And then we're good? Perfect. Crunch time.

Yeah?

I'd like to bring your attention to this

problem.

To wait. I'm trying to send a link here too to a post that I sent a while ago where I did a ChatGPT generated comic. Oh, yes. The the date in that is

very interesting. Eerily close.

I did not put in my prompt anything about the release date or any details about that, just the actual like panels. And then it just decided to fill that in. And for those listening, it's a, it's a comic that I made with me and Daniel Roe where I say, I know when the, the next four launch date is, and then it shows my phone that that Daniel Roe sent me a text saying June 13.

It is Daniel

Not too far off.

Should we just make it June 13 then for the memes?

I've just noticed that in the group chat, it says, Darie Dari. Dariel? It's Dari. But, like, exclamation mark. An hour.

Darin. god.

Also, if you look at my ear in the first panel, I've got, like, an extra earlobe.

Or an earring?

It's an earlobe slash earring. Yeah. It's disturbingly similar to both.

But nevertheless, we have still the chance. The podcast is not out yet. We can cut no kidding. But the podcast is not out. But should we make it in June 13, or do you think we need a month of aggressive aggressive timing?

We'll see. I'm not averse to releasing it a little bit earlier than the June. We also have another person on Bluesky who said that if we released it on the June 23, he would quit his current job and go back, which he's building Next.js and he will go back to building Nuxt. So that is also a reason why we might bring the release date up soon. But if anyone gives me a better offer, you know, any bids, any, you know who knows? We could we could discuss dates. But

then bribes.

June 23rd sounds more even more appealing. Yeah. The the bids are opened. Write in a comment what you would offer to Daniel Rowe and the next team to release to release it earlier or at all.

Or six, which we discussed today, but I wasn't planning on talking about nothing more, think. Only that this is only really possible because so many people have been testing it. I really appreciate that. So thank you.

Perfect. Yeah. Thanks to everybody using the compatibility version. Reporting bugs with minimal reproduction, always appreciate it. Raising issues, contributing as well in all different ways. Yeah. And then, last but not least, where can people where can people follow you? Hope you'll find you.

I have a website at roe.dev where I can have links to most other things. But I'm pretty much on every social media platform except for Twitter. So give me a DM if want. If there's anything I can do to help, I'm always happy to be contacted.

Perfect. Then check out the announcement blog post, which is out when you listen to this episode and also linked as well as all the other links we've provided. Continue listening if it's not the most recent DejaVue episode and otherwise well, we also shared a few about Nitro, the Road to Nuxt four. Hot and spicy predictions for 2025, and some of them became true already. So check them out definitely. And thanks everybody for listening and watching, folks. See you in the next one.