Panel Discussion: What's the big next step for Vue/Nuxt?

So, yeah, we're going to have a few questions before the public proposes any questions or topic. The first one is, what do you think is the big next step for Vue slash next? Let's start by Daniel. What is the next step? So, well, a lot of the things that we're working on right now are about performance, both making things faster at build time and in dev time, and also thinking about what are ways we can get the compiler to make things better for you in production, because why not, right? I think that's something we always want to be on the cutting edge for. It feels like that's not a big next step, it's not a brand new thing or something like that, but I think that is something that we're really leaning hard into. I have some more bleeding edge type things as well. I think we're looking to see a lot more about WASM in the browser and also on the server, and that's going to be ever more necessary as the JavaScript build tool ecosystem goes towards native libraries, like thinking about Rust based or powered things. And so, WASM is going to be really important for deploying binaries into production. So, that's pretty cool. And I could list some other things off, but I'm sure there are others who might want to put some things in too.

True. Yeah, I also know that WASM is indeed very nice for performance. I had someone who had crazy benefits from it, so definitely a good choice.

What do you think, Maya? Yeah, I kind of agree with Daniel regarding the performance in WASM. I never tried, personally I never try to work with that at all, but I saw quite a few discussion about it. And especially the one working on that is from Microsoft, so I see it everywhere.

Okay, perfect. Eduardo, any input? Nothing to add. Sorry. Eduardo, surely you're going to say something about loaders. I feel... He tried to hold back, he tried to hold... I thought it was about WASM. I think the question is just, what's the big next step? I completely missed the question. There are a few things that I have to do in the background because of the time of the day. So, it was half funny, half another thing. Yeah, data loader is a big thing. One from my side still working on it, but it's been a few, more than a year. I mean, pretty much everything is in the talk, right? Okay. I said, I'm really sorry. Sorry for any more details. Probably watched Eduardo's talk. If not, feel free. What's for you? What's about you, Alex? Do you have any fancy projects upcoming? Any fancy project upcoming? Yeah, I mean, on top of the YouTube channel and the podcast. You spoiled them all. That's it, that's all. Give us more details as of like maybe your plans on like, pushing it forward and like how to connect the community or... Yeah, I think how to connect the community, that's a really good point. So, I think while my content on YouTube, for example, also streaming is more about like education or streaming, like just showing how I build things that I can share and maybe people are interested in that. I think the podcast is really a community thing because the goal is to have some amazing people from the open source side of Vue on their own ecosystem, but also lots of people who are users of Vue, who build amazing things with it and who maybe, I don't know, became Vue consultants or team leads or CTOs or startups, like fun startups using Vue Knox to reach their goals and explain what worked well, what didn't work well, if they would have different choices, what they wish.

And hear from people that are avid Vue enthusiasts, but don't have that voice in the community right now because they may be not that popular or they don't share the knowledge otherwise. And there are so many amazing projects out there. So, Michael, I shout out to him, who is on paternity leave right now, will come back very soon. We have some really cool guests lined up and yeah, you should definitely follow Deja Vu on that term. Yeah. I'm not sure if we can have some links on Discord or something, but yes, please. And yeah, also, I wanted to point out the fact that since you're in the Nuxt team, that's very good because you can just explain things when they're released and, yeah, explain some pain points that people might have. So, yeah, that's very good. If nobody has anything to ask to that, I guess, second question? I think I have. Okay, Maya, go for it.

Okay. I do have a question about the podcast, Alex. So, what is the target audience that you're going for? Is it also for middle, let's say, senior developer to learn about, to listen and to improve? Because I kind of find now that most podcasts, I mean, for Vue or for front end, for the web, are very much from the beginner level. In a certain phase, we have middle range developer or senior starting. It starts to become too, how do you say, too basic. But we want a little bit more focus to build more complex system and how to advance from there. So, I mean, how would the podcast stay?

