DejaVue

After the first part, Michael and Alex continue their conversation with the one and only Evan You, covering the future of the modern JavaScript Framework.

Starting straight with possible plans for Vue 4 to address common pain points and no ETA for the next major, exciting improvements like native CSS Scoping or removing the need for declaring props are discussed (though nothing is set on stone)!

Next, Vue 3.5 and it's current alpha version are on the list. We all look forward to the amazing features in the next minor version, including Lazy Hydration, perf improvements, easier types and also new composables like useTemplateRef.

Eventually, the State of Suspense, Vapor Mode, Volar, and Mobile App Development with Vue are addressed as well.

Enjoy the episode!

Chapters

  • (00:00) - Welcome to DejaVue!
  • (01:06) - Do you have any plans for Vue 4?
  • (02:47) - Ref Unwrapping in objects
  • (05:22) - Native CSS Scoping, Signals and Browser range
  • (07:12) - Defaulting to script setup and TypeScript
  • (11:12) - No prop declaring necessary anymore
  • (13:43) - Nothing set in stone for Vue 4
  • (14:50) - Vue 3.5 improvements
  • (15:50) - Internal type improvements
  • (16:33) - Reactive Props Destructure RFC
  • (19:31) - useId and useTemplateRef
  • (21:00) - Do we still need custom directives?
  • (22:06) - Lazy Hydration
  • (22:57) - Allowing Hydration mismatches on purpose
  • (25:10) - Custom Lazy Hydration Triggers
  • (26:18) - Vue 3.5 Alpha
  • (26:56) - State of Suspense
  • (30:17) - Vapor Mode
  • (33:44) - Performance of Vapor
  • (35:31) - Volar and the Vue VS Code Extension
  • (39:09) - Negativity towards Volar
  • (40:18) - Mobile App Development with Vue
  • (42:51) - What content would help the Vue community?
  • (51:07) - Wrapping up!

Links and Resources



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
Host
Michael Thiessen
Full-time Vue educator
Guest
Evan You
Creator of @vuejs, @vite_js, @rolldown_rs, and more
Editor
Niki Brandner
Sound Engineer

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.

Michael Thiessen:

Welcome to DejaVue.

Alexander Lichter:

Your favorite Vue podcast? You just don't know it yet. Or maybe you do because, well, we are very much on to the second half of our interview with Evan You. But who is Vue? If you haven't heard it, well, check out the last episode.

Alexander Lichter:

But, I'm Alexander Lichter. I'm a web engineering consultant, part of the Nuxt team, and also do video content around Vue, Nuxt, JavaScript, and TypeScript. And with me is the 1 and only Michael Thiesen.

Michael Thiessen:

Hey. I also do some content. I actually actually do this as my full time job educating you and everyone else about Vue and Nuxt with articles and courses and books. And, yeah, this is the second part of our conversation, which we had a great 1. So it went quite long, and so we decided to split this up into 2 sections.

Alexander Lichter:

Exactly. So as I mentioned before, check out the previous episode for the first part, but you can also jump straight away in the second part if you're into Vue 4. Yep. Spoiler alert alert and some other questions from the Q&A that we did before. So, yeah, let's, don't wait too long and jump in straight away.

Michael Thiessen:

So we've talked about Vue 1. We've talked about Vue 2, Vue 3. Do you have any plans currently for Vue 4?

Evan You:

We have some ideas floating around. Actually, I have a, like, a little list of things that might happen in Vue 4, but a lot of them will actually need proper RFCs. So they're kinda like in the phase of where, like, we need to discuss with the community to see if this is feasible. For example, 1 thing is, like, in defineProps , the way that we do casting causes a mismatch between so if you declare an optional boolean prop, its default value will be automatically casted to false instead of undefined. So it actually creates a mismatch at type level because there's no way for you to properly declare this.

Evan You:

Like, say, when you declare, like, boolean, an optional property that's of boolean type, You expect it to in typeland, its value is true, false, or undefined. But in reality, it's only true or false. It will never be undefined. So many people actually consider this a bug, but I think there are existing codes that rely on this behavior, so changing it would be a breaking change. It also, like, having to cast boolean, like, this boolean casting rule is just 1 thing that's I think it has some historical issues, like the order in the in the types you declare.

Evan You:

For example, if you declare, it can be either a string or a boolean, then the order of them affects how they're casted.

Alexander Lichter:

Oh, interesting.

Evan You:

Yeah. So a lot of these little things, we actually have to, like, have pretty intricate internal workarounds or, like, implementation details, which I think probably shouldn't exist in the 1st place. So that's 1 thing we might want to just remove. And then, ref unwrapping in objects. This is something actually creates a bunch of issues.

Evan You:

For example, so when you nest a ref inside a reactive object, right, you access it and it automatically unwraps the ref. We did it mostly for initial convenience when we expect a lot of mixed usage of reactive and refs, but that had, intended consequences, especially in type. Is because, now we have created a type called UnwrapRefsRecursively. So it's like a recursive type that tries to unwrap all the refs nested in the reactive object. Actually, that makes the return type of reactives incompatible with the original type because an original type can contain nested refs.

Evan You:

But when it becomes wrapped and reactive, all those refs are unwrapped. So now the types mismatch. This also creates issues in for example, wraps inside an array will not be unwrapped, but refs inside an object will get unwrapped. So in hindsight, this is probably a design mistake we wanted to rectify, but it's kinda tricky how to make the migration smooth because this can have implications in some pretty tricky runtime behavior stuff. But we'll try to come up with a plan to allow people to kind of narrow it down and try to find the cases where they're actually relying on this behavior.

