New Releases: Nuxt 3.16 and Nuxt UI 3

Welcome to DejaVue.

Your favorite Vue podcast. You just don't know it yet. Although, you know, a year in, you've had how many episodes now? 52. This is the fifty third, I think.

Exactly.

A lot of chances to to check it out. But if you're new here, as many of you probably are, then welcome. The first episode you're listening to, hope it's a good one.

Exactly. And, I mean, we're talking about Nuxt three dot sixteen, so that must be good if using Nuxt.js out there. And, of course, that's not the only topic. We also sneaked in Nuxt UI v3, so the big major update there.

Yeah. Let's let's dive into it. We've got a bunch of fun things to talk about. So Nuxt three dot 16 came out just like top level, but we'll dive into the features one by one, but named layers, which is great. We've got some delayed or lazy hydration, which was added in Vue, and then now it's made its way to Nuxt. Some extra things with debugging and new version of Nitro in there with better errors and some other stuff in there as well. So, yeah, that's a pretty good release.

Yeah. It's like every minor version, it's pretty much filled with good stuff. And there's even a tiny thing people might not necessarily notice until they spin up the new project. We can even start with that, which is, well, a new way to initialize your Nuxt project. We can just run a create Nuxt, like npm create Nuxt and then get started.

Yeah. I tried it. We actually use it in Mastering Nuxt. It came out just in time for me to rerecord the like, that very first lesson where we

Perfect.

set up the Project. So nice little streamlined way of doing that. Yeah. And I mean, I think it's great that it's like a it's not and, like, if you're already using Nuxt, you're probably not gonna see this as much because it's only for new projects. Right? But, yeah, an easier way to get started. It's always better.

Same for reproductions and stuff. And there is also one thing that a lot of people really wished for, which was also heavily discussed in the team, the wizard, right, in create-nuxt-app that people had like, oh, do you want ESLint? Do you want Tailwind? Do you want one of 10 other UI libraries? And finding the balance there is tricky.

Yeah. It doesn't really reduce the friction if you have to spend, like, an hour weighing the the pros and cons of everything. And

Exactly.

Sometimes you just wanna get started.

And, ideally, so from that idea as well that there might be modules and that might be also your own in the future. Right? As you say, okay. No problem. I installed the module and the module can do something during the installation.

Yeah. That makes that's a nice feature to have the template to just dive right in there. Because at this point, I mean, NUX four is not out yet, but it is Getting there. At that point where it's like, if you're gonna do a project, you probably should just start with that in in that compatibility mode so that you can just when it does come out, you can just, you know, flip it right over without having to do a whole ton of refactoring.

Exactly. So I think it's helpful, and especially if you're not worried with, like, trying some more experimental things. If you say, okay. Look. Everything that's merged, it will come. I I just straight away wanna get it. Yeah. It's a great way to try it out. Of course, you can also set it manually. You don't have to necessarily set it up with a template. You can do it afterwards. But, yeah, that's a just a more streamlined way to get started.

Yeah. I'm looking forward to the ability to have more templates and stuff like that as well because I think if you have templates and you don't necessarily need to have, like, starter repos and things like that, as much you can just use NPM create Nuxt, pass in the template, and, like, however you wanna wanna use it, you can have a whole bunch of stuff already, like, preconfigured there and ready to go. That'd be really neat.

Yeah. I agree. Like, the template part, it's always I feel like it's a double edged sword because on one hand, it's great to have, like, things straight away set up already. You can, like, define your custom ones. On the other hand, of course, maintenance.

Yeah. One of the most interesting new features that dropped is the lazy hydration support for Nuxt, which lets us control when a component hydrates. So if you're not as familiar with how Nuxt works with the universal rendering system, basically it combines server side rendering with single page app where the first time you hit that server, it will send you back that fully server rendered page, but then it also sends back that app bundle so that from there on out when you click around on the page and stuff like that, it acts like a single page app. So you get the performance benefits of both. But in order to do that, after that first page load, the app has to basically transition from server side rendering to single page app mode.