That's a good point. So, our audience in general are any kind of Vue developers, developers in general that are interested in the Vue and Nuxt ecosystem. And in a way, I agree with, like, especially for beginner content, it is quite easy to produce it. You don't need crazy amount of experience. But especially for people who might have heard quite some beginner content already, it plateaus at some point. But what we want to do is we want to also give everyone listening at least something new to learn about. Maybe not in every episode, I don't think that's really possible, but at least to have also some points like, oh yeah, look, you might not read the latest release notes. Here's a feature. And not only here's a feature, you can figure it out as well, but why? Like give examples, give use cases. And with the people sharing their stories, also give inspiration and points like, oh, interesting. That person, let's say, built a cool application or a cool game with Vue. And that's possible based on these libraries or, hey, here's the author of a library that's maybe under the radar, but maybe a good alternative for what I'm looking at in my project. And also have a few shares of stories about what worked well, what didn't work well.

And also have a few shares of stories about what worked well, what didn't work well. So, the problem with podcasts is mainly that's a very complex topic. It's tricky without screen sharing, without going too in-depth and then losing the people that might not be that much into it. So, that's what I commonly do more in videos, because then you have the screen as well. So, yeah, that's tricky, but in the end, we try to cater everyone and also there, every feedback we're grateful for. And if you're like, okay, more content of that, more in-depth things, we try to facilitate everybody.

Got it. Yeah, I know quite a lot of people. I know quite a lot of people who would be very welcome to present their work with it. And also, yeah, based on the people that are doing Deja Vu, yeah, that will probably be also quite advanced if the public wants it. So, yeah, very good choice. Gentle reminder of if anybody wants to put a question regarding a specific topic, you can do so in Slido. And is this fine? Do we have anything else? Or can I go to the second question this time?

I mean, now that you're asking, Konstantin, I think to what's the next biggest step, what wasn't mentioned, and maybe it's kind of obvious, but there will be more, at least from my point of view, pun not intended, and ideas, there will be more connections with the server and the client. Because right now, still, we treat them to some degree as different entities, and we have API connections. And of course, with things like Nuxt server components, things come closer and closer together. But I also see that more and more coming. But also there, we know it won't happen in the React world, where server components will be a thing from the ground up, that's not what's planned in Vue, but having more experiments there in the meta framework.

So, Nuxt will be quite interesting to see. And also, we're going to see probably more and more of the Nuxt team, thanks to NGS. And the fact that it's used in a lot of places, also the dev tools that we have in Vue that are now used in Solid and Astro, maybe even more places. So yeah, that's definitely a good choice. Yes? Maya? Daniel? Eduardo? Any other input? All good?

Yes? Maya? Daniel? Eduardo? Any other input? All good? So, in line with what I was saying about performance, I think it's worth mentioning VaporMode in Vue. Because that's exactly the kind of performance enabled by built-time transforms that I'm talking about. I think we'll also see things like... So, Wiz and Angular merging is very interesting, because it brings into the open source arena a lot of the sort of core primitives that Google has been using with Wiz to create really interesting things. So, resumable components, sort of hydrate on demand, and that is basically going to be filtering out. So, that's something I'm looking at with great interest in terms of a Nuxt side of things. So, this is just to flesh out what was... I'm beginning to realize a little bit of a vague answer before. So, I think I would be definitely watching that space. And the good news about a lot of this is that it should just work without people needing to opt in. So, we should be able to start making use of some of these things for people and their project should just get faster and better. That's sort of the idea. I mean, I could point to specific plans we have for Nuxt, but I think the big headline is that, I would say. So, that was my final two cents.

So, that was my final two cents. Perfect, thanks. Yeah, I also saw that the Nuxt community is also willing to very focus on a lot of performance things. For example, last time I stumbled upon hydration specific things like Astro on like, hey, when do you want your app to be hydrated? When you see it, when it's in the viewport, so yeah.

Overall, I think that most frameworks now, like meta frameworks, tend to go into the same direction where they aim for the same goal. They just have different tools and ecosystems. But in the end, maybe in two or three years, everything will be crazy fast and with plenty of plugins and everything. So yeah, I mean, we already kind of have this with Nuxt, so that's very good. Yeah.

