Reinventing Vue: Lessons Learned with Evan You v.2
===

[00:00:00] Hi, and welcome to PodRocket, a web development podcast brought to you by LogRocket. LogRocket helps software teams improve user experience with session replay, error tracking, and product analytics. Try it free today at logrocket. com. I'm Tejas Kumar, and today we have coming back to the podcast, the inventor of Vue.

And frankly, a friend we had the privilege of meeting at RenderATL some time ago, and I'm excited to dive into this conversation with Evan Yu, who's here to talk about his talk from CityJS Singapore titled Reinventing Vue Lessons Learned. Evan, welcome back to the podcast.

Great to be here again.

It's so good to, have you. And I'm really excited to dive into your talk and the details in and around it. But before we get going, maybe we can. Give the listeners a brief overview of who you are. I believe you actually don't need any introduction, but just for the sake of posterity we can talk a little bit about who you are and what's been going on in the the universe this year.

Sure. Hi, my name is Evan Yeo. I'm an independent open source developer, primarily working on [00:01:00] two projects, Vue. js and Vite. The former is a JavaScript framework, the latter is a JavaScript build tool, and I've been a full time independent open source developer since 2016, currently based in Singapore, and yeah, that's pretty much it.

Wow. So that's Vue, and that's Vite, and that's doing all of it full time. I can't imagine how that must be. And, there's a whole bunch of rabbit holes I want to go down even just talking about what that looks like practically in terms of funding open source and so on.

But in the interest of staying on topic of your talk let's dive into that. You say the talk is about how you went from Vue 2 to Vue 3 and the lessons you learned, right? Some difficult, some not difficult, et cetera. Why do you think that's important for developers to learn from this experience?

For me, so, so there are two aspect of this one of it is for me to give an honest sort of reflection on this whole process because it hasn't been all just a Rosen. It's just uh, there are some things that we. Felt like [00:02:00] we need to talk about just to be honest with our users.

And on the other hand, I think it's valuable for people who potentially maintain their own projects, especially if you have a project with a decent user base and you're thinking about making some major updates and maybe hopefully you can learn something from this experience and avoid some of the mistakes. So that would be better off for uh, your users and better for your project and overall, just hopefully sharing this experience can, help fellow open source developers maintainers in some way.

Yeah, I, I agree with you. I think there's so much value there in providing insight around such large changes specifically because you did mention , that the change from Vue 2 to Vue 3 is so drastic. It produces a lot of changes. Some would call it even an overarching rewrite.

I'm curious if what you would say, is it considered like a ground up rewrite? Is it a bigger migration? How do you see

so, so code base wise, view itself is completely rewritten. This is actually not the first time that's [00:03:00] views been rewritten. We've done it like two times in the past. So I think this is like the third time.

it? And how does, the community respond to that, right? Because people, I feel like, would develop some affinity for the existing code base. They would learn it, , contributing to it so much. And then a rewrite happens and... what's the, what's the valence of the community around that?

Did they, do they like it? Did they like, Oh, this is new. I'm excited to learn. Or is it more Oh my gosh, again.

I think users in general care less about the code itself being raritan versus how much work they need to do to adapt to the changes. Most people only care about the letter because out of I'll be honest, like out of all the users the people who contribute, who actually have read the source code or even have developed an affinity with it are the absolute minority. So in a way obviously, there will be contributors who've worked with the old code base. I think in general, contributors are excited about rewrites because they get to see how things change, how things are [00:04:00] different. Because people who are able to actually contribute are people who are generally curious about how things work, and uh, the opportunity for them to see how a big project gets rewritten from the ground up uh, is a good learning experience. For people who are interested. So I don't think there's any sort of rewriting being, being inherently bad kind of perspective. It's mostly about managing, the parts that actually affect users like API changes or runtime behavior changes. These are definitely more more people care about the ladder.