Evan You:

I think the the easiest way is, like, we will ship a build that just have the rectified types. And you'll find a lot of errors in pipeline where you can fix. And then we'll probably have internal flag where if we detect you're accessing a nested ref in a reactive object, it will try to warn you about it, telling you, like, the value has is no longer unwrapped. It's it's giving you the raw ref back. So, definitely, this will also require an RFC.

Evan You:

We'll need to talk in-depth about the migration strategies and everything. I think overall, that would, just make things more consistent, less confusing. Like, we actually yeah. When I was writing this relevant section in the docs, I was like

Alexander Lichter:

It doesn't feel right?

Evan You:

Yeah. It feels it's very difficult to explain.

Evan You:

Yeah. And then I think in Vue 4, there's some things, like, in Vue 4, we may consider, like, raising the browser support range again, but that kind of heavily depends on timing. We may have to, like, defer it until further major version.

Evan You:

But some things we're looking for is, like, native CSS scoping

Alexander Lichter:

Oh, yeah.

Evan You:

Native signals. No. Native signals might be further down the road, but native CSS scoping is actually, I think, much closer. And if it lands in a decent amount of, like, browser range support, we can, we'll definitely, like, offer a a mode where you can opt in to say, now SFC scoped CSS will just compile to native scoped. It will generate lighter CSS, lighter HTML markup.

Evan You:

It if in a future version we're able to completely drop the current scope CSS implementation, it's also going to simplify the internals quite a lot because scope IDs are actually a pretty complex thing to handle, like, because, it's just, like, very pervasive. We have to have scope ID handling at all stages in client rendering, in service side rendering, in hydration. It's just quite annoying. So I'm looking forward to be able to just, like, move over to native scope CSS and get rid of that.

Alexander Lichter:

Well, less thing to worry.

Evan You:

Yeah. But it's mostly like kinda like a browser baseline requirement thing. It won't affect a user by anything. Right? So as I mentioned, we definitely want to focus on either it's fixing a mistake or it's something that would be technically breaking but won't really require you to do much on your end.

Alexander Lichter:

Like better defaults, for example.

Evan You:

Yeah. Yeah. I think 1 thing that might be controversial is, for example, we're thinking about defaulting script to setup mode. So, essentially, without setup, it'll be, reverse like script setup nowadays. So we're just, like, flipping it around.

Evan You:

So the other script will be like script module, which runs in module scope, and the default script is just setup. And we're also thinking about maybe, defaulting to TypeScript directly in the script as well. So, this is this is also gonna be a controversial 1. So For sure. For sure, we're gonna have an RFC for that.

Evan You:

Right? So I'm I'm actually, like, initially, I was skeptical about this too, but, Astro actually has been doing this since the very beginning. So the script part in Astro components are TypeScript by default. Kevin actually raised this as a discussion item in the vapor repo, and a lot of people didn't like it. Right?

Evan You:

But I think the, the idea behind this is, when people think about TypeScript by default, they worry about all the extra complexity that comes with TypeScript, like configuration or, like, getting the types right and all that. The thing is it all comes down to how you handle the default developer experience when you are not writing TypeScript in a TypeScript setting. Right? So if because TypeScript is synthetically a superset of JavaScript. So any JavaScript you like is actually valid TypeScript.

Evan You:

There might be type errors, but we don't have to enable like, for example, you don't have tsconfig.json. We don't have to be in strict mode. It's just gonna be the most lenient type checking as possible. Anything unamitated is gonna be any. Right?

Evan You:

So you're gonna just be, like, writing normal JavaScript. If we don't tell you, you probably won't even realize it's TypeScript by default. That's the idea. Right? So for people who are not into TypeScript, they can just keep writing the JavaScript they like, but it actually allows us to give you a bit better intellistense and type checking compared to plain JavaScript.

Evan You:

Right, so so that's 1 thing. I think the other aspect of it is people like the explicitness, like, knowing. I think the only concern that we have is people started seeing TypeScript syntax inside a plain script tag. And I'll be like, woah. What is this?

Evan You:

Right? Some people actually have we actually had this feature request in Vue Core for quite a long time, and people want this behind a feature flag or an option that you can toggle. But I think having an option in the current view 3 will be actually very confusing.

Alexander Lichter:

Right? Yeah. Definitely.

Evan You:

So but if we coupled it with a major version like Vue 4, that might make a lot more sense. It's like, oh, you're seeing TypeScript syntax in the default script. It must be Vue 4. Right? Also, you're seeing composition API in the plain script, that's Vue 4.

Evan You:

It doesn't really fundamentally change the way you would write your components. It's really just like writing less, a bit of less. Or maybe in the RFC discussion, someone will convince us, like, this is not worth it, you know. But I think overall, it's just like the like, over time, we really acknowledge how our user base kind of changed and shifts over time. Like, in the early days, probably 90%, no build step, 10% with build tools.

Evan You:

Vue 2 era, probably 50/50. Vue 3 era, probably even more build tools, more Composition API. Right? So we kinda always want to optimize framework for the most dominant use case for the to put most people on a happy path.

Alexander Lichter:

Yeah. Like the 80% solution, at least.

Evan You:

Yeah. Yeah. Yeah. So that's the main motivation.