Eduardo, any input? I mean, we've been going for a long time, so there isn't really a question anymore. I don't know if you'd answer. Yeah, I mean, sure. But it's more like, do you think that on your side, you could also... I think it's the same question. Again, the future? Or is it performance? It's more like, from your point of view, do you think that you could do something groundbreaking in terms of performance? Or is it more like refining and features and anything? On my side right now, I'm not focused on performance because the team is doing a better job laying out the foundation. And I found myself reusing the foundations that work well.

Although there are places where I could improve. There are things in performance, there is an open issue, for example, that is interesting for the Vue router, which is about having a lot of routes. So this is a very edge specific case. And if you have a lot of routes, the existing matcher is not meant to be performant in that scenario. And so I initially designed the router to be able to plug in another matcher. So to say, the router is split into multiple parts, and the matcher logic handles some part of the routing. And you can pass, I mean, you cannot pass it, but the code is already prepared in order to pass a matcher. It has been like that for four years. So you pass another matcher, like a trip, you lose some of the benefits of having the RareGix-based routing, but you gain performance. So I think for these websites who need the performance, they don't need the RareGix-based routes, but they prefer the performance. And so far, I haven't had the time to implement it because I need to focus on stuff. And I'm also focusing on finances on my side. So I'm trying to balance that out. So if there is a company who is interested in that, they can definitely reach out to me and I will freelance that for them and just put it on top of my list.

Yeah, perfect. Damn, I didn't know that. You heard it here first, I think. Say what? I said, you heard it here first. This is the beginning of a bright new dawn. Let's go. Let's maybe go towards the second question that I had, which is like if you had a wish list as of today, what would you ask for in terms of Vue or Nuxt or anything related, even Vite? Yeah. And Vite. Oh, that's what I have. Only ESM. I'm having something simple for libraries. No, but... Maybe Daniel? I think there's a lot of legacy. Oh, Eduardo, sorry. Yeah, Eduardo? Yeah, sorry. I know you got it. No, no, no. I mean, that was a good start. Legacy, that's always a good topic to start with. Legacy, yeah. I mean, I think we suffered a lot. Users suffered a lot. My team suffered a lot from all the ESM required fiasco, all the typescript ESM, command.js fiasco. So, it's both a pain for maintainers and consumers because there are people consuming different ways. It's not really the part of the project you update or you care to update because, well, it's not in a library, so you don't really see too much about it. It doesn't add anything. But, for maintainers, we need to maintain multiple parts of libraries, multiple exports, multiple outputs. And it's difficult. I think, Daniel, you've seen it more because in Nuxt, you see more issues about it, right? Like, people opening word issues. It's hard to debug also for you and for them.

So, excited about Node? Absolutely. It's cool. And they're requiring ESM. Also, don't we have very nice tools nowadays that allow you to work with ESM or command.js? Like, Ben is doing that, if I'm not mistaken, where you could just dump both. I mean, at the same time, I'm not sure if it's working well, but at least it's a thing that we have. So, that's good, nice.

Daniel, since you were the first one to reply, can you pinpoint some stuff that you would like to improve regarding Nuxt? I mean, you probably have a lot. So, yeah, I have a long list of things I'd like to make better in Nuxt. So, what are some things I'd like to point out? So, multi-app support, so, module federation, or even sort of module federation lite, where you have a sort of a Nuxt app that could, say, import a single component at runtime from another app or something like that. So, like, you could have a sort of a Nuxt app as a host, and it could consume different kinds of things.

We're also already, we already have support experimentally for remote sources for server islands, server components. So, you can create and you could, for example, have one endpoint rendering components, say, for your component library or CMS. And then you could have multiple websites that consume these components. And basically, you could do that today. But again, we don't talk much about it. We haven't stabilized fully the feature set. And so, I think that's something that I'll enjoy seeing. I'm looking forward to one of the things that's coming in Vite and that we'll take advantage of in Nuxt and in Nitro, which is environment support. So, the idea, so, at the moment when you're building a Nuxt app, you're building it in an effectively, there's a dev environment. And then when you deploy it, it's deployed to Azure or Vercel or Cloudflare or some other environment.