And so what I'm hearing is in light of these rewrites, the, a lot of the developer experience, especially around the public facing APIs and performance fronts were preserved. that's fantastic. I'm curious if we could speak a little bit to the motivation behind such rewrites, especially going from something like Vue 2 to Vue 3.

How does that start? What is the genesis of, the idea of even doing a rewrite? How does that appear?

So the [00:05:00] idea you know, it's, it's not a shower thought or anything. It's mostly we've accumulated this sort of problems that we've been facing in the view two code base that we felt like it's just important to address. So. I think Vue 2's codebase being around, I think the whole idea about Vue 3 started in september 2018, and uh, around that time Vue 2's codebase, not that old, it's around 2 years old. But we are realizing that it needs to be modernized in a way. The first of all is the type system. We were using a flow back then. And we adopted flow because in the beginning phase of view two, it was a pure , JavaScript code base. There was no type checking. So, uh, later on when the project grew a bit bigger, we decided we need type checking and we were looking at. Flow versus TypeScript, and back then, the development experience was much closer than it is today.

Today, TypeScript has pretty much won, right? [00:06:00] But back then, it was still kind of a debate. Do you prefer Flow or TypeScript? Some would argue that Flow's type system was more sound compared to TypeScript's. And in a way, I think for us, one of the consideration was that flow was advertised itself being incrementally adoptable.

It's not as a one shot migration per se. So we started using flow in some of the files and gradually ported added types to Most of the code base, except for some files that contain some really dynamic logic that we felt like, Oh, if we want to add types to this part, we will have to rewrite it pretty much. I think that was the moment when I realized, okay, if we want to have a fully. typed code base, we will need to rewrite at least some of the parts from the ground up. And it was also through halfway, we realized flows overall, like the way Facebook was [00:07:00] maintaining flow to the public consumers was lackluster. So it was always like 0. I think back then it was like 0. 60 something and later on it went all the way up to 0. 120 and every release it pretty much broke something always. So for us it was a kind of painful to keep up, keep up to date with this sort of like never 1. 0 kind of status and also the IDE experience with flow was kind of lagging, starting to lag behind compared to TypeScript. And more of our users start to use TypeScript with Vue. And actually very few of them actually use Flow in their day to day work, right? So we realized, okay, our users are on TypeScript, but the codebase is on Flow. So there is a disconnect here.

In order to support the TypeScript users, we had to manually maintain the DTS file, the declaration files. So we are like writing types in the source code one time, then we manually maintain equivalent type in another place that creates a very pretty [00:08:00] serious maintenance problem is every change we make.

If we change the source code, we kind of have to keep the two distinct files in sync to make sure things work right. So that was probably the most driving factor for me to consider a rewrite because we wanted to. Just have the code base fully ported to TypeScript and then have the types being generated automatically. And obviously this alone doesn't really say this doesn't mean you absolutely have to rewrite everything, but it's one of the driving factors. And then there are other concerns like uh, V2's compiler architecture was relatively simple. In a sense it was It was intentionally simple because entirely Vue's compiler needs to fit in the browser. So we can't really do super advanced things like including, say, a Babel compilation tool chain in there and then do, Dude, like JavaScript analysis. So there was this challenge because in view templates, you [00:09:00] do, you're allowed to embed JavaScript expressions. And in order to probably process some of the expressions essentially to rewrite them so that they are accessed off this inside your component context. Uh, We had to do some pretty hacky stuff in view to So when in the browser, we are evaluating with it with a with block generated on the fly and during production, we then essentially compile the template first, then pipe it through a second step, which contains a proper javascript asd analysis to. Rewrite expressions, right? So that was hacky. It worked right. But we wanted something that's more robust in terms of the compilation pipeline, where we want to have a proper parser to AST, then we get the plugins to transform the things. These are working on the template AST level, not the JavaScript.