Evan You:

And then I think 1 of the more difficult ones is we may want to eventually remove the requirements for you to always declare all the props. So right now, like, the the you can already use types to declare props in SFCs. Right? For a lot of people, that's great. But the problem is at runtime, Vue still needs to know the exact list of props this component expects in order to differentiate props from attrs or fault through attributes.

Evan You:

This actually creates a problem because now we actually built a pretty sophisticated, like, reverse compiler that parses your types and try to infer the final list of props you expect from this type. Right? We actually had to do all of that in view, and there are there are still a lot of edge cases we don't support. And it's kind of like a rabbit hole that's that's kinda endless. Like, we supported, like, probably most of the common use cases people see, but if you use, like, crazy stuff like generics, key of, index types, maps types, you know, people do crazy types, especially in component libraries.

Evan You:

Some of them, we're like, well, we probably should never be able to support this. Yep. Makes sense. You know, I guess the end all solution to this is just to remove this entire requirement of having a known list of prompts. But in that case, how do we handle fall through attributes?

Evan You:

That's something we will definitely need to discuss, right, in RFCs. And how do we provide a good migration strategy? Like, would be the I guess, the main difference is when you declare no props at all, everything's gonna be treated as props. So there will be no attribute fall throughs by default because you did not declare any props. Then in that case, how do you maybe only explicit allow the things you want let to let to fall through.

Evan You:

I don't know. Like, that's something we are we're open to discussion. It's just the thing we wanna do, but also we don't really have fully, you know, thought through what we need to do to get there yet.

Alexander Lichter:

That makes sense. And it it will probably solve lots of issues with, like I said, the complex typings or even things like conditional props that are not really possible at the moment on the type.

Evan You:

That would allow us to allow us to completely remove all this TypeScript reverse inference stuff, and reduce this whole category of bugs. But how to make this compatible with all the existing code bases, that's the most concerning part.

Evan You:

But all the things I mentioned for Vue 4, none of these are set in stones. These are just things we're thinking. Every single 1 of them will have to go through an RFC process, and it's probably not gonna happen very soon because we're right now still focusing on 3.5.

Alexander Lichter:

So so it's for aim 4, like, not not this year.

Evan You:

Definitely not this year. Definitely not

Alexander Lichter:

this year. Yeah. It's it's always good, like, not not to give a date or something. It's just like a time range. Yeah.

Evan You:

It, it's like all these breaking changes we're thinking right now are super conservative. Like, we wanna just, like, start thinking about collecting these things early and start the discussion early. So we have this process of getting feedback, prepping the community on what where we are heading, and then, finding a good timing to eventually do this.

Alexander Lichter:

Makes sense. And you already mentioned 3 3.5 and and Vapor. Yeah. So I I think these are also 2 2 very important parts the community is interested in, as in, like, what comes in Vue 3.5 and, of course, the current state of vapor mode. Feel free to choose what's what's maybe faster to discuss or what could be more interesting, and then we go for 1 and the other.

Evan You:

Yeah. Well, we'll do both. I think 3.5 right now, the the it's already in alpha state. Actually, there is an alpha version of 3.5 already. It comes with the first significant change is internal reactivity refactor take 2.

Evan You:

This time, it's mostly memory usage improvement. So it uses, like, almost 60% less memory, which is, going to be great if you have large data collections or huge applications. And then it it works a lot better when you are iterating over large reactive arrays. We optimize all these array methods individually. So, in some cases, it can be, like, 10 times faster.

Evan You:

So if you have, like, large data collections in your app, you'll probably see performance improvements in 3.0 5. And then another thing I need to pull up the list because there are

Alexander Lichter:

There's so many good things. Yeah.

Evan You:

We improved the internal defined component type. So this is a bit internal. It took a bit of effort, but, we had some big internal type improvements that also made it easier for the IDE for Volar to, more accurately infer your prop types, Especially when you when you're using define props with the type syntax, it is now able to use the verbatim types. And, in the future, we are also going to add things like if you write a comment, js.comment documentation for your props, it'll show up when you are consuming that component and, like, looking through the props. So these are the, like, quality of life improvements.

Evan You:

That's kind of kinda need to sync with Volar in a way. And then let's see.

Evan You:

Props destructure, we're stabilizing that in 3.5. I basically made a final call in the RFC trying to solicit last minute feedback. And I don't think interestingly, I don't think so it definitely has some people who don't like it, but I think the more valuable feedback come from people who've actually used it in their production apps.

Evan You:

And almost every single 1 of them have actually used it at scale in their real projects, came back with positive feedback. And they're like, we love this. The team loved this. We want to see this feature be stabilized. At the same time, there are a few people who are really skeptical.

Evan You:

They're like, we probably will never use this. So we do provide a flag for you to just disable it in your project if you don't wanna see it ever. So that is, granted props to structure. I personally love it. There are some lengthy discussions from the RFC talking about the mental overhead and pros and cons.

Evan You:

If you're interested, you can check it out.

Alexander Lichter:

But The link in the show notes, of course. Yeah.

Evan You:

Yeah. But I personally think it's a big quality of life improvement for the average use case. And, also, we're working on something in Volar to kind of sync with this change again. I think it's interesting because a lot of features we do now kind of like we try to think about how the IDE angle can improve certain features that's purely framework level, right? For example, like, when you just structure a prop, that prop is actually kind of a special variable.

Evan You:

Volar can actually know those variables and inject something like an inlay hint before it. So that when you're looking at download components somewhere, you see a variable, you you don't have to, like, go to definition. You'd know it's a reactive prop right there, so you won't ever get confused.

Alexander Lichter:

That's pretty cool. Yeah. Plus, I guess, in addition, there are probably also many people, at least I see that in quite some projects, who are already destructuring props without knowing that that loses reactivity. So probably there will also be lots of problems solved just by by bringing out 3.5 at some point.

Evan You:

Yeah. The nice thing about the the structure is if if it worked before without reactivity, it probably continue to work with reactivity, right, unless you were explicitly trying to get the initial value of the prop without ever expecting it to change. Like so the case, I think, is going to be extremely rare where you think, like, this prop will likely change, but you you only want to get the initial value. Like, I think that's just a weird use case.

Alexander Lichter:

Yeah. You also would wouldn't do it that way then if you actually explicitly want that, but

Evan You:

Yeah.

Alexander Lichter:

You never know.

Evan You:

Yeah. So,

Evan You:

other than that, we're thinking about some other things in 3.5, useId. I think Nuxt team has been asking this for a while. Then another thing called useTemplateRef, where, right now, the the way template refs work is you have to declare a normal ref, then you match that refs variable name to the ref string in the template, which I very long time felt is kind of weird. Right? So it also creates an issue because, for example, if a composable needs to work with a template ref in your templates, you have to declare that template ref in your main setup block and then feed it into the external composable.

Evan You:

So the usage is kind of annoying to some extent. So use template ref is going to be this like, you pass it a string key, and that string key matches whatever thing is in your template. And then this use template ref can be actually caught in nested composables, which means you can create a composable that is expected to work with a template ref without having to explicitly have the user created and pass it to you. It can actually create it and then return it.

Alexander Lichter:

The only thing is you have to document that the template ref is this in this name then when you use the composable. That's the only downside, I guess.

Evan You:

Yeah. Yeah. So your composable can also allow the user to customize the key.

Alexander Lichter:

That's a good point, actually. Yeah. It can pass the key in then. Yeah.

Evan You:

Yeah. So I think this would unlock a different category of composables that work with the DOM and kind of, like, serve as a replacement for directives. So incidentally, this is because when we're implementing vapor, we noticed that the directive system is actually quite a bit of an overhead in the vapor system. And, it's just, it feels like a lot of the things directives custom directives can do can be done with composables nowadays. So I guess in the future, we may also consider, like, should directive still be part of Vue?

Evan You:

But again, that's a super, super early thought, because we don't really see a lot of people that use that. And some people may prefer it, but in a way, we tend to more and more treat directives as a compiler hint rather than a runtime construct. So having more custom directives in the whole flow actually makes the template just less optimizable in many cases. That's what we discovered when we're working on vapor. So, yeah, something we're we're trying to think about.

Evan You:

And then something like SSR related improvements, lazy hydration. So the way it works is it's going to be using async components as the boundary, and when you define an async component, you can define when to trigger the load of this this component. So, you can defer the load of the component on a specific condition, like on view ports or on hover or on interaction. So only when that condition is met will the corresponding chunk for that component be actually fetched, and the hydration will only happen at that point. So it really is just like an additional option to define async component, and most of the things should, be pretty non obtrusive to the end user.

Evan You:

And then we also want to introduce something that allows you to basically explicit allow hydration mismatches in certain parts of your app. Like, for example, like, when you're dealing with dates, sometimes it's just right? Like, because your date on the server and on the client would never match. So in this case, you know you want to always override it with the client data. So in this case, you can maybe add a data attribute called, like, data allow mismatch equals, you know, prefer client.

Evan You:

And now, you know, when it comes to the hydration of this specific node view, we'll just say, okay. Let's just let the client value override whatever. Like, we basically, it'll just, like, adopt the client value in this case. But this is kind of like what we're thinking. The implementation details actually still needs a bit of work.

Evan You:

Like, we may have to restrict it only to certain types of bindings, like primitive values that can be, like, retrieved from the client. And then there could also be a value called preferred server, which means don't override it with the client rendered result. Just keep whatever the server is. So prefer server will be more tricky because it needs to adopt the already rendered value, extract it back. So we may not actually be able to implement that fully.

Evan You:

So prefer client is more straightforward.

Alexander Lichter:

That makes sense. It it it sounds a bit like, though, that, this could be used as an escape hatch for lots of things. It's like, oh, there's an hydration error. Let's just throw in and allow hydration.

Evan You:

Earlier, we kind of always have to, like, wrap it with, like, client only.

Alexander Lichter:

Mhmm.

Evan You:

But that's kind of

Evan You:

not ideal because it's, like, blank, and then it kind of amount you have to wait the whole hydration to complete, then it kind of kicks in. But if you can still render it on the server and then let the client override it or whatever, I think that's more probably a bit more flexible.

Alexander Lichter:

Also sounds a bit like more progressive in terms of, like, okay, you still have something. You don't have to define a fallback component. You can just go with the component as is and then say, hey, that value, let's skip that and choose client one. Very nice. So 3.5, lots of SSR improvements, internal internal type, improvements as well, and the the lazy hydration topic.

Alexander Lichter:

On that, do you plan on, like, custom ways of of triggering the hydration to say, like, okay, that async component stops, like, I don't know, on scroll, on interact, as you said, but, like, more defining