And so, there are differences between these that can bite, come back to bite you. So, sometimes people deploy and they say, oh, something's not working for me. And we trace it down with, oh, like Azure behaves in this way. And so, but you won't know that in development, which is a pain and can be a source of bugs. So, Vite is experimenting with the idea. There's an open issue to talk about it. Having the idea of actually environments in the Vite context. So, the interesting thing about that for me is that it enables us to maybe talk about having, for example, dev environments. And Nitro is already going down this path. I think probably before Vite was, now it's difficult to tell, but Nitro is going down this route as well.

So, for example, if you're building for Cloudflare, can you access those Cloudflare primitives in development on the server? Well, yes, you can, thanks to an experimental module that Puyo created. And that's the kind of thing that I think we'd like to see rolled out more broadly. So, again, increasing the difference between dev and prod, doing that in Vite, doing that in Nuxt, doing that in Nitro, and actually having this sort of much more seamless approach, which I think, again, the fewer differences you have between development and production, the more stable and more confident you'll be when you're deploying your app.

So, for example, if you're building for Cloudflare, can you access those Cloudflare primitives in development on the server? Well, yes, you can, thanks to an experimental module that Puyo created. And that's the kind of thing that I think we'd like to see rolled out more broadly. So, again, increasing the difference between dev and prod, doing that in Vite, doing that in Nuxt, doing that in Nitro, and actually having this sort of much more seamless approach, which I think, again, the fewer differences you have between development and production, the more stable and more confident you'll be when you're deploying your app.

So, yeah. As for micro frontends, I never really worked with it. Maybe, Maya, do you know any companies that use it? Do you use it at Microsoft? Because so far, I know that most companies just do their own source. Do you maybe have any users for that?

No, I would say I don't know any group in Microsoft that is really using micro frontends, but it's a very common, it's kind of a trendy concept, I think. I mean, I heard people talking about it for a while, and I think my friend Natalia, Natalia Kim from Microsoft, also working on and promoting about micro frontend. But it's never get to me about the micro frontend. It's like the concept is nice, but it's just sometimes it doesn't click on me about micro frontend. So, I never try it out, to be honest. Though, I would like to try.

Is it web component similar to micro frontend? Come on, it's not right. It's not the same, right? No, micro frontend is more like if you have a shell and inside you have several frontends. So, that's really nice. If, for example, you have several teams, big teams working on features and you don't want to block them. So, that's very good for that case. But you need to have like kind of a general store that interlinks them together. So, that's quite a lot of complexity. And I enjoy it. It can cause a lot of, I think it can cause a lot of complexity.

Usually, most of the team are working on one product or one feature. And, you know, it's not one feature. It's one product or one project and one application. So, unless you really have to share the same component everywhere, then that may work. But again, the concept is nice but you need to see in reality where the use case is really. Like what are the underlying problems in maintaining it? So, I mean, it's not only one component because you could really bring a lot of frameworks inside of it. For example, you could have a Nuxt and inside React, Svelte, Vue, Svelte, React. So, yeah, it's like a specific use case. Maybe it makes more sense for libraries, I think. But yeah, I haven't seen something like that yet. Me neither. Maybe, Alex, maybe you saw it as a consultant somewhere? So, like, yes and no.

I've heard lots of people talking about it. I have lots of people using it. And I think I get the appeal of a certain part of micro-frontends. I get the idea of saying, we have a huge application and we have teams responsible for different parts and they should have autonomous control about how to deploy, about what to use and they shouldn't wait on other teams because then things will get delayed. They should have their own way, their own CI, their own integrations and so on, so on. So, it's really like the microservice way and the back end, but also split in the front end. I understand the idea behind it.

But as you already mentioned, and as the typical issue, micro-frontends bring another set of problems. So, it starts with, okay, performance, for example. Okay, if you have a big SPA behind authentication, maybe then it's not that important that you load, if that's the case, like 10 different frameworks in 11 different versions. If you do that, you don't have to, right? You don't have to load one different framework for a different microservice. And the other hand is then, okay, as you said, the state management, right? Communication, plus how to deal with that.