Then we want an opportunity to essentially hook in Babel to take over the JavaScript part. [00:10:00] But this step also needs to be. Pluggable. So, in the browser oriented build, we still will remove Babel and then do the old with block trick. but in the Node. js compiler build, we would actually import Babel as a dependency and then do the proper JavaScript expressions. So that you generate code that is CSP compliant, that is, doesn't involve any sort of Eval or with block or any sort of black magic. And this also sets up for give us more opportunities to do advanced optimizations for performance. So some of the that we do in Vue 3 to essentially generate compile time hints that will be Consumed by the virtual DOM runtime in order to skip unnecessary work. This is all. made possible because now we have this more advanced compiler architecture that allows us to do more static analysis when [00:11:00] necessary. So, so these are the two main things I think led to the rewrite and it all, it was also enough. So once we, you decide that you're going to rewrite it it also opens up a lot of ideas on how you can restructure the internals to make things better, how to make things more maintainable, I think. it's easy for developers to get excited when you're like, say, Hey, we're going to do a rewrite. Why don't we also do this and this during the rewrite and the scope just creeps beyond your initial plan. And it just grows a bit larger than it should, which is very common.

Thank you for that really well thought through response. What I got from that was, you know, just at the very beginning, you mentioned it's almost like a. Like I don't want to use this language because it's a bit woo, but it's, it sounds almost like you develop a sixth sense or a feeling for, oh, there's a lot of changes we need to make.

For example, we need to strip out the type system. We need to clean up our with block hacks, etc. And so over time you go, oh, you know what? This is probably time for a rewrite. And that then sounds like that's the genesis [00:12:00] for this prompting. And then I assume you discuss it with the core team, the community, the maintainers and go, okay, yeah, let's do it.

There's many ways I can take this, but I'm, I'm really excited in all the things you mentioned. I'm curious, just before we go a little bit further, if you could elaborate a little bit on with blocks, because it's not used at all, nor is it supported, I think, widely in JavaScript. And for those listening I suspect a few will be hearing with blocks and go what even is that?

Yeah. So in JavaScript, a width block Uh, allows you to say when you with, then , uh, assign, uh, basically dedicate, um, target an object as the context, then all the code inside the width block will implicitly be using that object as the parent scope in a way.

namespace, almost.

So imagine you are writing.

So in your normal view code, you would write this dot foo. So you are trying to access foo, this property from this, and [00:13:00] this is assigned by when we call a method, view will basically say the functions. This context will be the component instance in this case, but in your template expressions, you don't have to write this.

You just directly write foo. And Vue will evaluate it as this. foo. So how this happens is Vue essentially creates a width block on the fly with the component instance as the current context, and then evaluates the foo expression, which allows the JavaScript engine to say, okay, this foo property needs to be located on the component instance instead of the global window object, pretty much.

Wow. Yeah. Thank you for that. So there's being work done now, or rather the work is done with Vue 3 to move away from that in the tool chain that runs in the Node. js 

well, in Vue 2 and Vue 3, when you have to run the whole compiler in the browser, this trick is necessary for you to avoid having to pull in the entire Babel tool chain [00:14:00] because this is kind of a trade off between being able to ship a lean compiler that does the absolutely minimal amount of work to compile the template versus generating end The correct generating code the right, but the harder way by doing a full AST rewrite so that essentially we inject this for you at the syntax level, instead of using a runtime mechanism like with block.

So this is because in production, we see more and more people like use build tools when you use a build tool. There's no reason to rely on the width block anymore. So you'd want to get rid of that. So your code is more secure and also. For some users, you do need to remove them to first be compliant with CSP and second, with block don't actually work in ES modules because they are strict mode by default. So it's kind of a necessary thing to provide a way to generate code without the width block.

All right. And I'm glad Vue [00:15:00] 3 does that at least in, in the Node. js build side of the world. I'm curious if we can talk a little bit about the change detection or update mechanisms. Because you did mention Vue does have this virtual DOM runtime, but also there's a compiler. Compiles out template expressions.

I'm curious how this works in modern view. I, I, I, my view knowledge, I apologize, is pretty outdated. 

Sure.