Evan You:

condition, like, yeah, that could definitely be a way to do that. Like, it gives you a function to call. You call that, and the the thing just happens. It's like a callback. Or you return a Promise, maybe.

Evan You:

I don't know. Like

Alexander Lichter:

That could also work.

Evan You:

It it's gonna be pretty open ended. I think a Promise would probably be nice.

Alexander Lichter:

And that also means that the JavaScript and the CSS, if it's like the scope CSS, will will only be downloaded, when the hydration kicks in.

Evan You:

CSS so CSS splitting has to do with your build setup. So I think Vite by default splits the CSS along with the async component chunk and loads them in parallel, which means yeah. So the CSS will also only be loaded when the chunks are fetched. But that's kind of like it depends on your build setup. Yep.

Alexander Lichter:

Fair.

Evan You:

Yeah.

Alexander Lichter:

Alright. Then we have the the latest and greatest news for 3.5 is the the alpha bills are already set, so people can try it. And, of course, everybody's happy for feedback. And

Evan You:

Yeah. Alpha is not feature complete yet. Some of the things we talked about is not in the alpha yet.

Alexander Lichter:

Also important to notice some people trying out be like, hey, the preferred client doesn't work yet because it's not in here. Yes. But maybe at the time while you're listening to that, maybe 3.5 is already out. Maybe you're trying the next alpha. Who knows?

Alexander Lichter:

So, definitely, give give the whole thing a shot and and try out the features that they implemented already. Yeah. And then, of course, we come to the, maybe 1 more thing before Vapor mode. like, quite some people were asking about suspense. Like, I remember when we had the, when you had to talk at the

Alexander Lichter:

Vue.js Live earlier this year, you said suspense. It's also a matter of writing RFC, stabilizing it, and it will happen probably this year.

Evan You:

Yeah. Suspense is an interesting 1 because the RFC just takes takes a long time to write. It's been draft status for a long time.

Evan You:

I think at this stage, a lot of funny thing is something just happened in the React ecosystem. I'm not sure how many of you users are aware of it, but React 19 made a very significant change about how suspense worked and didn't even, like, document it very prominently.

Evan You:

And that turns out to break a lot of assumptions in user land, like, whole the whole React query would just, like, not work as efficiently as they want it to be with this change. So, Next.js probably also. It's just like the way that React team expected they they want suspense to work. Turns out to be misaligned with how the community has been using it.

Evan You:

So I think that's the kind of the the thing. We kept suspense view suspense in experimental status mostly because in the early days, I was like, I'm not sure if this is how we, you know, want the API to look like because there are some things like error handling and all that. But after all this time, I'm starting to feel like the basic use case is fine because we don't really see people raise very specific concerns or requests about how they want suspense to change. So that probably shows it's actually in a pretty good place. And, also, I don't think many people I think, like, for example, it's used in in Nuxt.

Evan You:

It's used in, for example, like, I think. And they've been all been just using it just fine. So I don't think we'll expect to go through, like, big API changes with suspense. It'll just likely land as none you know, disruptively as possible. It's just gonna 1 day, we're just like, oh, suspense is, isn't stable now.

Evan You:

You can finally stop seeing that experimental warning in your console.

Alexander Lichter:

Yeah. Yeah.

Michael Thiessen:

I think for me, I've been like suspense. I dug into it a while ago, but for the most part, I've just been like, it's been like an invisible feature for me that, that Nuxt uses internally. And like, I don't really think about it a whole lot.

Evan You:

Yeah.

Michael Thiessen:

And I think that's that's a great way of having it.

Evan You:

Yeah. I think suspense, we were unsure about it when we implemented it because it it's it cut across a lot of different areas, like, keep alive, transition, especially, suspension transition is very tricky. We had a lot we fixed a lot of suspense related bugs over time. I think that's Kinda ports. Like yeah.

Evan You:

Yeah. Exactly. Yeah. So it's like we kinda want we kinda put it in the experiment because we know there are bugs. Like, we want to take the time to fix all those bugs before we can comfortably say it's stable.

Alexander Lichter:

That totally makes sense. Yeah. And, I think the the other big 1, we already mentioned it, is vapor mode.

Alexander Lichter:

So what's what's the current state on vapor mode? We know the repository is open source for a while.

Alexander Lichter:

We have a playground.

Alexander Lichter:

So how is it, how is it going?

Evan You:

I actually just synced with Kevin yesterday.

Evan You:

So, so overall, I think so if you look at all the features, the, we're basically at a stage where we're, like, 90% done for components. And, the only thing missing from the component feature is define async component. So that's going to be the next thing. Once we've done that, then the only thing missed the only thing missing is the, built in components, so things like transition, keep alive, dispense. These are gonna be a bit difficult, but before we dive into those built in components, we want to then start to work on test coverage.

Evan You:

Actually, first, performance tuning. So we wanna do it's kinda like a milestone where, like, oh, components are done now. We should, like, take a look at the performance again, see if there are, like, room for optimization. When we once we've done the performance tuning, we will then do the hydration support. So because, the way Vapor works is, server side compilation of SFC will be exactly the same for normal virtual DOM components and Vapor components.

Evan You:

So both virtual DOM components and Vapor components will be able to hydrate from the same HTML output. And the early version of vapor's runtime that I built actually already have hydration handled, but as these new features were added in, some of them were added without hydration support. So now we need to basically catch up with that and make sure all these all the features implemented up to this point are hydration supported. And then next is, Kevin actually just posted a small road map. But, after that, I think it is interop.