Technically infinite. Right? Because you even have, like, an option with, like, called hydrate when. So you can just define your own ref, whenever the ref turns true, it's fine.

Okay.

So, yeah, I agree. It's it's pretty amazing. We have, like, lazy hydration. And to add out there, I think, was a really good explanation in terms of hydration works. Why you don't want to hydrate your full page, of course, it's cost intensive.

Yeah. So what are the best practices around this? So you don't need to lazy hydrate everything on your page, of course, because then you have to make everything async, right? Because it only works with async components.

Yeah. Correct.

So there's some different ones here, hydrate on visible, hydrate on idle, hydrate on interaction. So those make sense, okay, you only want to hydrate an element once it actually scrolls into the view, or once the browser is idle, or there's a hydrate on media query, so we can, if you've got a mobile nav and a desktop nav, we can only hydrate the one that actually is being used. So do you have any other thoughts around best practices? I guess this is a newer feature, so maybe we haven't figured out best practices for this one just yet. But do you have any thoughts on that?

Always have opinions. Always have thoughts. That's a pro and a con itself. So there's there's one strategy that is, I think, pretty important. It's called hydrate never.

Yeah. That makes sense. We can basically take some of the the stuff we already know about lazy loading and just apply it here.

Exactly.

So this hydrate never, it sounds like, like I'm wondering if it works similarly to, so we have a v-once directive in Vue, which lets us do the whole like interpolation, but then after that it treats us static content. So the hydrate never is basically like a similar way of doing that, but we do the interpolation on the server and then on the front end, we just never hydrate it. It's just fully static.

Yeah. More or less, exactly. Because for the whole hydration, it applies to the whole components, not only the template but also the script part, of course. Basically you do everything on the server first and then, as you said before, it has to be taken over by the client. And there you have what I would call a replay effect because you go through all the components that are in the server and you have to run the same code on the client again.

Okay.

I think Yeah.

That's a good one to to to know. Yeah.

Yeah. Oh, absolutely. And it's, I think, key if you have, like, a static footer or something with only external links, then that's a perfect scenario. Or, like, a lot of text. Let's say you render some markdown and you have no internal links in there.

Right.

That's also a big pro.

Yeah. That's good to have that in there.

And I think the last thing, at least that came to my mind regarding lazy hydration, there are still some limitations in terms of usage. So the main part is because how it works internally, and I've also showcased that in in a video already, I'll link also that in the show notes, means that you can only use it with single file components and you need to use auto import. So direct imports don't work for that. So you can't just say, I import this and this from components or whatsoever. And you need to have the lazy prefix, of course, which is automatically added by Nuxt.

Right.

So, yeah, these are some gotchas. Some some people definitely experienced. And they're also highlighted in the docs, but better say it twice than ever.

Yeah. I think this will be an interesting feature to see what we can do with it. And I'm looking forward to experimenting with this one now.

Yeah. Especially performance wise, I think this will bring a lot of, lot of gains. Because before you had no choice to, well, hydrate it all, and now you can say above the fold, the rest on visible, or, like, on idle and so on. So, yeah, definitely for everybody out there who has, like, a public facing page. And it's already on two dot 16. Well, if not upgrade now and implement lazy hydration, there you go.

Another feature is the named layer aliases. So, yeah, we get this hash layer slash the name of your layer you can access when you're doing imports, but you can also provide custom names through the next config. So if you wanna have a different name for the layer, then, yeah, you can do that, which I think this will make it a little bit easier and a bit more organized to access things from different layers in your app. It's a bit of a smaller one, but definitely quality of life improvement there.

Absolutely. I think everybody using layers was waiting for that in a way, but there are not that many people using layers, so also worth checking it out. Whenever, I don't know, you, for example, slice your application into domains or features locally or you have a more elaborate structure or use white labeling or similar, then you would probably use Nuxt layers. And before you had the problem that you can't reference single layers and say, I don't know, hey, give me a certain component or a certain image or whatever from a different layer. And this made things a bit more opaque.