React is essentially pure virtual dom. And then you have things like Velt, which is the other side of the world, which is pure compiler, and then you have things like solid that will do a little bit of both um, to some degree except solid has Novi, om it signals, et cetera.

We get into the details, but I'm curious what that means for view three. How does change detection and reactivity work in three?

Yeah, so there are two parts of this. One is how do you manage state and how do you detect state has changed? And the second part is once you detect stage has changed, how do you figure out what dom nodes should be updated? These are actually two separate concerns. So on the state part, [00:16:00] I would say view is the closest equivalent is solid. The state management part is Solid uses signals. You have refs, but they are fundamentally the same thing. In the sense that you have you have a primitive reactive primitive that holds values. And you have what we call effects not to be confused with react use effect, , these are reactive effects that during execution they will track these reactive primitives as its dependencies, right? , so for example, a components rendering is an effect that will track all the component state that's been used during its render. And whenever one of those state changes, the system will then say this component dependency has changed, so it needs to update, right? So when it goes to the update 

Sorry to, sorry to interrupt, does you also take a proxy based approach to this type of reactivity or is it a different 

So it's a mix of both. So, I don't think solid [00:17:00] necessarily needs proxy, but Vue does use proxy internally for deep observation. So we have two APIs. One is ref. Ref is the sort of um, It's a, it's a container. It's like a box that contains a value. So ref implementation by itself doesn't really need proxies, but a ref in view, reactivity is deep by default.

So let's say you take, you feed an object to ref and you access a deep property. These deep properties are made reactive automatically. And in proxies. Yes.

I say, I think like fundamentally solid and view are extremely similar in the state management part. It's just some of the higher level decisions that leads to first did like different API interfaces. And second is few is deep by default, mostly because we're carrying over this sort of. The developer experience people get used to in previous versions of Vue. It's always been like that, but we do offer a shallow version of these [00:18:00] APIs where uh, you can, say, have a shallow ref where it doesn't care about the nested properties. So you can have really deep, large data structures stored in a shallow ref, swap it out in an immutable fashion, and then only track changes at the root level.

When it's entirely replaced which is also possible. So that's the state side of things. The, so on the, onto the the rendering part, they're updating the DOM, right? So Vue 2 is much closer to pure VDOM. We have very limited compiler optimizations in Vue 2, but in Vue 3 . The base is still VDOM, but there are a lot of things that virtual DOM just kind of waste cycles on, for example, figuring out in a largely static tree where only a few things have changed. I would say, in fact, the way Vue 3 works with VDOM is very similar to something called Million. js, which is relatively new in the React ecosystem. The idea is you [00:19:00] would do a compiler pass. to look at your template or JSX and figure out, okay there's this concept called a block where I would say blocks are divided by these control flow directives, like V if or V four.

So when you have a conditional branch or you have a list, each part of a list, each section of a list is a block. Each if else branch is a block and essentially you would. So if you look at a template instead of a deeply nested tree, you would essentially flatten it to just a few nested blocks, right?

So, so that's the first thing. So within each block, the note structure is deterministic. It's static. So when you update each block, you only need to quickly compare each dynamic binding inside that block instead of walking through the whole tree. So I think interestingly the concept behind Million.

js and the way Vue 3 optimizes Virtual DOM with compiler hints is very similar but we are actually moving towards something [00:20:00] more solid in the sense that we want to generate code that doesn't really rely on Virtual DOM Which we found to be we found to be more memory efficient because in a way one of the reasons we still kept virtual DOM in Vue 3 was because we want to be compatible with a lot of component libraries or existing patterns that relies on virtual DOM people. Can actually skip the template part and manually write render functions in Vue 3 or in Vue 2 as well. So starting in Vue 2, you can skip the template compilation and write manual render functions or you can even use JSX with Vue. It's been supported since Vue 2. So there's actually A decent chunk of users using that. So in Vue 3, we decided to keep that, but at the same time we realized, Oh because , most users do use Vue through the template, probably the absolute majority. So, do have the room to say, offer [00:21:00] a different compilation mode that doesn't really need a virtual DOM. So this would result in a lighter runtime, less memory usage, better performance. The challenge would be how to keep it compatible with existing virtual DOM usage, which we believe we can do by having seamless interop between the two types of components. So you can have a virtual DOM component invoking a non virtual DOM component and vice versa. This is obviously tricky to get right, but it's important for us to, it's one of the lessons we learned during V2 to V3 is like future features. No matter how big they are, you definitely want to keep it as seamlessly adoptable as possible.