Evan You:

Yeah. Test coverage. Yeah. Test coverage, performance tracking as hydration based in component, then building components. Before we dive into building components, though, we'll probably try to get Vapor mode running in VitePress because so once we have hydration, once we have, async component, these are the 2 key things.

Evan You:

So these are the only 2 things missing from vapor mode that allows us to just run all the components in the default theme in vPress because it's a pretty limited actually, I think, oh, the default theme probably uses transition in a few places. So we have to, like, run it without transition, But, other than that, it doesn't do anything crazily, you know, complex.

Evan You:

So, our hope is to be able to get a build of VitePress to be running entirely on vapor mode.

Evan You:

Actually, it doesn't require any change in VitePress itself. It's like we want to get vapor to a to a place where we can just, like, add the vapor attribute to all the components in the default theme, and it'll just work.

Evan You:

I think that's a good milestone that we hope to hit later this year. And once we do that, I think Vapor can be, you know, considered in beta status.

Alexander Lichter:

Sweet. Okay. So we definitely Exciting. We'll most likely see a beta later this year as soon as that milestone is hit. Yeah.

Alexander Lichter:

Amazing. Yeah. That's that's that's pretty good news. And in terms of performance tuning, do you, like, have have any, let's say, milestone and that you wanna reach there maybe compared to to Vue 3 at the moment or also to other frameworks in the JS benchmark?

Evan You:

So Kevin is actually working on that, as we speak. So, he's going to set up a continuous CI tracking on CI to basically because previously, he was basically in, the he and the Vapr team is mostly in kind of feature mode. It's like, let's get these implemented Yeah. And cover as many features as possible. And then it's like, periodically, then we go back into performance mode.

Evan You:

So it's gonna require a lot of profiling. I think because of all the feature added, the performance definitely probably regressed from the last time I benchmarked it. Last time is much faster than current Vue 3. It's, we're using JS framework benchmark as kind of the reference. So we'll see how the latest number are at, and I think there are definitely room for optimization we're gonna do.

Evan You:

So, basically, next the next few weeks, that's the focus of the vaper team. So we'll have some updated numbers probably after that.

Alexander Lichter:

Yeah. We'll also share them as soon as as soon as they're out. That's perfect. So it's it's already been over 1 and a half hours talking. We we still have a long list of questions.

Alexander Lichter:

Of of course, we won't make it for all of them. But, that that also means we would like to have you a second time on here at least, if you'd be up for that. Perfect.

Evan You:

We can do that.

Alexander Lichter:

Nice. Then maybe there there are, like, I think, 2 important ones from from the community that I've seen, like, super like, lots of people are interested in on Reddit, but also on Twitter, on on LinkedIn, and on on the YouTube comments. So Mhmm.

Alexander Lichter:

Maybe that the first 1 is is all around Volar, maybe all related around the 2.0 release, weird VS Code marketplace bug, and so on. So, basically, someone was asking, what's the the plan for addressing the, say, quote in quote instability, in Vue language tools since it's 2.0 release?

Alexander Lichter:

That's what a user was asking.

Evan You:

I actually talked to Johnson a while ago. And to be honest, like, it's it's kind of difficult in most of the the reason it's difficult is because our probably reproducing language tooling errors is kind of difficult. Like, a lot of users reporting issues to us don't know how to, like, help us reproduce it. So Johnson has literally fixed every single reproducible issue.

Evan You:

He he was like, everything that he was able to actually reproduce, he fixed them. Right? So but we still constantly hear about this and that. So I think, there was a period when 2.0 was just out. There was, like, really unfortunate timing where VS Code also shipped things on their side that just broke Volar entirely in some cases.

Evan You:

Mhmm. But, you know, that's why I posted on Twitter a while ago trying to, you know, solicit more feedback. But the thing is, Volar's problem can relate to a lot of things. It can relate to your operating system, your VS code version, your Node.js version, your Vue version, your Volar version.

Evan You:

Right? And a lot of times, people, when they are telling us showing us, like, a screenshot without any of these information, it's like we don't even know where to start. Yeah. But Johnson's trying his best. Like, if you can provide him something that is state like, strictly reproducible, he's definitely going to fix it.

Evan You:

Right? So the problem is if you run into these issues, help us with real reproductions. Give us the most precise, most detailed possible information about your environment so we know we can, like, pinpoint the real issue. Other than that, it's like, you know, we're trying our best to fix whatever we can see, but, if we cannot reproduce it, then it's going to be difficult for us to really address them. But I think some of the more disrupting problems, like, caused by upstream, VS Code, I think it has been fixed.

Evan You:

And there was also, like, a period after 2.0 because we we published the original extension and got VS Code marketplace confused. So a lot of users were actually stuck on a separate instance of the extension and never upgraded. So, like, keep hitting those bugs that might have already been fixed. I think that has been resolved in the marketplace now. And, like, personally for me, I've been using it, and it's just working well for me.

Evan You:

So I never actually experienced any of the problems people ran into. So yeah, so it it it's it's challenging because, like, when you do a big release in Vue language tools, I think it's definitely something we should, you know it's a lesson learned. Like, when we do these, like, big refactors in language tooling, which can be more difficult to predict, in terms of the the impact. We should probably be be a more bit more conservative. Like, for Vue core right now, we have, like, this every patch release before we do, we run through ecosystem CI.