And I think, like Visionvise, if you use one framework that has pretty good support for that, that's actually saying, okay, hey, you can stitch certain apps together and you get that freedom of the deployment and the freedom of, well, choice, let's say, and the teams can work autonomously. That can be working pretty well. But I haven't come across a solution that's like, okay, yeah, that's amazingly how it would work to be. And we don't even start with server-side rendering and performance part there. I think, yeah, that opens another can of worms.

Yeah, yeah. Yeah, yeah. Just like what Alex said, microservices can work. You're cutting a bit, Maya? Could you repeat, please? Most of our project thing, it's easy to split one. Can you hear me? Yeah, could you please repeat the last 15 seconds? Yeah. So I was just saying that microservices, it can work. It really proved that it works in the backend because literally it's just about communication to the servers and you can actually have smaller servers. But the frontend is more complex than the backend because the frontend you have to deal with also user interfaces, communication with different components to different components. So yeah, it can be complex. It can be very, very hard to deal with, not careful about it. Yeah, especially if you want a seamless experience that is really smooth because if it's messy on the backend, you don't really see it. You can feel it, but on the frontend, it's more tricky. We have a few questions on Slido.

One of them is about web components. The question is like, what about web components ruling the world? So I'm not sure exactly what it means, but do you think that maybe at some point, we'll use more and more web components in general? I mean, I know that Vue is very good in terms of web components, on how you can export them and use them easily in comparison to all the frameworks. But yeah, do you think that this will be very popular or asked by a lot of people?

Daniel? Anything web components? Sorry. Sorry, Daniel. Go ahead. No problem. So I mean, web components, I feel like they've had a lot of promise. People have thought this is going to be the solution to a lot of things. So it's a way to distribute a single component in a way that works in multiple frameworks. And if you look, for example, Cal.com, they recently released some primitives, which are React components. Well, that's a shame, right? So because it means that you have to have a React app to be able to embed those components. So now we need Vue components. And web components, in a way, is addressing that. So you can write web components, compile them, and they can be used anywhere. And so Vue CLI has a great support for exporting Vue into web components and consuming them. Having said that, there are a lot of pain points around web components, including on server side rendering. And there seems to be a disconnect in some ways between the friction and difficulty of using them and the promise that is held out. Which means, right now, if you ask me, am I bullish on web components, I'm not. I think the promise, of course, is fantastic, and I would love to see that. But the reality is very different. And it doesn't take the pain away. What you can do is wrap the pain. So you can build, for example, a Nuxt module that handles it for you. And that's currently what I would recommend. So there's some great modules like Prashant, for example, and Steve are maintaining a Nuxt module for some web component library, and doing a fantastic job at sort of getting underneath the skin of the library and figuring out how to make it work properly with server side rendering. So, I mean, you can use that and not experience the pain. But pain is still there. It's just being borne by the module maintainers. So I've got nothing in principle against web components, but I just recognize that right now, they do bring a lot of pain, particularly if you want to do things like render them on server side. And I think there are also other solutions that are coming out.

So, for example, there's Mitosis, which is a solution from Builder.io, which is you code your component in a common format within exports to different frameworks. That's one option. I think Anthony at one point came up with a very experimental solution, ReactiveView, or something like that, that allowed you to directly use React in view. I'm not sure he would recommend that today. And there may be other solutions, too, to the core problem, which I think we would want to solve, which is, how do you have interoperability between frameworks and individual bits of components? But I'm not sure web components is the answer right now. But at the same time, I'm not sure there's tremendously better alternatives out there.

So, that's my take. I agree. Like, even if it's agnostic and very nice, in the end, what matters is going fast sometimes and having a nice ecosystem. So, if you need to build it always from scratch without a lot of tooling, that may be a bit annoying. And again, yeah, as you said, Mitosis is a very good alternative and very nice. Maya, do you have some exciting feedback regarding web components?

Well, whatever I want to say, Daniel already said everything. Okay. Literally, my point of view is the same with his. Okay. Next time, Konstantin, Maya should just say, because we're quite aligned, I suspect. So, she can speak for me and I'll speak for her about that. Oh, okay. That'll be interesting. Maybe you have some experience with it?