Yeah, and that's, also from just the pain of flow always being not so incrementally adoptable. I think that maybe even helps direct that. I'm curious if you could then, so it sounds to me like the place of the VDOM in view is diminishing. Ideally we move towards pure fine grained reactivity is what I'm understanding, but the VDOM [00:22:00] will still have a place for interop.

But that place will diminish. I'm curious if you think at some point in the far, far future if it's still within the realm of possibility that Vue does away with the VDOM entirely after maybe many generations. And I ask this because I had a conversation recently with Mishko Hevery from uh, Builder, and, even QUIC uses VDOM.

So QUIC also does this thing where it has signals and signals are the fundamental unit of reactivity but. It does invoke VDOM if there are structural changes to the DOM show height or dynamic components. So it's, it seems to me like VDOM is just always going to be around. So I'm curious if you could speak to that is that a reasonable prediction, or at some point we'll just do away with entirely and go solid style?

I think it's possible because I don't, I do believe it's like one of the, one of the primary reasons we keep VDOM around is mostly for the authoring experience. The fact that you can treat parts of your, your render function or your [00:23:00] JSX as an expression that you can move around, you can inspect, you can dynamically generate and put together. I think a lot of people do want that when they are authoring highly dynamic components, especially these very reusable base components and component libraries. But I don't think it necessarily has to be interpreted as virtual DOM. I think Solid is a good example. Solid actually uses JSX, but it compiles JSX into something that's not virtual DOM. So it still gives you this sort of authoring experience that allows you to treat your component view as as expressions and data, but you don't have to think of them in terms of actual objects, virtual

DOM objects at runtime.

Yeah. 

Let's talk a little bit about library authors in, in such a migration between View 2 and view 3 and in the migration between being almost purely VDOM with view 2 and moving towards these newer primitives with view 3 and also the build tooling [00:24:00] moving away from with blocks, etc.

You mentioned you, you underestimated the impact of. The libraries within the ecosystem, and you talk to a lot of developers, view developers, but not library authors. I'm curious what problems or insights that led to focusing so, so much on one side of the spectrum and maybe not as much on the library author side.

Yeah, I think it's mostly due to the way that we collected feedback. When we discussed many of the breaking changes, we just we just posted them as RFCs and then asked people to give their opinions, but we didn't. We didn't specifically seek out library authors and maintainers. So, which means we should have more proactively included them in or proactively invited them, or maybe even forced them to be in the conversation. So that they, their voice Like naturally their voices actually should carry more weight in a sense, but it was we just didn't do a good enough job to get them [00:25:00] Involved more often in those conversations. So a lot of the feedback the were given from application developers in the context of just writing day to day application code.

So a lot of the changes we think about from an application developer, they'd be like, Oh this seems manageable. Like we can also understand why it's doing that. So, and in fact, I think a lot of a lot of the smoke cases, we're probably tricky for these component libraries to migrate away from, but application developers would be like, yeah, it looks like a simple refactor. And and that's one, one aspect of it. The other aspect is mostly about private APIs. I think in view two Partly because of the early code base being in pure JavaScript. We didn't really enforce this sort of strict what is public, what is private. And we just assumed that if we didn't document it it's safe to change.

Because if we [00:26:00] didn't document it, who would figure out how to use them, right? But, that's just not what's happening in the real world. If you have... Some private things that, as long as people can find it by inspecting them in DevTools, they'll probably use it in some way. That's what I've learned, right?

That's why we've probably seen the React meme with React APIs called I'm stable. Don't use this or you'll get fired.