Yeah. And you don't have to do relative paths or anything Oh, yeah. Like that, which can be a whole mess. So

Yeah. I'm I'm happy that there are solutions for that now. Like, also, this is something I I remember we talked about quite a bit here and there. And it wasn't too trivial to get to a good solution, but, yeah, it's up now. Definitely give it a try. And, well, if you have any suggestions or feedback or beware bugs, let us know.

Well, yeah. And I think as developers, we're familiar with that. Sometimes the things that appear simple on the surface and are just, like, clean and obvious are actually the things that took the longest to figure out how to do. And then also to actually implement takes a long time.

I've had

in the past where, you know, I spent like weeks on this one on a feature that was like a button, but all the stuff in the back end was very complicated. So it was this kind of funny way that it didn't look like a whole lot, but it was.

Yeah. It's the same. I know you have PR and you come up with 10 lines of code. And they're like, yeah. I I took two days for that. And then people are like, how do you take like, how does it take you ten day two days for 10 lines of code? And they're like, yeah. Well, this is not how they started with. Like and first finding Yeah. Like, finding the issue. Then like, okay. Here is how it works. Here is no. There's another thing. We've been through that.

Yeah. At some of the places I've worked, it's been where the senior devs would, like, do a PR, like, every couple days. That might be, like, three lines of code or one line of code. And that's like, what are you doing? And like the junior devs are like committing all this code and just like, you know, but that one issue was like 99% just trying to figure out what the problem was.

Exactly. And that's always good when you have, like, don't a PR and can describe at least, hey. This was my thought process. This is This is what what I did. So it's Oh, yeah. At least a bit more transparent. But still, very often, you don't see the work that is done behind the the whole thing there.

And so with Nuxt three dot 16, we've also got Nitro and other UnJS packages have been upgraded, but Nitro two dot 11. And I think the main thing in that one is better error messages.

I think it's a great feature that before, I felt the errors, the stack traces, were always a bit tricky. Back in time, actually, Nuxt two, we also had it. It was called Yauth. So it was a wonderful, nice error page with some stack trace and everything also nicely in CLI. And that made a comeback for Nitro v 2.12 sorry, v 2.11.

Yeah. So instead of getting just, like, an error page that doesn't have anything useful, it's got your stack trace, nice, intact highlighting, and yeah.

It's pretty sweet. And and talking about debugging, actually, there's another thing. It might be a minor thing in in a minor version, but of Nuxt JS. There's also better way to debug stuff now. Because before, there was this flag in the Nuxt config. It was just called debug, You can set it true or to false. It was always enabled in dev. That's great, especially if you want to debug things. But then it starts like, okay, you turn it on and you get tons of messages from anywhere.

Yeah. So I'll just do a quick rundown of the different flags here. You got templates, modules, watchers, hooks, and there you can specify client or server hooks. And you've got Nitro, router, hydration.

Exactly. And more to come if there's anything else needed, but I think that's that was the the default we rolled with so far.

Yeah. This is gonna make things a lot nicer because, yeah, like you said, you don't sometimes just having debug messages for everything isn't helpful because you actually can't find the actual thing you're looking for, and that's, yeah, that's not really much better.

Exactly. So, yeah, worth worth trying it out if you ever have issues. I know, at least anecdotal evidence, I know from a lot of people have never used the debug flag. Might be worth trying it out if you have some issues. So I heard it's useful.

Yeah. For whatever reason, I also forget to use the Nuxt dev tools, and, like, they're so good and have so much in them, and I just forget that they're there. Even though there's, that little floating thing at the bottom that you just click on, and I just forget that I can open that up and check things out. But I'm trying to get better at, like, forcing myself to to use that more more and more because I think it's, yeah, it's it's got useful stuff in there.

Absolutely. And good that you mentioned that because Nuxt DevTools also saw a v two major release actually of three dot 16. So it's not like a massive update as in tons of new features. It's mainly necessary breaking changes, whereas the major version should be. So now DevTools before, they're always based on Vite.

