Of course, we can't fully start into 2025 with a little ReVue of the past year. And to make sure to catch all the highlights, Alex is joined by Daniel Roe, full-time open source developer and lead of the Nuxt team to go through some notable events of 2024 in the Vue and Nuxt ecosystem.
In addition to the shining moments of 2024, don't miss out a deep dive into web fonts, learn why Nuxt 4 isn't out yet if you didn't know already and maybe even get a slight glimpse into 2025 and Nuxt 5.
Links marked with * are affiliate links. We get a small commission when you register for the service through our link. This helps us to keep the podcast running. We only include affiliate links for services mentioned in the episode or that we use ourselves.
Chapters
The Year in ReVue
Daniel's favorite release in 2024
How did Nuxt Fonts evolve in the past year?
Benefits of Nuxt Fonts
Possible Future Improvements of Nuxt Fonts
What devs do wrong with fonts
The one CI tip saving you troubles
Vue 2 going EOL
Vue's development progress in 2024
Alien Signals
Tooling in Vue
Triaging the ecosystem
Our favorite Nuxt.js improvements
Nuxt 4
Nuxt 2 going EOL and Nuxt Bridge
Incremental improvements in the Vue Ecosystem
The Open Source Pledge
VoidZero
Our Favorite Vue.js Features in 2024
Quickfire
Honorable Mentions
Your feeling about the Vue and Nuxt ecosystem in 2024
Wrapping Up
Of course, we can't fully start into 2025 with a little ReVue of the past year. And to make sure to catch all the highlights, Alex is joined by Daniel Roe, full-time open source developer and lead of the Nuxt team to go through some notable events of 2024 in the Vue and Nuxt ecosystem.
In addition to the shining moments of 2024, don't miss out a deep dive into web fonts, learn why Nuxt 4 isn't out yet if you didn't know already and maybe even get a slight glimpse into 2025 and Nuxt 5.
Links marked with * are affiliate links. We get a small commission when you register for the service through our link. This helps us to keep the podcast running. We only include affiliate links for services mentioned in the episode or that we use ourselves.
Creators & Guests
Host
Alexander Lichter
Web Engineering Consultant • Founder • Nuxt team • Speaker
Guest
Daniel Roe
Nuxt Team Lead and Independent Open Source Maintainer
Editor
Niki Brandner
Audio Engineer and Video Editor
What is DejaVue?
Welcome to DejaVue, the Vue podcast you didn't know you needed until now! Join Michael Thiessen and Alexander Lichter on a thrilling journey through the world of Vue and Nuxt.
Get ready for weekly episodes packed with insights, updates, and deep dives into everything Vue-related. From component libraries to best practices, and beyond, they've got you covered.
Alexander Lichter:
Welcome back to DejaVue. It's your favorite Vue podcast, and, you probably know it by now. First of all, it's a bit belated, but happy New Year to everyone out there. I hope you had some relaxing holidays, some downtime, maybe some time to work on some side projects, open source contributions, and so on, so on, so on. Let us definitely know what you did in your free time and, if you could, get away from all the electronic devices or, like, no.
Alexander Lichter:
I have to finish. I have to put out a side project. And, yeah, why not taking the time now that it's 2025 to have a look at what happened last year, so to say, a year in ReVue? And, of course, that can't be done alone. So, we got a lovely guest on here.
Alexander Lichter:
He is I know him already, but he's the lead of the Nuxt.js team. He is a full time open source developer. And, of course, when he's not coding, which is very, very rare, then he's probably out there bordering around the world somewhere. It's Daniel Roe, everybody.
Alexander Lichter:
Daniel, how are you doing?
Daniel Roe:
Hi. It's, it's nice to be here. And, obviously, I took a break from my, difficult, bouldering schedule to, to make make make the recording.
Alexander Lichter:
Perfect.
Daniel Roe:
Yeah. Doing very well. Thanks.
Alexander Lichter:
Glad to hear that. Yeah. And I mean, also, like, all the releases coming out, if you have a few things on the list, quite a packed schedule, so to say. Also said beforehand, you know probably half of the releases we have in the list anyway because you were either in charge of them or at least somewhat contributed. So, do you have something?
Alexander Lichter:
If I have to pick one thing from 2024, this is it this has to be mentioned.
Daniel Roe:
And one of the things I was most excited about was, was Nuxt fonts, which I think probably because I was so involved in building it, you know, user of Nuxt. I I benefit from lots of things that other people code, you know, like Nuxt dev tools, for example, I'm basically not at all involved in doing, and yet it's one of the best things about Nuxt. But somehow when you're involved in creating something yourself, you always feel this little sense of, yay, that was cool.
Alexander Lichter:
Absolutely. And,
Daniel Roe:
I definitely felt that way about Nuxt fonts. It was, it was pretty cool.
Alexander Lichter:
Nice. And, yeah, the initial release was, I think, around Vue.js Amsterdam time. I think you released it. Did you release it live on stage? I think so.
Alexander Lichter:
Right?
Daniel Roe:
Yes. Is that right? I think yeah.
Alexander Lichter:
I think so. Maybe
Daniel Roe:
I did.
Alexander Lichter:
So link to the talk, definitely, in in the show notes because, of course, then you also gave a talk all about, Nuxt.js And, also, a link, to the the shop for 2025 edition of Future Samsung, which is coming up in March, so very soon. Discount code there. So just to mention, drop it in with code DEJAVUE.
Alexander Lichter:
Get 10% off. But, yeah, back to Nuxt fonts, like, how did you see the project evolving from its initial release that's, well, almost like a year ago now? Did a lot change?
Daniel Roe:
So, I mean, I remember, sort of drafting some RFCs for Nuxt, scripts, assets, and fonts, and, and having a look through. And and, obviously, you know, the, Nuxt assets isn't isn't built as a project, although the ideas of it are implemented in scripts and fonts. And scripts isn't entirely implemented as I sort of imagined it. I think it's probably implemented better.
Daniel Roe:
But I mean, I remember sort of writing writing Nuxt fonts and, and just thinking about what it could be, because we have examples of how font integrations work in other frameworks. Next.js, for example, has a font integration, which is basically importing from a file and then sort of binding those styles to an element in the same kind of way that you would in React or in in CSS and JS. And obviously there's stuff like font source, which lets you do the same kind of thing in any framework. But I actually sort of starting to build it, I just realizing, actually, we can do this with no configuration.
Daniel Roe:
We can do this to from CSS. You know, we don't need to have people explicitly import anything. It can just just work for them. And that was, that was incredible. So then which is not as I totally imagined it, I think, in the beginning.
Daniel Roe:
I would have to go back and have a look at exactly what ended up in the RFC, but, I think it definitely as as we were working on it, it just sort of sort of expanded, you know, in terms of of of capability. And that was that was that was fun.
Alexander Lichter:
Amazing. Yeah. I mean, now it's everybody is using a web font out there, no matter if local or from any kind of provider should use Nuxt fonts to get all the benefits. Also Fontaine, which you managed before, which is also integrated into that, and, of course, also, like, downloading the fonts, serving it locally to avoid all the GDPR hassle, and so on and so on. So there are a lot of neat features out there straightaway that people can use without any downsides.
Alexander Lichter:
Right?
Daniel Roe:
Yeah. Exactly. So it it should be, you know, as we aim for and everything, really, and all the the next libraries, the sort of idea of of the progressive path where, you know, it it sort of does things for you that are best best practices and you can always sort of take full control. And, yeah, so you get the the benefit of not needing a preconnect, you get the benefit of the CSS being generated for you for the fallback fonts. Yeah.
Daniel Roe:
I think that yep. You get a lot of things out of the box.
Alexander Lichter:
Sweet.
Daniel Roe:
And and the multi provider is a big thing. So, you know, you're not making choices between, how to set up Google or Bunny or Fontsource or Fontshare or whatever or how to add the the links even to a local font that you drop into your public directory, but it just just works.
Daniel Roe:
I actually I recall using a library years ago called PostCSS Font Magician. Mhmm. And I'm pretty sure it did something similar as in it detected what you were using from CSS and and added some links. So, in terms of the but, I mean, it added links to Google Fonts in your CSS. So I think that, you know, there's probably art out there in terms of people thinking about how to do this magically.
Daniel Roe:
But, yeah, yeah, it does a lot of things just for you so you don't have to do them or think about them.
Alexander Lichter:
As well, the video or you also talk shows, you just say, hey, I want to use, I don't know, Poppins, Vingdings, whatever, and it would just magically work out of the box.
Daniel Roe:
Yeah. It just works. So, almost everything that needs to be done, you know, there's some there are some complexities. So for example, we can't yet determine what font weights you use because of CSS being cascading. So you you can, you know, set bold higher up and then you're using a font lower down.
Daniel Roe:
So we we don't know necessarily that that is going to be bold or not. So you do have to configure your weights. But I'd like to think that even that we might be able at some point to at least configure if you explicitly set it. You know, if you say this font and then font weight, we we should know that. We should be able to grab the right font weight for that one.
Daniel Roe:
So I think there are some some further improvements. You know, my my aim would be for it to be as optimized as possible, even maybe you're doing some automatic subsetting. So very common, for example, that people use a heading font. If we know all the headings in your app, and we know all the we should be able to create for you the subset font, which just has the characters needed to render those headings. Now that's a pain to do manually because every time you change a heading, you have to resubset the font.
Daniel Roe:
So if we can automate that for you and create smaller fonts for users, I think that's a nice feature to have. It would be opt in, of course, because it does mean that you you then have a a font that, isn't quite as cacheable between deploys if you're subsetting slightly different characters. But I think, you know, there are there are things we can do to to make it even better and from a performance point of view.
Alexander Lichter:
And I guess it also only works then for, let's say, static content because as soon as you fetch content from, like, a headless CMS, it will be a bit trickier with the the subset.
Daniel Roe:
Yeah. Exactly.
Alexander Lichter:
I mean, then you could probably still say, like, I don't know, configure wise, only the Latin subset, only the cyrillic subset, whatsoever. So, like, at least exclude as what I did in the past with funds, certain there are certain letters that definitely will not use, like alphabet wise.
Daniel Roe:
So Exactly. Characters and stuff like that where you're like, yeah, I don't I don't think I'm going to be using it. But I I it always comes back to bite me. And I think it's one of the things that this isn't, you know, very year in Revue, but I think that I was giving a talk just last night, at a meetup about fonts. So I'm gonna go on about fonts forever, you know.
Alexander Lichter:
That's fine. That's fine. I'll stop you.
Daniel Roe:
And it's one of the things that I think we can get wrong as developers, when we're using custom web fonts, and we can install them on our computer. That's a terrible thing to do Yeah. Because it means you see the font you have installed on your computer and you never see the web font. So, you know, you have characters missing in the web font, you wouldn't know because you have it locally. You see, using a font weight that isn't supplied in your HTML, there's no rules in your CSS about it, but it still works because it's on your local computer.
Daniel Roe:
So if you're like me and you're like, hey. I want all the fonts in the world installed locally, and you just sort of download some pack, and then you're using that in a site that you're building, you might miss big visual problems unless you have some kind of way of of testing, which might be, for example, to have a different name.
Alexander Lichter:
Yeah.
Alexander Lichter:
So it doesn't load
Alexander Lichter:
The local one.
Daniel Roe:
Yeah. Mhmm. So, actually, we could probably make that work in that response for you automatically. So you use Poppins, and we just rename it for you. We're like Poppins web, because all that matters is that it matches with the font face that's generated, and we're generating it.
Daniel Roe:
So it's not something you would even need to think about. That might be there you go. Thank you, Alex. Good idea.
Alexander Lichter:
Yep. Already worth coming on to the DejaVue podcast again.
Daniel Roe:
Yeah.
Alexander Lichter:
It it's really funny, though, because I I worked at a a client project. It was the same issue that, like, everybody, but not of developers, but actually of the the stakeholders checking their website had the font installed. And, of course, some of the developers, I came in, like, hey. That's not the corporate entity font. And they were like, what?
Alexander Lichter:
We set it here. Like, yeah, but never loaded. So then nobody noticed, of course, because they all had to install locally for legacy reasons, I guess. That's definitely a a real thing. And, yeah, looking forward to to have that fixed in next months or, like, in fixed, let's say, that make it easier to spot these problems.
Daniel Roe:
Do you know I have a I mean, I I think it's one of the most useful things you can do on getting a new website up is to create an end to end test that just takes a picture of the home page.
Alexander Lichter:
Yeah.
Daniel Roe:
That's it. And, like, obviously, you expect this to, sort of change as you change the home page or whatever. But just hang having it in CI, the test is run and probably auto fix, like, automatically updated, So you're not having to manually run this all the time. But it means that you visually reviewing the PR, you're like, this is what the Playwright computer is seeing, and not what I'm seeing on my computer. And that is, I think, it detects re serious regressions, like your CSS breaks for some reason, you're targeting the wrong selector.
Daniel Roe:
You know, CI will always pass. You know, it's very difficult to sort of test that. Well, I mean, you you can do it, but it often adds friction and people don't end up doing that. So just screenshot your homepage and it gives you a huge amount of coverage of things are rendering as they're expected to. I find that it finds font problems.
Alexander Lichter:
Oh, that that's for sure. Yeah. I mean, I love that idea in general. It's like, hey, it's not a like make or break the it has just like here is that. You can look at it while you review the PR and take a look before merging it, and you know it's fine.
Alexander Lichter:
So just like having that, it works on my machine problem sorted out by another entity, in this case, the CI and Playwright solving it. It's, it's really smart. I think, yeah, that's and shouldn't cost that much either, spinning up a higher instance, making a screenshot. CI mini device shouldn't be too expensive. So definitely something that you that people should add to your project.
Alexander Lichter:
Love that idea.
Daniel Roe:
Yeah. Yeah.
Alexander Lichter:
Coming back to the the year in review, I think it's still good because I guess the the font problems, but you quite sometimes has worked a lot on fonts in 2024. Maybe even go back from February when Nuxt fonts was released a little bit back to, let's say, the the first January, which was a remarkable day in 2024. It was the first day where Vue 2 was end of life, so to say. So how did you feel that day? Some joy, some pain?
Daniel Roe:
I think by that time, I had not been using Vue 2 for a very long time other than to support people with Nuxt 2. And I think my I wasn't totally I wasn't totally weightless because we were still supporting Nuxt at this point, and Nuxt 2, and we didn't want to to drop that at the moment that Vue we dropped support for Vue. It would have been nice, but, really, I was then still going to be working with Vue 2 for for a bit. So it felt more like a stepping stone, in the right direction. I mean, I regard that the move from Vue 2 to Vue 3 is a totally good one.
Daniel Roe:
I really like it. Vue 3 is more performant. Obviously, it drops support for some certain legacy systems that don't support proxies. But again, I think, you know, often as a developer, I feel you're limited. The language is evolving.
Daniel Roe:
There are new features. There are great new built ins. All the time they're coming out, but you're always having to code defensively for the older systems you're supporting. And that's even more so obviously for both of us, sort of maintaining Nuxt. We, you know, we can't just adopt, the sort of latest thing that's coming out in Node 22 or, in the latest, you know, bleeding edge browser, you know, Chromium release or whatever.
Daniel Roe:
We we just can't. Even if we want to, even if it's going to be a a pretty cool thing, the most we can do is let users opt in with an experimental flag, which obviously we do. It's, so so it's it's hard, to to have to support back.
Daniel Roe:
But the vue 2 to vue 3 migration, it was, it it might have been painful, but I think the result at the end with vue 3 and the composition API is just gorgeous. And Vue 3, I think, fixed a lot of captures also with Vue 2 in terms of how reactivity worked.
Daniel Roe:
You know? Do you remember having to mutate arrays? Like, that was, you know, that was always a thing. Why why shouldn't this work in the same way that chain objects, worked. And, you know, things work a bit better in v three, and that's that's really nice to see.
Daniel Roe:
I think I'm a lot happier with vue vue's general progress, though, at the end of the year than I was at in the beginning. Because in January 1, although we were dropping support for vue 2, the progress of vue 3 was a bit slow. It felt like releases were taking quite a while. There were some significant issues with, SSR. And in general, it, you know, it felt like q three was done, but there were still some issues and things were were a bit slow.
Daniel Roe:
I don't mean to be mean or anything because what I think I've seen across the year is that stuff is really picking up on Vue. So a lot more contributions, bug fixes are being merged. The SSR story is a lot more stable. I'm loving the work on improving the reactivity system, but we already, by this point, have had 2 almost complete refactors of reactivity in Vue in minor releases that, have made it so much more performant. I mean, just it's it's an incredible to see.
Daniel Roe:
Particular, hat tip to Johnson and and also Evan, of course, as well who's been been working on that. But Vue has just really started accelerating in terms of pace of development and improvements going on. So I'm I'm really excited about that.
Alexander Lichter:
And on on that note also, yeah, you said it, minor versions, which means no breaking changes. So two times refactored to different system underhood without breaking anything. And now, we can jump a little bit, for that a little bit, further with Alien signals 1.0 being released, just couple days ago and which was going on for a while, we see even more performance improvements and another refactor of the system. So that's super exciting to see, okay, people from the Vue ecosystem are pushing the boundaries. And with that library, it's not even tied to Vue itself anymore.
Alexander Lichter:
It's more like, hey. This is a single library people can use and, like, Angular signals, solid signals, Preact, whatsoever. They can all implement it with the same ideas and techniques, not necessarily depending on the library, but using the same patterns.
Daniel Roe:
Yeah. Although, you know that, Johnson got into some some hot water. You probably know you know this. Right?
Alexander Lichter:
I do. I do.
Daniel Roe:
You're like, I wasn't planning on going into that, Daniel, but if you insist
Alexander Lichter:
Bring it on. Bring it on.
Daniel Roe:
I think the package was originally called native
Alexander Lichter:
native signals. Yeah. Native signals.
Daniel Roe:
Yes. And this was criticized because it's not, there's a proposal obviously to bring signals natively to the browser, and this was not an implementation of that. I think Johnson meant it to be sort of as close to sort of native JavaScript, you know. Yeah. As close to, like, really, really minimal, rather than it have anything to do with the the the proposal.
Daniel Roe:
And actually, I felt that it was really, like, the sort of negative press he got. It was really, really unfortunate. Like, I don't see I don't anyway, I thought I thought it was bad really bad form. And I think the people who made him feel bad really ought to take a good hard look in the mirror at, you know, what they were doing to an open source maintainer who was trying to make the web a better place.
Alexander Lichter:
Yeah. That's that's the craziest part. It's not even, like, I don't know about competition or framework wars or whatsoever. We're like, yeah. Okay.
Alexander Lichter:
It might still be a little bit of foul play, but, okay, kind of, like, people do that sometimes, like, the the weird joke with a JSX versus Svelte and Vue components, but it's also another another story. But in there also, it's like, hey. Come on. Johnson is trying to improve, as you said, the Web ecosystem, making it better for everyone than saying, oh, basically, how dare you naming it that way? Come on.
Alexander Lichter:
But I'm I'm very happy that this, in a way, got I wouldn't say necessarily resolved, but, like, this conflict isn't there anymore with the renaming, also moving it to to the Stackblitz org. And, finally, we went full circle now because Johnson created a PR through the TC 39 signals proposal to write the polyfill based on the alien signal 1.0 implementation. Yeah. Still, of course, stop passing all tests and stuff. But, like, okay.
Alexander Lichter:
Hey. That's the outline. If you wanna make sure all the the tests are passing, that's that's further up to the maintainers. But in a way that comes back now to the proposal making, that's ideally also super fast. So yeah.
Daniel Roe:
I mean, Johnson is an example of a lot of the people who are working behind the scenes, who don't necessarily receive the appreciation they deserve, who are making things better for a lot for everybody. Obviously, you know, from Volar, one of the reasons Vue 3 is so great is the TypeScript integration and therefore the IDE integration, and a lot of that is driven by Vue TSC. So if we didn't have that, if we didn't have this really strong type checking experience, if we didn't have not just an IDE extension, but something you could actually run-in the terminal to type check Vue components, you know, developer experience of Vue would be hugely less. And, yeah, I'm not I'm not sure he always gets the appreciation he deserves.
Alexander Lichter:
I think it's actually even worse than that. I think he also gets some unjustified negativity, like, especially on some social media, there's always like, oh, I don't know. I can't use Vue because of the Vue, language extension whatsoever. Of course, also not writing. Okay.
Alexander Lichter:
It's the Vue official VS Code extension whatsoever. Or this and this sucks and breaks. If these people would just report bugs, then probably Johnson would be fixing them really easily instead of, like, hating how bad everything is because that doesn't make things better. So I really think, like, Johnson does an amazing job for, as we just said, the web ecosystem, but also about the whole Vue ecosystem. And I finally made a video about Alien Signals when it was, like, 0.4 or so, and then Johnson was like, yeah.
Alexander Lichter:
Wait. Wait. Wait. We're we're not done yet. There is more coming.
Alexander Lichter:
And just highlighting, like, how someone is like, okay. I wanna improve Volar, so I need a faster signals library, improve the whole web ecosystem. And having that as an example, once again, coming out of the Vue ecosystem is really nice to see. People should, instead of writing another sh*t post on on Reddit, maybe consider reporting their bug. Even might not be that easy because, yeah, lots of moving pieces, VS code version, code and so on and so on, but that would actually help.
Daniel Roe:
It's really difficult with, anything that is the, like, the apex of a pyramid. So people experience the VUE language plugin, like the, Vue support coming from Vola. And the thing is, he's working with a lot of moving parts. He's working with TypeScript. 1, TypeScript can release breaking changes without a major version because they don't.
Daniel Roe:
He had to send Semva. The numbers are just arbitrary. Like, when we get to TypeScript 6, it's not going to be that there was a big change from TypeScript 5 dot 9 dot whatever. It's going to be that way because that's how the they're just incrementing. But also, IDEs are changing.
Daniel Roe:
And also, Vue TSC particularly needs to hack into the internals of TypeScript. So it's not even that there might be a breaking change with someone else, just a a minor patch change to TypeScript could also break Vola. So there's so many of these moving parts, and it's easy for people to think, oh, it's a bug in Vola. Like, this is broken. I mean, we experienced this also with with Nuxt.
Daniel Roe:
You know, if something goes wrong in post CSS or in Babel,
Alexander Lichter:
Or in Vite.
Daniel Roe:
Or in Vite or Rollup or in ES build. There was a big breaking issue with ES build in a patch. I mean, it's still sub 1, so I guess it's a minor, but in, in like the final significant digit of of ES build that broke Nuxt totally and also all other Vite, framework. But the point is we're the end, with that end of the wedge. So people experiencing this bug, experiencing it, they experience it with Nuxt, and so it's a bug they report to us.
Daniel Roe:
And the same, I think, is true with obviously Volar. You know, it's you're triaging the ecosystem because the experience that people are having is they don't know where it's coming from. All they know is that they're using Nuxt or Volar, and they're experiencing a problem. And so it's easy as a as a maintainer to think, you know, not my bug. But it's, you know, it's difficult as a user to know where where it's coming from and where to report it.
Alexander Lichter:
That's the other part. Yeah. Like, why or, like, as a user, you can't I can't really expect, okay. I see it here. I report it, and then maybe it might be escalated upstream somewhere.
Alexander Lichter:
But, yeah, I have the issue right now there, and let's say, Nuxt or Volar or whatsoever. And, of course, like, not everyone is a is a VS Code extension developer or framework developer, like, has the time to dive in. But it's like, okay. I started. Oh, it doesn't work.
Alexander Lichter:
Dang it. Then, okay, I check. I report a bug. At least, like, that's already, I think, a really good step there. But, yeah, the maintainers of these projects, of course, then have the additional effort of, like, okay.
Alexander Lichter:
For Nuxt, well, this is a Nitro Bug. There's another dependency. Here's something with Vite, and they, once again, Vite might put it up further up the chain and so on. But that's also the the part of depending on dependencies, sadly. And as you said, being the the end the user facing parts of the same use case, developer facing part.
Daniel Roe:
I do worry sometimes that I don't like, I I do appreciate it when people raise bugs. I do worry that I don't necessarily come across that way. I don't know about how you feel, like, in your your own projects as well, but because, you know, I close them. I close the issues. You know, someone has created a reproduction, and I say it's not not a Nuxt issue, and I close it.
Daniel Roe:
And I feel so bad about that because I worry that people will think I don't appreciate the effort that's gone into reporting it, and I really, really do, but there's nothing I can do about it. You know? Yeah. I'm not sure I get that balance right always. I really feel bad.
Daniel Roe:
I really feel bad. I I I wish I could give you no an apology to people. I'm so sorry. You you you worked, you created a reproduction. Thank you for that, but it's not a Nuxt issue and I I can't, I can't do anymore.
Alexander Lichter:
But I guess usually you give people pointers like, hey, it's not Nuxt issue, but there is the problem. Or, hey. This should be reported there and there. So at least it's not like that's the end. You tried.
Alexander Lichter:
Goodbye. If you don't know how how to continue further, usually, it's like, here's the next point where then people maybe have to alter reproduction. Okay. At least I narrow it down, and I don't know, can't narrow it, get down down with the dependency or whatsoever. So it's not like they're they're lost in limbo forever, but more like, okay.
Alexander Lichter:
There's yet another thing that's to do. But you also, like, you you can't fix the whole ecosystem. Nobody can. That's why, like, the delegation part, I think it's it's kinda necessary.
Daniel Roe:
I hope so. I mean, you're right. It is necessary. It's certainly necessary. But yeah.
Alexander Lichter:
But I understand the feeling of like, hey, it would be nice to, like, just have a fix for it straight away. But especially if it's not a Nuxt problem, it's definitely, well, out of bounds, so say, out of scope.
Alexander Lichter:
But coming to, not a Nuxt problem is a good point.
Alexander Lichter:
There were quite some Nuxt releases this year, a lot of patch versions fixing some bugs. But, of course, also a lot of minor versions bringing in features, being experimental features, some, I would even say, polyfills for features that, Vue brought on later, like useId in January, of course, DX improvements and and also actual features.
Alexander Lichter:
So do you have a favorite this year where, like, hey, this, I don't know, this kind of feature or this kind of bug fix, if I have to pick once again one thing or maybe top 3, you're like, yeah, these are so amazing that I have to highlight them.
Daniel Roe:
So there are a lot of things, a lot of things to to highlight in terms of the things
Daniel Roe:
because there are things that I think are cool and there are things that I use all the time and that make make a difference to me. So, I think there's a whole raft of performance improvements, both on the server side and also in the client, and those are some of the things that I'm most excited about to use and experience. So So, actually, even in the patch release, just I don't know. We've we've not talked about this, but I released a patch of Nuxt, just a few minutes before we started chatting. And the performance improvement there improved start up time by 45% in the basic fixture.
Daniel Roe:
I can't promise that to everybody. That was the basic fixture in the next Mana Reaper, which basically has got everything thrown in. But I think it will be proportionate to things like the number of, modules you have installed and the number of page routes that you have in your app. So it should be significant for big big apps. And those kind of things make a big difference to me.
Daniel Roe:
Also stuff like the shared prerender cache, where basically we're adding a feature back from Nuxt 2, the idea that you could have this payload with data that's shared between different pages, which made sense. Right? You know, you fetch common data throughout your app, and then you don't have to fetch it for every one of the 10,000 pages that you're rendering.
Alexander Lichter:
Absolutely.
Daniel Roe:
And the fact that in in Nuxtree now, we are doing it basically automatically. You don't think about it. You don't even have to know about it. It's just automatically shared between pages that are prerendered just based on the key, which we already have generated or advised people to create. And so it just, hopefully will just work and mean that we save 10,000 data calls.
Daniel Roe:
That's the kind of thing that I like most when you basically get something for free. And, and that kind of performance improvement, I think is really, really satisfying to bring. You know, there's some other things like that that, you know, are just very nice to roll out and some, yeah, some stuff that's coming. Actually on the DX point of view, another one that was just rolled out is HMR for route metadata
Alexander Lichter:
Yes.
Daniel Roe:
And routes.
Daniel Roe:
Have you have have you got a chance to try that yet?
Alexander Lichter:
I tried it. It's so amazing. It's like I even I even saw people being, like, appreciating so much on social media, but, like, hey, whoever did that deserve a cup of coffee, and then it was like, yeah. Hey. So no.
Alexander Lichter:
I I also think, like, this is such a game changer because how often HMR, like, makes life easier if it works correctly. And for ease of use, it's it's so amazing, especially now with the patch where I think there was an issue with query params that were not considered while, like, refreshing. So after that's being gone, it's like, nice, lovely, so good. So, yeah, also thanks for implementing that as well. People will be very happy.
Alexander Lichter:
No. Alright.
Daniel Roe:
I mean, bear in mind that I think I was following up on a a comment from Eduardo who implemented HMR. I mean, there were 2 bits to that. So one is the HMR for our virtual files, which was a big thing, and the other was the, HMR for the the routes themselves. And so Eduardo basically dropped a line to somewhere where he had implemented this in unplugin-vue-router. And basically, I think I copied the code across, and that was the implementation.
Daniel Roe:
So I don't deserve a huge amount of credit for it.
Alexander Lichter:
But for the virtual files?
Daniel Roe:
I was Yeah. I was pleased pleased with that, now to get HMR working because we've struggled with that for quite some time. But I think we finally hit either the the Vite capability or the the implementation in Nuxt where it it actually just works.
Alexander Lichter:
So that's definitely a a delight to see. Yeah. And I also agree with, like, all the the performance and also DX improvement that you just get for free. Like, for example, also having SSR logs in the browser console in dev mode. So you're like, okay.
Alexander Lichter:
I'm working on some stuff. I might not check my terminal. I maybe only have a single screen. And in the browser, you can see, like, oh, there's a lock. Like, okay.
Alexander Lichter:
I know where to check. I also have to with a lot of people, like, hey. Check the console. Yeah. Which one?
Alexander Lichter:
The server? The browser? Maybe especially people are not aware, but, like, using SSR implies in terms of complexity. So that's perfect.
Daniel Roe:
That is true. And I think there's there's more stuff coming there. So there's but, yes, being able to see the SSR logs in the browser is really important. I don't know if you know, but you can now see Nuxt Hooks in the performance panel. Yes.
Daniel Roe:
If you're on Chromium DevTools. So you'll actually see them as little, like, marks in the timeline of when the hook ran, which is really useful. I mean, you can see them logged out in debug mode where you actually see it in the console, but it's really nice to see it in the timeline, and that visually helps you sort of compare, like, when did this happen in relation to other things that were happening, other resources that we're downloading. And, actually, I was chatting to, someone on the the Chrome DevTools team. We can actually put similar timings for server side events that are happening in the because you you have the the, like, the initial load, like how long does the document take to load.
Daniel Roe:
So we actually have a space in the timeline, and we can fill that out with other bars that actually includes stuff like what was happening on the server and when did it take them. You'll be able to see I mean, this is coming also to Nuxt dev tools Yes. Which will probably be a better way because it will work in cross browsers. But I don't see a reason why we shouldn't also implement this in the the browser dev tools so people can actually see, like, oh, we were doing some network requests, and they were a waterfall.
Alexander Lichter:
Yeah. Exactly.
Daniel Roe:
Like, just being able to see that that is the pattern without needing to add any debugging in your code.
Alexander Lichter:
Yeah. I mean, I've seen that came in, in December, in Nuxt 3.15, the Chrome support for that. So, that's really lovely. And also, as you just said, having that available for all users, no matter which browser in the dev tools, I think is a key part here as well, to have the benefits for people using, I guess, Opera, Chrome, or Edge. And still people, like, using Firefox, like like me, most of the time, still, be able to check that.
Alexander Lichter:
Even though if you probably do, like, performance, like, checks and and some traces, you probably run Lighthouse and Chrome Tools anyway. But, nevertheless, it's still good to see, oh, yeah. The DevTools, hey. This plug in takes so and so long. It's async.
Alexander Lichter:
There might be something's going on, so so that's great. Yeah. Nice.
Alexander Lichter:
I think another thing, which is pretty interesting, since I think it's Nuxt 3.12 in June, people can opt into a lot of breaking changes with the Nuxt 4 compatibility version.
Daniel Roe:
And this is something that you really, I think, drew or at least the the granular nature of that. Right?
Alexander Lichter:
I think that that was important to me. Yeah. That people can, like, say, okay, I wanna opt into this feature, but not this, this, this one. Yeah. Exactly.
Daniel Roe:
And I think that's actually been essential because it's been such a delay to the release of Nuxt 4, that's been in some ways out of our hands because obviously we're waiting on dependencies. Honestly, I get so many questions from people. Viomi ask me anything, but on my website as well, but, yeah, like, people just, like, when is it coming out? And it's it's really hard, when it's, you know, it's on not your hands. The number of times I've been tempted just to release Nuxt 4 and then release Nuxt 5 when Nitro comes out, that would be a totally acceptable thing to do, and actually would have been totally fine if we had done that back in in June.
Alexander Lichter:
I just wanna say, if you would if you would be able to time travel back to June now and talk to, like, the the Daniel in the past to, like, Daniel from the past and from the future, Nitro is not out yet
Daniel Roe:
Yeah.
Alexander Lichter:
Release. Would you do that?
Daniel Roe:
Yeah. I would. I would because the, I mean, honestly, I think the well, I think the fact that we have the ability to opt into the breaking changes is the most significant piece because it means that we can test them out. And actually, we're coming up to you know, we've had half a year of testing these breaking changes, and people are using them. I'm using them on my projects.
Daniel Roe:
Other people are doing it too, and that it's totally fine. So, actually, you know, I'm very comfortable releasing those. It's not holding me back. I'm not worried about that. We need to do some stuff to migrate modules to use them, and we need to, you know I think that's that's the main thing, just make sure that everybody is up to date, but I'm not worried about any of those changes.
Daniel Roe:
And so if I knew now if I knew then that Nitro still wouldn't be out at this point, I would absolutely release Nuxt 4 back then, because I don't want us to be afraid of major versions. That's the thing. The longer you wait, the more, the more it can feel like, oh, no. What's going to happen? Because we don't, like, we don't remember the last major version or the last one was was far away.
Daniel Roe:
But for example, if I if we had released Nuxt 4 back in June and it was great, and we released Nuxt 5 in February this year, you know, and it's great, you know, like it's not a problem. People will be able to update, particularly given that we're hoping it's going to require less migration than a minor, you know, or a similar amount. You know? We're we're not imagining it's going to be a lot of trouble for most people. So I would like to normalize the the the major the release of major versions, and it feels like maybe we passed up our opportunity to do that a little bit by waiting so long for Nuxt 4.
Daniel Roe:
But it's not a not a a total loss. I I don't think it will inconvenience people too much because they will have been able to test and migrate if they needed to. And anyway, we're imagining this is about a a day's job to migrate rather than a matter of weeks or something like that.
Alexander Lichter:
Or months. Yeah. Yeah. 4 months, but
Daniel Roe:
it there might have been from 2 to 3. So this is this is a, you know, a different order of magnitude. And at the end of the day, there's no harm. So I've I'm not I'm not losing a huge amount of sleep. I just feel bad.
Daniel Roe:
That's that's all.
Alexander Lichter:
Playing the devil's advocate here, what's stopping you from releasing Nuxt 4 now?
Daniel Roe:
Well, I'm not sure that's such a devil's I've I'm I'm I I think the the only thing that has has stopped me releasing Nuxt 4 at any point is people telling me that Nitro will be ready sooner. So, or or or me thinking that it will be. So, I mean, I think that's the, like, that's the the only thing that would really stop me from it. I and or I guess, like, the idea that we might release Nuxt 4 and then have to release Nuxt 5 the next month. Mhmm.
Daniel Roe:
That would be annoying. Like, that would feel like that's putting people through an amount of churn that we don't need. That would hold me back, I think. So, I mean, I would like to see a little bit of air gap between the release of Nuxt 4 and 5.
Alexander Lichter:
Absolutely. Yeah.
Daniel Roe:
And that's why it's hindsight is always better in this kind of case. Like if you go back and tell me in June of last year that it's gonna be a solid 10 months before the release of Nitro, then okay. I figured. Great. That that's fine.
Daniel Roe:
Like, that's enough time. But now, there's no chance it's gonna be 10 months. Right now, Nitro is gonna be out, I hope, within a month, you know.
Alexander Lichter:
So I that's why, like, right now, it's it would not make sense. So, like, hey, I'll release a major now, and then in, I don't know, February, March, April, another one. Given that, okay, Nitro comes out, breaking changes, adapting them, testing them is still a little bit of period. So we'd probably still talk about, like, 3, 4 ish months, something like that.
Daniel Roe:
Yep.
Alexander Lichter:
Depending also when the release is, of course.
Daniel Roe:
I think what we're going to see is alphas of h3, and Nitro, and I think then that's gonna start to be the time the thing is I don't wanna migrate the Nuxt ecosystem where there's still a possibility of further breaking changes in Nitro.
Alexander Lichter:
For sure.
Daniel Roe:
The danger is I'm I'm basically I'm rearing to go. So the danger is, and hold me back, please, that I will start sort of migrating everything too soon. And I think because the the there might be more breaking changes coming, so let's wait. We'll wait until all the breaking changes are there. We have the Nitro release candidate.
Daniel Roe:
We, you know, experiment with the Nuxt within the Nuxt monorepo. We have a Nitro release candidate, and then it's the time, I think, to start migrating stuff to, work with a nightly version of of Nuxt and and Nitro. We get a again, we release our own release candidate, start experimenting with it, start migrating stuff to it. And that hopefully after means that if we do that well, then about a a month after the the release of Nitro, we should then be in a position to release Nuxt. That's that's what I hope.
Daniel Roe:
So that means that we're we're really, at any point, not too far away from the release of Nuxt 4. But it's it's just not totally in our own in our own hands. That's that's Absolutely.
Alexander Lichter:
I mean, that's also something that comes up this year, so we can be eager for a Nuxt four in 2025. For sure, there is no real way around that. So latest
Daniel Roe:
No way around that. Yeah.
Alexander Lichter:
June or July, latest then, then you will just release it.
Daniel Roe:
If if I I I don't like that. That's the kind of thing that would give me nightmares. Even June or July, we didn't have a Nuxt 4. Yeah.
Daniel Roe:
So, don't don't don't even suggest it. That's
Alexander Lichter:
No. No. No. That won't happen. I'm I'm just mildly joking here.
Alexander Lichter:
Talking about June, July, though.
Alexander Lichter:
So in July last year, right, 1st July, and maybe that was the day that, gave you a bit more thoughts than the 1st January because then Nuxt 2 officially became EOL.
Daniel Roe:
That was that was a big move. I mean, Nuxt 2 honestly had been seeing very little development for quite some time, but not just from my point of view, but also from people preparing PRs of, filing issues against it. I mean, probably more people filed issues than than filed PRs, but and, you know, I I I tried as much as I could to merge whatever issues, whatever PRs people did create. We went back and forth on stuff like polyfilling, crypto, MD5 hash in Webpack 4 because basically something that Webpack 4 required internally was sort of deprecated, removed from Yes. From nodes.
Daniel Roe:
It was a a problem. And we still we we polyfilled it, and then Webpack polyfilled it, but not for everybody. So we we ended up having to add back our polyfill for other webpack plugins that hadn't done the same, basically. But I mean, apart from the odd PR, you know, Nuxt 2 didn't take a lot of focus. Going back to the Nuxt 2 code base, which, you know, I was very familiar with at one point.
Daniel Roe:
Now I look back at it and I think, oh, I could never go back from the current Nuxt code base because it's sort of typed. You know, we're we're not sort of relying on classes with sort of implicit inheritance and overriding. Like, oh, yes. This is an instance of but we're over we're providing our own, method to do this. And it made it very, very difficult to debug and, and sort of update implementations.
Daniel Roe:
I know that it there's anything wrong with the code. It was great, code, but it's it's a lot easier to to maneuver around the the new Nuxt code base, which I I I love. And, also Yeah. I I was I was celebrating I was celebrating the end of life of Nuxt 2. I closed a lot of issues.
Daniel Roe:
That was also a great moment of satisfaction.
Alexander Lichter:
2. X closed closed. Yeah. I saw that in my GitHub notification, like, oh, nice. I also felt that.
Alexander Lichter:
So, yeah, I think that's great. And also with Nuxt Bridge, who, like, the the Nuxt Bridge stable release was out in January as well, so people had a lot of time to use Bridge to migrate over. That was also helpful. I mean, that Nuxt Bridge wasn't officially out. It was also the reason or, like, at least one of the reasons why the Nuxt to EOL was moved from the same date as Vues over to half year later.
Daniel Roe:
Yeah. Exactly. So, I mean I mean and, you know, it was a a fair point that people made. How can we have a Nuxt end of life if we haven't actually had a stable bridge release to to use to migrate to Nuxt 3? I mean, in in retrospect, I think bridge has was helpful to a lot of people.
Daniel Roe:
It was also not helpful to some people. Like, it really depended on their project. And it you know, that migration from 2 to 3 wasn't as seamless even with Bridge as I would have liked, and 6 months isn't necessarily a huge amount of time to complete a migration. I think certainly if people had waited until the release of Bridge to do the migration, that wouldn't have given them fully enough enough time to do so. But still, 6 months was after the end of life of you 2 was probably the right amount of time.
Daniel Roe:
Having said that, there are still people using Bridge today. And, thankfully, Bridge has a great maintainer in the form of Ryota, wattanx on on GitHub, who's is doing a great job, nursing along, adding new features even that we add in Nuxt 3. Like, porting them.
Alexander Lichter:
Yeah. That's pretty amazing.
Daniel Roe:
Yeah.
Alexander Lichter:
So a big big shout out. I think we have also both met him in, at Viewfest Japan. At least I met him, this year.
Daniel Roe:
Yeah. Me too.
Alexander Lichter:
Yeah. Perfect. So, yeah, like, definitely, it's so important that, also, all these these, let's say, project ecosystem have someone who is maintaining, driving them. And, of course, it can't always be the core team members or, like, I don't know, you, Anthony, Pooya, and so on and so on because, well, at some point, there is simply not enough time.
Daniel Roe:
Oh, absolutely. Exactly. And if we have to to wait only for a core team member to implement a feature or fix the bug, that's a pretty bad bottleneck. Like, you don't you don't want that.
Alexander Lichter:
100%.
Daniel Roe:
Nice to have nice to have a good team.
Alexander Lichter:
Yeah. Shout out to all of them. Shout out to all contributors. And if you are there contributing to an open source project in the ecosystem, and also shout out to you, and and thanks for that. Yeah.
Alexander Lichter:
And other than of course, we talked a lot of Nuxt things here. And, for everyone on the video, it gets a little bit of cat content. So if you if you listen to it, definitely check out either the the show notes later for a picture or the the video, to see Daniel's lovely, lovely cat. Hope Bali is doing well.
Daniel Roe:
She is. She wants pet petting, so she can have petting.
Alexander Lichter:
Yes.
Daniel Roe:
And at some point, she'll grow tired of it, and that will be also fine.
Alexander Lichter:
A lot of things happened in, let's say, plain Vue as well. Like, vapor mode got some improvements, but still not in beta yet, but still we we saw some some benchmarks. We saw compatibility. I think, like, the basic VitePress setup can be rendered with vapor mode now. That was, like, the latest state I remember.
Alexander Lichter:
VPress 1.0 also came out, also another thing. So for static site generation, that's another good option. Plus, if, like, that's the tool that a lot of people on the core team use to dogfood, in a way, changes like Vapor Mode or the new roll down compiler as well to to be used, try and say, like, okay. Does it work, How things look like? So it's really nice to see also there are big movements that are not like, hey.
Alexander Lichter:
There is a new Shiny release, but more like there are steps in that way.
Daniel Roe:
Yeah. I really do think that's the right way to go. It's steps to make things better rather than figuring out the the big perfect thing. And actually, it's it's not like it's incompatible with doing something big. You know, Evan did a big rewrite between Vite one and 2.
Daniel Roe:
You know, there's a big rewrite in Vue between 2 and 3. Like, you can at some improve things step by step, and then at some point realize, actually, this has taken us as far as we can go. We need to do a bigger thing. The problem is if you hold off on the step by step improvements because you're hoping to do the big rewrite. Like, that's the the problem, where you can you can end up in limbo.
Daniel Roe:
And the hope of the the sort of perfect implementation is actually holding you back from what should be something that works now. There are things that I'm very much looking for. I'm really, really, really looking forward to Vapr that can be used in Nuxt. I've played around with it a little bit. I had some issues with, server side rendering, which I'm sure are the you you know, Nuxt is a complex beast, a lot more complex in terms of what it does than VitePress, for example.
Daniel Roe:
But I I think, also, I think, Vapor, we've seen stop and start a little bit in terms of development. There's been some huge pushes forward, and then there's been, some pauses, in terms of who has been able to to spend time on it. I mean, that's the thing with, you know, open source, that time people have to devote to something isn't infinite, and it's not continuous necessarily. People have jobs. They have lives.
Daniel Roe:
They need to work on other things. And so some of these these projects, like Vapor, can have pauses. But it's, and Kevin would be another good person to to shout out, I think, here. Like, Johnson working on, Volar. Kevin's done incredible stuff, not just with, vapor, and he, by no means, is the only one working on it.
Alexander Lichter:
But also, like, Vue Macros, for example, Kevin, a lot of things, in general, in the Vue ecosystem, a lot of, Vite Vite things, right, Vite plug in Vue. So, like, he he's doing definitely a lot also, of course, on Elk as well, where you're also involved. So definitely And also there, you just mentioned it.
Alexander Lichter:
Like, yeah, if you're working open source, that's also tied to well, you have a lot of things on your plate in general, but then also the topic of funding, which means, well, if you can't pay your bills, then, of course, that means less time in open source, but actually doing something that pays the bills. So that's maybe also a good good moment to to mention that to support your the the people that's the the tools people use, that be it, FrameLog, Vue, or Nuxt, and, of course, also the underlying things.
Alexander Lichter:
Because, usually, the user facing projects like Vue or Nuxt gets a a lot of, let's say, visibility, and, a lot of people know they exist, while the sub sub sub dependencies, and we all know that xkcd about that, they probably don't. So that's also a good opportunity there to mention that. And on the other hand, there are, I think, 2 things that happened that year, that kind of helped with that.
Alexander Lichter:
Maybe not in a super, like, huge dimension, but the one thing is that the open source pledge launched, so to say. So, basically, initiatives to say, hey.
Alexander Lichter:
Companies should basically contribute a minimum of $2,000 per year per developer, and companies can join the pledge and make sure that open source can be at least somehow be financed or made sustainable. Yeah. So that's that's definitely interesting project there.
Daniel Roe:
Yeah. I think it's a really interesting project. And the the companies that are that are on it, that have you know, I I think they are really putting their money where their mouth is. So, you know, Sentry for years has talked about that commitment to open source and has tried to to do it in a programmatic way. So it's it's, you know, it's the dependencies that are actually used rather than just the ones that are known.
Daniel Roe:
There's also the lower level dependencies or and so I that has that has been a amazing thing to see. There are other companies too. I think Microsoft did a sort of airdrop of, quite a lot of Yes. True. That was interesting to see this year.
Daniel Roe:
But, you know, others like Stackblitz, for example, on the the open source pledge, have done some some amazing, sort of contributions to open source, not just and and, obviously, it varies in terms of what that contribution looks like. Sometimes it's GitHub Sponsorships, but it's also, empowering developers to work on open source full time. So think of Matias Capeletto, you know, Patak, working on open source, in Vite, employed by by Stackblitz and enabled to do that, in that way. Or other members on the Vite core team, for example, I think is an Astro maintainer. And and so that means actually that you have this plurality of companies sponsoring members of the Vite core team, which is really, really nice to see because it means it's this cross, company, project, not driven by 1, but, and that that's all those are all ways of of giving giving to open source, the explicit sponsorships and the implicit ones, I guess, by giving people's time.
Alexander Lichter:
And that's also important. Yeah. If it's not money, time is is also super helpful for triaging, contributing. And and but you also just mentioned, like, Vite as a, let's say, a multi company backed project. It's super important as it's such a central key part of of the web of the modern web development right now.
Alexander Lichter:
We also seen another company who also joined did also join the open source pledge, also newly founded regarding the ecosystem, which is void 0, so Evan's new company. Probably the listeners of the podcast heard the interview, I did have been doing, VueFest Japan. So, also, they're interesting to see that now 10 people full time work on OXC, Vitest, roll down, and so on and so on. So the whole ecosystem there to push that forward. Definitely also wasn't on my bingo card for that year, but was super exciting to see.
Daniel Roe:
No. I mean I I mean, I sort of in the ecosystem, I've I've known about the the company and things were coming, but, obviously, things have have changed a little bit, and and, obviously, you know, what is coming exactly? I think, obviously, you know, Evan has a great track record of investing in open source and doing bringing good to the, the web ecosystem. And I think you do get that feeling that out of projects he's been involved with, like Vue and Vite, come a lot of, non empire based, projects. It's not about sort of building something yourself.
Daniel Roe:
It's about collaborating and doing doing stuff with other people. And so I have, you know, every great hope for what void 0 will do and actually how that's going to continue to look. I don't yet know where void 0 is going. You know, I would I would love to be a fly on the wall. It will be exciting.
Daniel Roe:
I'm optimistic.
Alexander Lichter:
Exactly. It will be really exciting. Yeah. I also think so. And and also just seeing, okay, there there is VC money involved, obviously, but it's necessary to bring the velocity and actually have 10 people doing open source towards, like, improving the ecosystem and and getting things up and running.
Alexander Lichter:
It's definitely with Evan on top there and with the track record and with projects like Vue and Vite that show, like, okay. This works out. I'm excited about it.
Alexander Lichter:
Coming back to to Vue once again because it's the year in ReVue, and it's we're slowly going to wrap up. But before, I wonder, there are 2, minor versions in Vue, which is Vue 3.4, not really this year, December 2023, but I kinda still could count it in, and then Vue 3.5 in September.
Alexander Lichter:
So also a bit of time in between there. Do you have a favorite feature that was introduced in any of these Vue minor version where, like, hey, that's amazing. That's what we needed and we're missing out before.
Daniel Roe:
I like I like the built in useId. It solves some problems that we had in Nuxt, which we couldn't solve in Nuxt because they rely on on Vue internals. It's the closest thing we have in Vue to a React hook, by the way. Interesting. It really, really is.
Daniel Roe:
Like, in terms of how it calculates the ID, it's reliant on, like, the order in which things are running. And so it is very, very similar to React Hook, but it's it has to be. You know? Like, you have to be able to match between server and client, and it's a very, very tricky problem to solve. That, I'm I'm pretty excited.
Daniel Roe:
I'm also really excited about the hydration control that Vue offers, and we are obviously still yet to implement that in Nuxt. But we have we've had a PR for the last few miners that that we've been working on, to add that, and I'm really excited about seeing that come to Nuxt as well. That I think is is great, from the Vue point of Vue, but it's also hopefully gonna be great from the the Nuxt point of view too. So, yeah, that's pretty pretty cool.
Alexander Lichter:
100%. I I fully agree. And I think besides these two things mentioned, I was also a big fan, of course, the defined model being being stable as a macro that's that's like it makes the two way data binding so much nicer, less boilerplate, and it makes a lot of stuff sense. Of course, also, Vueo 3.4 picking up the hydration messages, improving them. I mean, I talked a lot about it.
Alexander Lichter:
I gave a talk at Vue Amsterdam about it and about hydration in general and also about the features. So it's it's really nice that it's now way more visible, especially where you have these hydration errors. So that's a big plus. And, eventually, props destructuring the RFC that became stable so we can find these structured props without losing reactivity. Yeah.
Alexander Lichter:
Good features. And, of course, like, DX improvements, like, the v bind short name, so, like, colon, my value, if you have the name in the script setup or in the script part, and it's matched, which was even up, like, I don't know, 5 years ago. And people like, it's too complex. Let's not do it. And now we have it.
Alexander Lichter:
So I remember to Vue 2 times to have the discussed, and people like, that's it's not beginner friendly enough. It's not really clear. Especially now with Volar matching that. And then we have once again the circle, and giving the the inlay hint saying, hey. This is bound to that.
Alexander Lichter:
I think it's it's a good addition.
Daniel Roe:
Yeah. I agree.
Alexander Lichter:
Alright. Then before we wrap up, I have a very quick quick fire with some spicy hot text, and then then we got it. I know your your time is rare, and we're running a little bit over time. Sorry for that. So okay.
Alexander Lichter:
First question, should Vue remove the options API? Yes or no?
Daniel Roe:
No.
Alexander Lichter:
No. Bolt dot new or v0 as they both have Vue's support?
Daniel Roe:
Bolt dot new for me.
Alexander Lichter:
Bolt dot new for you. Interesting. Have you used it?
Daniel Roe:
I have. I used it actually before it was released. I pulled a few strings of Patak, and he was like, oh, okay. Here here you go.
Alexander Lichter:
Nice.
Daniel Roe:
Show me show me what it was like. And it was it was, yeah. I think it's pretty cool. I love the fact that it can run a Nuxt environment, for example. That feels it feels really nice.
Daniel Roe:
And, obviously, it was built from the scratch to be agnostic as opposed to sort of so, anyway, I like obviously, they're both great. You know, I'm not not seeing anything against
Alexander Lichter:
Oh, no. No. Yeah. 100%. 100%.
Alexander Lichter:
Okay. Then, the last one, what is your favorite Nuxt package that's not part of the course? Like, not Nuxt slash, and not your own.
Daniel Roe:
And not one of my own, you say? Yes. Oh, terribly. How how do I use that? So I think I, one of my favorite is Nuxt OG Image.
Daniel Roe:
I think I love I just love which is obviously one of Harlan's packages. It's not even Nuxt JS. It's just NuxtOG Image. It's fully in in his own, namespace. It's it's just great.
Daniel Roe:
Obviously, it relies on technology under the hood like Satori, which are also great packages, but it just I think it gives that sort of chef's kiss to a site of being able to write your your Open Graph images in Vue, get her HMR when you're developing them. That's that's really nice. I mean, I think there are other other libraries that are amazing. You know, you could view use, for example, or I personally love Uno CSS.
Alexander Lichter:
Absolutely.
Daniel Roe:
Lots of great stuff there, but I think I'm gonna have to give it to a Nuxt.0 g image.
Alexander Lichter:
Sweet. I mean, also the the whole Nuxt SEO, let's say, the wrap up of packages got, like, also v 2, stable, and November is also another addition here.
Alexander Lichter:
So, yeah, we we see a lot of good things. There's some lots of honorable mentions we could talk about. Like, the Vue is the fastest. This is our framework out there based on benchmarks, which are, well, more or less realistic. About component libraries, Inspire UI, whatsoever, we have a lot more on the list, but let us out there know, or, like, you out there should let us know, and that makes more sense. What we missed? What is your, favorite thing about 2024?
Alexander Lichter:
And maybe the last thing is, how do you feel about the Vue ecosystem and the Nuxt.js ecosystem in 2024?
Daniel Roe:
I'm so excited about it. Thumbs up. I think one of the things that I was worried, with the release of Nuxt 3 back, almost, 2 years ago. 2 years ago. Yeah.
Daniel Roe:
I was worried because it that was because basically, we we had to sort of, there was a bit of a of of a blow to the Nuxt ecosystem. And also, I think there was a similar one in the Vue ecosystem where there was a bit of a pause in developing a Vue things. That's not what we see this year. That stuff is accelerating. I think the fact that you you mentioned a couple of UI libraries, there's so many, and, people are are actually building new stuff.
Daniel Roe:
They're adopting it, they're using these UI libraries. And why is that? That's because people are building with Vue and building with Nuxt. So there's there's a lot of usage and adoption and, I think, acceleration in the ecosystem, And that is just really exciting to see that, you know, it's bright skies ahead, I think.
Alexander Lichter:
Splendid. I mean, that's, I think that's the best last words we can have for this episode. That was, our year in ReVue, so to say. Daniel, thank you so much for joining the DejaVue podcast once again. All the links to your socials, Blue Sky, and so on so on stream all in the the show notes.
Alexander Lichter:
And, to everyone out there, check out, the newest episode if that is the newest. Otherwise, the latest episodes, they're shown us for all the links and resources. And see you on the next episode of Deja View. Goodbye, everybody.