It's really hard to prevent people from just digging into what properties are there and decide, Oh, if this solves my problem now I'm going to use it. I don't care if it's documented or not.

yeah, I'm going to tell people on Stack Overflow to use it too. And then you have a whole snowball effect of people using these 

yeah, exactly right. Sometimes in an issue in an issue, like people have a very specific use case and they would later on leave a comment and say, Hey, I figured this out. I can use this like property that I somehow discovered. And later on when people see that issue, they start using the same thing. And it just [00:27:00] goes from there.

what's the, What's the answer to that then? Is it documentation? Is it prefixing these internal properties and methods with an underscore? What's the secret sauce to prevent people from now using or abusing these?

I think some of the things is first when you when you expect something, people will likely try to access. You can pre actively emit warnings when they do that. Basically you're going to, yeah. So, so if they access something that's just not meant to be accessed then you will have a worry like, Hey, this is an internal API.

You should avoid using it. I think if you want to go even further, you can try to direct them to a place where they can explain their use case, like what caused you to be using this and is there a, from a maintainers perspective, I need to think about, Oh, like, why are they trying to use this?

Is there. Does this mean that our public API isn't sufficient for this use case? Is there a recommended pattern for this using existing APIs, or should I? Consider creating a dedicated A P I just so that they can stop using this private [00:28:00] thing. We're still in the process of doing that in view three.

I think this is an ongoing thing because we do already have this kind of problems in view three. Like we have an internal A P I card get current instance. It's been in this kind of process. gray area for quite some time now, because some early documentation that was work in progress documented this, but later on we realized they probably should not be using it. But there are already code out there, right? So this is the lesson. Like you, if you have these APIs that probably should not be used by the users, you uh, it's probably not enough to just hide them away with an obscure name, like you'd want to. Probably uses internal symbol, something like

that. 

Yeah. I really like what you said about emitting a warning. I that's absolute gold. I'm a huge fan of anytime you get to. console log and be like, listen, just don't really also a practical takeaway for most people. I'm curious, since we're talking about [00:29:00] the people who build on the Vue.

js project as library authors, as framework authors if you could speak to Nuxt and how that looks like now versus how it was in Vue 2, has that relationship changed? What's happened there since this rewrite?

I think so next three is now well in live and it's like working really well. In fact, next three is probably also a huge, rewrite from the ground up kind of effort. It took way longer than we hoped, similar to Vue 3 itself. And I think that's a large part of that is on us for introducing a lot of breaking changes in Vue 3 and causing these meta frameworks to be extremely hard to update.

I think we, if we worked closer with Nuxt thinking about migration paths for a meta framework. It would probably result in the whole ecosystem moving a lot faster. But... On the hindsight, incremental path may not give you the same level of, [00:30:00] concrete improvement with this sort of big departure from a previous version, say Nuxt3 actually got completely re architectured in terms of how its relationship with with a build tool because of Vite, right?

Initially it was, Nux2 is like strictly Webpack and it's like very deeply tight, tightly coupled with Webpack. But Nux3 is in fact designed to be bundler agnostic in the sense it can use Webpack, it can use Vite. And it's it's runtime engine is also platform agnostic. So Nitro allows you to bundle the same application to deploy on all these different platforms like Cloud, Flatworkers Deno. Or Vercel or like plain Lambda. So, there's a lot of this fundamental re architecture that only happens when you think about things, think, oh, I'm going to just redo this whole thing, right? So it's a, it's definitely a trade off, right? There are a lot of things that's just isn't possible by incrementally [00:31:00] evolving Vue 2's code base. But at the same time, we have to pay the price, although some of the prices probably could be prevented in hindsight, it's, you always have to, there are some things you only learn after it's already happened.

Yeah, hindsight is always 20 20 as they say. While we're talking about Nuxt. And this is completely an aside and, feel free to reject the question, but I'm curious, I keep hearing, and in fact, I even spoke to Daniel maintainer of Nuxt, and we both kind of identified that Nuxt has had this notion of things like server components for a long time, since before now, server components are the biggest thing that everyone's talking about.