Evan You:

And, yeah, it's it's just immensely helpful, like, because you can unknowingly break things. So I think at some time, we may want to, set up something some a more extensive integration test suite for language tools as well.

Evan You:

But the thing is, Johnson is, you know, he is working on open source full time, mostly through sponsorships as well. So, I think people should just give him more appreciation instead of trying to pile on on the negative reviews. It's really, really hurtful sometimes, like, we see some of the reviews just being really mean to the maintainers, and Johnson actually is going through some really, you know, big stress during those periods.

Evan You:

He was like, you know, these comments just make me don't want to work on this anymore. Right? And I don't think that's going to help anyone. The the best thing you can do is to give, you know, fully reproducible bug reports to help help us fix them. Right?

Evan You:

That helps yourself too. So, being mean to people just really doesn't help anyone.

Alexander Lichter:

100%. Totally agreed. And there's there's literally no reason to do that. Instead, just take your time instead of writing a mean review to find find a bug to reproduce it. And and also like, don't that's also what what people forget usually.

Alexander Lichter:

All these tools are out there for free to use. You don't pay anything. You don't have monthly subscription to run it. So, come on. Alright.

Alexander Lichter:

Then the last the last big thing from the q and a, which we'll probably do today, and then maybe a personal question from the 2 of us, and then then that's that. Maybe the longest the longest interview ever. The longest conversation here. Yeah. So lots of people were wondering, especially in in other frameworks ecosystem like React with React Native and Expo and so on, how is, let's say, the native mobile app story for Vue.js?

Evan You:

Yeah. I get asked this a lot. The short answer is the Vue team really don't have the bandwidth to come up with a native solution of our own. It's just gonna it's just too much work. It's like entirely different scope to build a native rendering layer.

Evan You:

So the only thing we can do is to make Vue flexible enough to be plugged into something that can do that. For example, native script. Right? And I think I guess the problem with native script is just doesn't have big enough community, not enough references or resources you can find, but still it seems people have been built successfully building projects with it. Right?

Evan You:

And the cool thing is NativeScript actually works with Vue, works with even Svelte and Solid and other things. So, I would recommend giving it a try first. And also, if your app use case doesn't really have super advanced, you know, UI requirements, you can get by with, Ionic or, what's it called, Capacitor. Yeah. Yeah.

Evan You:

Going full native, the the I guess the problem is yeah. I think the closest option if you want truly native stuff is native script, But you'll you definitely still need to have a certain level of expertise of actual native development to be able to handle something like that, even for React Native, that's the case. Right? It's the only upside is you can reuse a lot of your framework specific knowledge in those cases, but it doesn't mean you can't just, like, build a native rendering app without any native knowledge. If you want with that, you should probably go with the capacitor because that's truly web.

Evan You:

Anything that looks like web but renders to native, it's native underneath, and you need to understand how it works.

Alexander Lichter:

That makes sense. And so TLDR, basically, native scripts, give it a try if you need, like, actual native features. And if you basically need a web app running in a mobile app container, the capacitor is is a good way to go. Yeah. Makes sense.

Alexander Lichter:

Thanks a lot for that.

Michael Thiessen:

So this last question here is, 1 from, from the community as well as something that I wanted to ask you. So we'll, we'll do this as the last 1 here. So I do lots of content creation. So does Alex. And so I was wondering, what would you like to see content creators do more of?

Michael Thiessen:

And what ways do you see content as helping the Vue Vue ecosystem as a whole? That's maybe Mhmm. A big question. You can just pick 1 part from that to answer it if you want.

Evan You:

Sure. Yeah. I think it's it's fun to have more people just livestream building Vue apps. You know?

Evan You:

You see, Adam Wathan does that a lot for Tailwind. Like, he would do a stream and, like, let's span out this design 20 minutes, and he would just, like, use Tailwind CSS and just quickly build that really, really fast. I think that's a really, really good way to showcase how a tool he created, how productive he can be with it. And I think seeing someone working on from 0 to a Vue app, kind of like especially if, like, you can getting the flow while you're doing that, like, I think people will naturally realize how cool that is. Doesn't have to be a big, you know, complex app because I think it will be pretty hard for viewers to get halfway into it.

Evan You:

You're, like, already digging into some really specific things, like and I I mean small things, like like a Sudoku game or a Todo MVC. Maybe something that's slightly more complex than Todo MVC. You know? Or, like, I think a miniseries could be like, let's replicate all the official view examples from ground 0. Like, don't look at the solution.

Evan You:

Let's try to build them ourselves. How will we build it then compare notes with the official implementation? You know, something like that will be interesting. It also complements the official documentation in a way.

Alexander Lichter:

Good idea. So you would say, like, more, let's say, live examples could be could be really helpful just to showcase the the power of the framework and, like, how how you'd write or, like, how you would start writing.

Evan You:

I think there are enough abstract discussions on, like, why you should use this, why you should use that, you know, like a coding style and all that. I think what I, you know, what I don't see often enough is just, like, people showcasing how happy and productive they are with actually when they're actually using Vue. You know? Like, if I had more time, I would do this myself. I think it's gonna be pretty fun.

Evan You:

And actually, Anthony Fu, actually, I think does that on, occasionally. I think Kevin also did that on the Chinese streaming platforms Mhmm. When he was working on Vapor. So, some some stuff like that is cool.

Alexander Lichter:

Yeah. Anthony is Anthony has great content. Same, like, for Daniel's streaming. He's also often, like, maintaining, like, streaming maintenance work, but also, like, building things with Nuxt as well. So that's, that's always lovely to see.

Alexander Lichter:

Also links, of course, to channels as usual in the show notes or description.

Evan You:

At 1 point, like, there are a

Evan You:

lot of things I feel like, you know, could be a bit more fun, I guess, for the users. Like, in general, like, I feel like we have a lot of content that's focused on teaching you how to do stuff. But there's probably not a lot of like, just sort of an ongoing theme that everyone's just happy to follow along every week. It's not necessary because they want to, like, learn something to get a job, but because this is I feel like, you know, this podcast is 1 example where, like, people can follow along. Like, every week there's gonna be something.

Evan You:

For video content, it's the same. It's like every week we can find some interesting topic. I guess that falls into content creator territory, which I am myself not an expert in. But I think there's a balance between being intentionally controversial. I think a lot of YouTubers fall into that trap of trying to come up with crazy stuff, crazy thumbnails, and Yeah.

Evan You:

Create controversial for no reason. But at the same time, like, I feel the Vue community is a bit too, I guess, serious sometimes. It's like, we could have some more lighthearted stuff where, just keep people more engaged.

Michael Thiessen:

So focusing on on entertainment more than just, like, straight education. Keep things Yeah.

Evan You:

Like, make some memes. You know? Yeah. Friendly memes could be fun. Yeah.

Evan You:

Yeah. I feel like HTMX has been really, really successful with their meme marketing.

Alexander Lichter:

For sure. Yeah. They did really good on that.

Evan You:

Yeah. But this also takes talent. It's like some people are just naturally good with coming up with, like, viral memes.

Alexander Lichter:

That's true. Yeah. Talent and and time as well. Like, it's it's not easy to create good content, of of course. It's,

Evan You:

Yeah. Yeah. Definitely. Yeah.

Alexander Lichter:

That's the other thing. But yeah. And would you say the amount of content in the Vue ecosystem is, like, on a good level? Could be more, too much? Do you have a feeling for that?

Evan You:

I think there's there's a decent amount, but, honestly, I haven't watched all the content out there. That's that's actually a lot. Right? So for me personally, it's like there's a part that's more a bit more entertaining oriented that's mostly for community engagement, trying to, you know, attract people and keep them feel like they are part of a community that's just having fun on the same topic. And then there's a part where it's, like, more advanced, like how to write a good composable.

Evan You:

Right? Like, I feel like some of the Alex's content touches upon that. I think yeah. Like, that line of content is also good because I feel like not enough people talk about that. Or not enough people talk about it in a very digestible way, I guess.

Evan You:

You know, quality also really matters. So even if it's the same topic, you know, explained by different people can have different effects. So sometimes it's actually nice to have different takes on the same topic, from different perspectives, you know. I guess, like, I just I myself don't watch enough of the content because most of the time, I see this I see the description, see the thumbnail. I'm like, okay.

Evan You:

I I know what this is probably talking about. You know, I don't I don't really spend the full 20 minutes watching the whole thing through. So I'm gonna be running some cases.

Michael Thiessen:

A bit different for you because it's often just teaching things about the thing you created. And so, like

Evan You:

Yeah. Yeah.

Alexander Lichter:

Hey. I know this.

Michael Thiessen:

Probably. Yeah.

Evan You:

Yeah. It's funny because, like, on the Chinese in the Chinese view community, there's a meme talking about, like, I don't under I I don't know Vue. Like like, Evan Yu doesn't know Vue. That's the ongoing meme in the Chinese community. Because there was 1 time, someone posted a view interview question of a Chinese company.

Evan You:

And, I think I I looked at 1 of the questions, and I'm like, I don't know. And people just felt like, oh, even even you don't know how to answer this question. Probably don't know Vue that well.

Alexander Lichter:

And that that reminds me a bit of, like, oh, yeah. I look someone with 12 years of Vue experience, like, that that kind of post from, like, recruiters. Yeah. Crazy.

Evan You:

Yeah. The meme got a lot of a lot of, like, remixes. Like, people would extend with, like like, when they sometimes on social networks, there's me some 1 positive video of me, and they would be like, this guy looks really smart. I'd be willing to offer him, like, $500 a month to work for me.

Alexander Lichter:

Okay. So if if we learn at least 1 thing, more memes, folks. We need more memes.

Alexander Lichter:

Send us your best Vue.js memes, tag tag @DejaVueFM, @vuejs, Evan as well. He he will look at some of them and will laugh a lot.

Alexander Lichter:

But, yeah, I think all thanks a lot, Evan, for for coming along. There was almost 2 hours now of of q and a content around Vue mainly. We didn't even touch on the Vue part that much. Mhmm. So it's also something something for next time.

Alexander Lichter:

Yeah, to everyone who listened until here, probably in, like, small small steps or binge it all at once

Evan You:

when it comes out. Yeah. Thank you for joining. Take a look

Alexander Lichter:

at the other episodes. So, of course, there's a a big backlog or maybe when you're listening to it also some some more episodes, maybe or next 1 of Evan. Who knows? Yeah. Thanks for listening, and we are looking forward to to have you on board again, and, wish you a pleasant evening.

Alexander Lichter:

And to everybody listening, a wonderful day. Thanks, everybody.

Evan You:

Thank you.