Well, you hear him. Do you maybe have some experience with web components, Maya? Yeah, well, basically, the way I work, we have a design system that we call is a Fluent UI. So, our design system has two parts. One is React components for React project, and the other one is web components for React project. The other one is web components for the rest, which if you write a project on Vue, you have to use web components. Or Angular, you also use web components. So, literally, we tend to switch to React instead of choosing Vue because using web components in Vue is not, you know, it doesn't come naturally, and the web components have a lot of issues when you start working with complexity. Also, you don't really have a lot of user experience, but more like developer experience that can help you work with web components seamlessly. That's why it's pretty hard for me to work with them.

Okay. Alex? So, to add on what was already said, I think web components, especially with regards to service rendering or SEO friendliness and so on, made a big step forward with the declarative shadow DOM that is available on all browsers by now. So, that's a cool thing. But I want to give a different angle on the whole thing. Like, I agree, promises, they might not hold up that easily. We still need a good solution for templating and state management, what other frameworks already have. But let's face it that way. Web components are right now, and there is no better alternative, if you want to stay close to the standard, right? If you write a web component now, the chance that it will still work in 10 years is pretty good.

If you open a Node project from 10 years ago, the chance that it still runs, well, given the Node version, could be, but then there may be other things. Two weeks ago, you mean? Oh, yeah, fair. Fair. So, I've been with quite some companies, so, like, okay, they want to build software that should still run in 10 years because they deploy to machines and they can't just update it every year. Or let's say, deliberately, okay, we don't want to choose a framework because we want to adhere as close to the browser standards as possible. And then web components are the best way to go in the end. No matter if you like that they're class-based, that it's lots of friction with regards to state management and templating, but if you only want to rely on the standard, that's the thing. And I also think that there will be more and more improvements, given that this is the standard and I also have the feeling that, let's say, the pain that people experience with web components, that reached also the people that are responsible for standards, for development, and so on. So, I think we'll see improvements in the future. Will we ever reach the full interoperability? Probably not, but maybe we'll get something that works and is less painful and fun to use. So, let's see where this is going. Yeah. We even have some amazing news from tc39 with a lot of proposals to maybe even have like baked-in types in vanilla JS. So, yeah, that's plenty crazy and exciting. A spicy one as well, actually. Yeah, true. Do we maybe have any input on that, Eduardo? Web components? I think web components just miss the time. It was too late to a party, in other words. The frameworks were way too established. 10 years ago would have been nice, you think? No, maybe 15. Wow. But that's not how things in the specs are way slower, because of how many things they have to handle when they do the specs. So, now it's too late. It's like, the things that are interesting are more like a middle ground, another layer of abstraction that converts things, like Mitosis, which in a way it looks similar to Wasp. So, have that language that is an abstraction to better performance, not for everything, but. So, it's interesting, right? You miss, it's like a missed opportunity in a way. But, because also it doesn't, it's too, it's too, the API is too bad compared to any other framework. Like the API in web components is just shitty. Nobody writes web components because, I mean, directly, because the API is so limited. And you write something in Svelte, in Vue, maybe Sully, I'm not sure.

But I would personally go for Vue, Svelte if I want to build a web component. Definitely not React. Of course, React feels more simple to interact with web components, because the API is more limited. They have less features than frameworks like Vue, Svelte, Sully. But then if you're used to something like Vue and Svelte, which is great, then web components feels like shit. It's like going back to 15 years ago or JavaScript, which is too much sometimes to React.

So, if you're doing web components for 15 years, that's also a good argument on the opposite side. It's like, damn, Vue, Vue.js is shit. There's too much sugar syntax. I mean, some people actually complain about that. I'm not talking about the sugar, I'm talking about features. And it's more about you have only basic stuff. You have a lot of limitations in web components, like the events and stuff. Yeah, the development experience is therefore bad. And then you have all the layers. There are so many layers nowadays, with Vite and all the dev servers, the frameworks. There's so much to catch up. There is no way you're going to have something natively that is only half as great as what you have with a framework. Just least timing. Especially with things like authentication and a lot of Nuxt modules that people want nowadays, that are solving a lot of big issues in simple manners.