Why don't more people know about this? Well, I'm just really curious. Um, Nuxt seems to be carrying so much innovation, but we don't talk about it as much.

I think it's just an industry wide men mind share of react is just too big. And also, in a way it's sort of like this first mover advantage, where even [00:32:00] if you think about these newer frameworks like Solid or Svelte, their primarily user base is by attracting existing React users. So, when you look at some of the more React focused dev circles, when they talk about new frameworks, they typically only mention Svelte and Solid, but they just ignore Vue by default, because ironically Vue is, because Vue is a large enough thing, and it's also they just never, it just somehow they consider it on in a completely different camp. That they don't care about and then somehow Svelte and Solid both I think both kind of are marketed and advertised as , these new alternatives to react in a way, like Solid looks close enough with JSX and Svelte I think Vercel adopt like hiring Rich definitely also helped it. Increasing spouse mindshare towards React developers. And also, I think a big part of it is just how React. Bundled with Next. js, bundled with Vercel's great marketing [00:33:00] that's just created this really strong mindshare and and in a way, like on the view side, we just focused a lot on doing things. But we didn't, I guess we just didn't, don't have the kind of marketing budget to have a fully dedicated dev rels, like posting, posting memes or like trying to engage people every day on Twitter. In a way I wish, sometimes I'm like, Oh, maybe we should have someone do that. But on the other hand, it's I think it's just in a way from the days in the early days the front end open source space is largely. Largely not having anything to do with capital like in the early days, right? So I think with Vercel and starting you see all these newer solutions with with Svelkid being adopted being acquired by Vercel, essentially, and then. Solid Ryan is now hired by Netlify. Ryan is, is cool in the sense, I think solid is doing a really great job in very organic marketing just by being super active, [00:34:00] being super genuine and pushing out a lot of great content. But in general, you can see a lot of newer solutions are tied to a for profit. For profit company with venture backing and they have, some of them have budget for people to just constantly be on out there and pushing, talking about their stuff, which does make a difference.

I would, I must admit. And maybe we should do, in a way, I agree that we should probably do more of that on the view side. It's just we've never operated in a way to say I guess the whole vibe of view is we're not operating as a. For profit company trying to get more engagement, get more growth and aim for more users. Like more users is always nice, but like our main focus is just shipping good stuff that helps the users instead of potentially. Get a return on an investment or something. So

it's interesting. I think the landscape and the dynamics [00:35:00] of the whole front end tooling space has changed a bit with more capital being at play in some way.

I think there are good things. There are good aspect of this, there's more activity, there's more excitement. There's just overall, it's a net positive with more innovations that's going on. But on the other side, I think the way people approach the way these things are marketed and these things are being promoted has changed a bit.

yeah. No I fully agree. And I appreciate that's a really healthy take on and on the state of the ecosystem on the whole. I wasn't expecting that, but I appreciate it. In fact, the only reason I know as much as I do about Vue, which admittedly is limited severely, is by the amazing folks in the community, right?

People like Natalia Tepluina, like Debbie O'Brien, Sarah Drasner you Daniel Rowe, for example, these people, I have the privilege of hanging out with them at conferences and they tell me things like, yeah, Nuxt has had server components. It's really not that new and we love it. And I get to learn, but I [00:36:00] do think there's almost like a disproportionate.

Marketing budget somewhere in the front end world. Yeah, which I think is ultimately a disservice to developers, right? Cause like we think things are new that aren't anyway, without digressing too much I have one more. I'll be a little bit of a silly question, and then I want to shift a little bit and talk about the future of Vue with you, and then we'll wrap up there, but before the future, my silly question is I see a lot of people arguing about really useless things on Twitter, if I'm being honest, and sometimes people, or I should say X, not Twitter, but sometimes people say, oh, hey, view is a framework, not a library.