Yeah. And you can also choose a different editor for opening things up into

True.

Which I think is great because a lot of us have switched over to cursor or, you know, there's a whole bunch of other editors out there, zed, NeoVim, etcetera.

WebStorm. Yeah.

WebStorm, the list goes on. There's been like an explosion lately, I think. And especially with all these AI assisted ones and not everyone's using Versus Code anymore. So yeah, you should be able to configure that.

Do you still use VS Code?

Well, I'm using cursor. So in a way, I'm using VS Code. Yeah. It feels like VS Code to me.

Yeah. That's I mean, it's a fork.

Basically. Yeah. Yeah. Exactly. I still use the original, but I use the insider's version that I upgraded a couple days ago or so and to also use a co pilot with the new agentic workflow. So that's pretty fun.

In that sense, upgrading can also lead to performance improvements. And, yeah, there were quite some actually in 3.16 Actually, Harlan did a PR also out of nowhere that improved the performance of basically starting your application.

Yeah. Another great example of what we were just talking about before of, like, just, like, shifting some lines around and rearranging it, then suddenly, you know, we get some performance gains there.

Yeah. Yeah. And it's still without breaking changes. So that's the the best part. There were a few things where we thought, like, okay. Let's revisit. Because Daniel, like, originally put the order in a different place or, like, considered a different scenario, but things work fine. So, yeah, win win for the community. And it's that's that's not even it. Right?

Is that in three dot 16?

That is also in three dot 16. Yes. So there we adopted oh, I see. It was like PR. Let me check here. Thirty thousand sixty six where Daniel moved all the things over.

Okay.

Things just work. Also there, a big benefit. It will be even better when we have rolled down in Veed. Not when an episode comes out. I guess you can try it out already, but it's not landed yet. And then things will be even faster then, so a lot of speed boosts coming up.

Yeah. Not just functional testing, but also the performance testing so that because that's a I mean, for NUCs as a framework, that's a very important metric for like, when I'm building an app, I'm not gonna worry as much about performance because that's why I use Nuxt. So Fair. Like I do like like obviously I do wanna test for performance and like make sure my SEO is gonna be good and that users can load the stuff and get around the app. But it's definitely a lot more serious of a thing for the framework itself.

Definitely. There

was so much performance testing.

There, especially the framework or library level, if you fix or improve things, then it will have an impact on so many people. So of course, that's a big part. But that's no excuse to not test the performance of the application, especially if it's public facing. So definitely worth doing that. Also in the CI, never hurts to set these up. But of course, takes time. You have to dig into that and so on and so on.

Yeah. But, you know, it's worth it. Testing is one of those things that that often gets forgotten about, but it's also important. So just throwing it out there. Quick reminder to do some testing.

Exactly. Pause the episode or continue listening while while implementing it. You know the drill. And I think for Nuxt 3.16, there are a few more things. So we linked the the blog post, of course, that's always part of a new minor release for for you in the show notes to see what other amazing things are in there, like Unhead v two, for example, decorator support, some some minor changes here and there.

Yeah. Give us some comments, some replies. Good to hear from you.

Yeah. And then I guess we jump all the way over to the other big release that came up recently, UI v three. Michael, tell us.

Yeah. Nuxt UI v three and also runs in Vue. I'm gonna mention that a few times because it's called Nuxt UI, but there was some recent work done that allows it to run just with Vue. You don't need to be running Nuxt to use this, which is great. And, yeah, a big update.

I must say Nuxt UI v two was also really nice to use. But of course, now with Tailwind v four, which is one of the reasons a lot of people wanna upgrade, because we we too will not get Tailwind v four support. And also with being based on Reka UI, which some people might know before as, like, Radix UI, that gets a more, let's say, robust foundation. And also it's accessible out of the box because the primitives are tested for accessible. So that's great.

Yeah. And one of the the big changes too is that so we we switched to Tailwind v four, but then also there's a new design system which uses CSS properties. Is that what they're called? I always forget there.

CSS variables.

Variables.

Yeah. I think.