Maybe as a wrap-up, because we are around five minutes, could we maybe have a quick round of the biggest successes of Nuxt so far? Or biggest lessons? I'm just merging two questions. So, if we could have 60 seconds of every one of you thinking, hey, why did Nuxt do great in the past years? Maja, first? Well, I must say what I like the most when I switch to Nuxt 3, the starting time is so much faster than before. And that's thanks to the team. And the second thing is that the structure of the project of Nuxt has become much more simpler, like simpler and easier to understand and easier to navigate also. And yeah. So, that's been the main thing, the performance of Nuxt. We start a project, to add in some features, to add a new module inside, it was much easier than before. Also, the syntax is getting much, much smoother. True. Daniel? 60 seconds.

I think one of the successes, one of them is TypeScript and our ability to tell people at the point of use, a lot of things that they didn't know before. So, everything from the middleware name to what a layout is to something like unplugged type routes from Eduardo, which tells people actually like what the valid routes are. So, I think that's a big success.

I think our biggest failure so far was the migration to version 3 and failing to release sooner and faster and keep people more up to date. The breaking changes, I think we didn't do a great job with that. True. And in a month or so, you'll have a chance to see whether we've learned our lesson. Excited for Nuxt 4. Let's go.

Eduardo, your take on this? Or from your side or from me personally? Yeah, like maybe about the migration or anything nice that happened. You're also very welcome to comment on any, like, my failures as well, Eduardo. Like, that would be... Your failure? Fine. 60 seconds to roast Daniel. Firing shots. More pushups. No, honestly, I feel like Nuxt did a great job in migration. Personally, I have a great time migrating. It's just that there are some problems that are inherent to the technology itself. The layers add complexity and debugging sometimes, migrating sometimes is hard. But it's true that it took time for Nuxt to catch up. But it's because they had... I mean, they explained everything in blog posts. So what am I repeating things? They went through Vite, Webpack, and then the unplugging refactors. There were so many improvements on Nuxt 3 that are completely invisible because they're in NGS. And so I think that's a success. Honestly, in reality, when you are aware of all these things, it's impressive, right? Failure is more on the Vue side for some of the migrations.

There were so many improvements on Nuxt 3 that are completely invisible because they're in NGS. And so I think that's a success. Honestly, in reality, when you are aware of all these things, it's impressive, right?

Failure is more on the Vue side for some of the migrations. Some of the stuff took a lot of time. I think the migration... We could have collaborated a little bit better with companies who needed some help with Vue 2. But again, I don't know if they are willing to pay. But that's a requirement at some point. Otherwise, I guess it'll be tiring not to have any support from companies who need legacy support.

Indeed. So maybe there is something there, right? It's a failure. Yeah. From our side too. Indeed, yeah. Having more companies involved would be nice. True.

What about you, Alex? Any big wins? Yeah, I'll make it quick. Big successes. We have three things. First one is more of a joke. Merch. Merch is amazing, but you can't buy it. That's unfortunate. Hope we have a merch shop one day. Fingers crossed. But for real, the biggest wins... Developer experience. And what I even value even more, and there's not much that I value more than developer experience, contribution to the whole JavaScript ecosystem. And that's a pretty big one. I mean, seeing where Andreas is going, seeing where the code is being used, and also inspiration for other framework authors and library authors as well.

Failure, well, the migration next 2 to next 3 was mentioned already, but also there, I think during that time, communication could have been way better. But that's behind us. That's the past.

And we will do much better, as Daniel said. And that's all. Yeah, perfect. So sweet conclusion on that.

And for the merch, we have the Vue.js Live T-shirt. So yeah, it's not the big merch, but still, it's a start. So thanks again for the amazing discussion. Huge applause for all the panelists. Let me put some applause. Let's go. And yeah, we're going to take a short break and come back in a few minutes. Stay there. See you soon.