And other people go view is a library, not a framework. And there's all this like terminology debate. I'm curious from the author himself how do you define view? Is it a framework? Is it a library? What's the difference? Does it matter?

I think it doesn't matter in a way. I would say view is definitely a framework at this point. In fact, I I was gave a talk on the whole evolution of view, like in terms of how its scope grew over time. In the [00:37:00] beginning, it was definitely just the library, but like the moment we started thinking about, you Like all the other things that users need to build a full application, starting with a router, starting then a state management browser, dev tools, a CLI tool chain IDE support, TypeScript checking and everything. So when you put these things together, you've created a framework, right? These are. The scope is large, much larger than just the core library. In fact one of the reasons it took so long for us to consider Vue 3 fully ready is because the scope has grown so large over the years, we have to keep everyone everything in sync and the sheer amount of work that needs to be done to get everything ready together. Was huge. So I would say, yes, view is definitely a framework. If you look at the scope of things that we maintain it's much larger than just a chunk of JavaScript that you load into a browser. 

Yeah, which also speaks to a little bit of the the modular release schedule of Vue 3, right? You released the core, and then [00:38:00] there was like a lot of different parts that you were working on. So it wasn't just one big monolithic release, so to speak, but it was over time. And...

Yep.

There may still be parts that are y'all still working on parts or is it 

We consider it's largely complete now so everything is stable and actually we are focusing on it for, to be stable for quite, quite some time so that the whole ecosystem can sort of transition over. We're still in the process of moving over, but I think a very healthy amount of existing apps are now on Vue 3 and most new apps are created in Vue 3.

Fantastic. I want to spend the last few minutes of our chat Evan with a little bit of vision casting. You are the author of Vue. You're the lead maintainer. You're in control of the roadmap, the feature, etc. I'm curious what's coming up. What's the future of Vue look like?

So the main thing we touched upon is the the new compilation strategy that is inspired by solid. We're calling the vapor mode because it's going to [00:39:00] make the components really light and ideally reduce the cost of the abstraction cost of component instances. So. That is probably our main focus for now some, there are some smaller features that we've planned, but it's not in the sense that's going to completely change the way you write your applications, right?

That's the, in fact I would say. For at least the next year, like our focus would be on things that don't require you to rewrite anything. So things like VaporMode, these are, VaporMode is opt in, right? And the main focus is to, for a VaporMode to be a strict subset of the existing API. And that subset will work exactly the same how it works today.

So, when you're writing a VaporMode API, you shouldn't have to Ideally, you shouldn't be able to, you shouldn't want to say oh, like things work differently because I'm in a different mode. You want to be writing the same view. It's just more optimized under the hood. Similarly, [00:40:00] there will be some internal optimizations that just focused on, just improving things without the user having to actively refactor that code to get the benefits. I think that will be the short term focus. Long term wise, like we, we definitely still want to avoid this kind of view two to view three kind of situation because the, I think the ecosystem definitely suffered in terms of this long period transition period where like doing it for a very long period of time.

Some. Important dependencies are just not available. So if you were thinking about, say I'm starting a new app, there was this period of time where they're like, we are lost, like, where should I use this or that? Is it ready yet? There was a period that people got confused, but I'm glad we're out of that now.

So it's a, it's a period where we want to. Give people extended time to just build on top of you three and enjoy this new improved DX. Before we, think about what do we need to change again?[00:41:00] I don't think that's going to happen very soon.

Fantastic. I'm, I honestly, after this conversation with you, I feel motivated to go make something with Vue 3 and play with it. We didn't get, unfortunately, the chance to talk about Volar and things like this, but there's a whole ecosystem of things that start with V that I'd love to, I'd love to play with.

And and see how we go Evan, listen, it's been an absolute pleasure, man, from the beginning talking through the lessons you learned and, the nitpicks of whether it's a library and a framework and all of this really enjoyed the conversation. And it's always a pleasure having you on the podcast.

Thank you for coming.

My pleasure. My pleasure to