Yeah. Variables, properties. I think there's sometimes both terms are thrown out there, which is confusing.

Yes.

Anyway, the whole variables in CSS, Nuxt UI v3 is using that, is done so that we can sort of simplify how the theming is done, so instead of always having to specify the exact tailwind class, we can have a bunch of variables like UI text highlighted or UI text muted, UI background, whatever. And so that way we can have this abstraction over your tailoring classes, have a design system built in. Then of course you can customize those variables, and then because the components all use that, then it's just easier instead of you just have one place to customize things.

Yeah. And another thing that's nice to UI V3 is based on is the tailwind variants. So that's actually, once again, another thing that was, I think, first propagated for Stitches was introducing variants and the people behind Hero UI said, Oh, it's great. So they brought that over to Tailwind CSS. You can basically define your variants, let's say a shorthand for base, a button, whatsoever, and then reference that by calling, well, tv, fortainment variants, defining all the things and then calling whatever the definition is as a function and then saying, Okay, I want to have this size.

Yeah. And one thing to point out is that I think this is maybe confusing for some people, but the Nuxt UI is the the people behind Nuxt UI is Nuxt Labs, which is a company run by Sebastian Chopin, I believe. Correct. And so it's separate from the open source side of Nuxt. Maybe you wanna take over this one and explain a little bit of the differences there.

Yeah. I think the best one to explain it is Sebastian, which is why we don't have him here in the episode, but we'll hope he'll come on soon and we talk about all that in-depth. Yeah. Because I think that's that's pretty important. But to add on there, it's it's absolutely correct.

Yeah. And so the with Nuxt UI, there's the free open version of Nuxt UI, which comes with a whole bunch of components you can use. And then there's Nuxt UI Pro, which is the paid one. And there you get some extra components and some templates and things like that. You can quickly throw together a landing page for SaaS and stuff like that using the Next UI components.

Exactly. So some templates, you don't have to build them from scratch. You can use them. Also, you can alter them as you want, that's fully up to you. You can copy the code over.

Yeah. And if you buy through that link, then you also help to support our show here, which isn't free to run, by the way.

True that. True that.

You maybe didn't know that, but we have a wonderful editor who does all the work all this work for us. And, you know, we have to pay for these this recording setup and stuff. And also paying for Nuxt UI Pro. I'm not trying to sell you on it here, but just to like add further clarification. So Daniel Rowe, who's leading the Nuxt team on the open source Doesn't work for next labs, but he gets some of his funding from the team at next labs.

Yes. And it's win win win win. Right? Okay. You get a head start. You support open source. And, yeah, we're all happy at the end. And, ideally, your company paying for that, so they also see something back. I I also talked a lot with companies like, yeah, ideally, want to, I don't know, sponsor some creators, but then people are like, okay. But why?

I don't think we've missed anything. Yeah. We mentioned it's that works with Vue. Mention it again. And, yeah, I think that's that's it. I think we covered it all.

Perfect. Then we can only tease for next week's episode because we talked a little bit about sustainability of open source, totally not on purpose here. That just fit in very nicely. Next week, we'll definitely dive into that a bit more, so stay tuned for that episode. Make sure you listen to the old ones if you don't know them yet.

Yeah. And the weird thing about the slogan is I don't even remember like, we didn't brainstorm it. It just it just sort of happened. I think you said it one time, and then

we kept it, I guess.

And then now it's it's just a thing that we do. So Yeah. Yeah. Maybe we have to to swish it up.

Let's see.

Do you have any suggestions for us? We we'd love to know. Put in comments. Maybe we'll maybe we'll take your suggestions.

Yeah. Well, you know what? Just do a little social media post as well. And if people have a new slogan idea, let's let's go. Then maybe we make a little mini episode just rating them.

Let's see. Need a slogan?

Like, no. Like, a mini episode just rating them. Like, hey. This slogan, how do feel about it?

Yeah.

Okay. A lot of extra content ideas. Nevertheless, I hope you enjoyed the episode, and we'll see you all in the next one. Until then, folks.