DejaVue

This DejaVue episode is special - Alex and Michael meet up with the creator of Vue, Vite and Rolldown, Evan You himself and talk about the last ten years of Vue!

Starting with how Vue.js started as a side project while Evan still worked at Google, Evan shares the story of how Vue.js came to be and how it evolved over the years. Interesting insights, such as why the Composition API was created and which initial problems should be solved with it, are shared in this episode. And to all that, questions from the Q&A were answered as well, touching topics like petite-vue, if and how the Options API will persist and how opinionated Vue.js is.

After an hour of content and insights, the episode ends with a tiny cliffhanger, as Part Two of the conversation covering the future of Vue, possible Vue 4 features, Vapor mode, Vue 3.5 and more, will be released next week!

Enjoy the episode!

Chapters

  • (00:00) - Welcome to DejaVue!
  • (01:09) - How did Vue.js start out?
  • (04:48) - The Initial Version of Vue.js
  • (13:42) - Do new Vue users start without a build step?
  • (15:02) - Vue's expansion to different use cases
  • (18:14) - Is Petite Vue dead?
  • (21:03) - Why Vue 2?
  • (29:58) - How opinionated is Vue?
  • (35:15) - The Transition from Vue 2 to Vue 3
  • (36:32) - How did the idea for the Composition API came up?
  • (38:24) - Options API vs Composition API
  • (44:54) - Will the Options API stick around?
  • (46:10) - Overhead of keeping APIs around
  • (51:13) - Considering to disable Options API via a flag?
  • (53:05) - The former class-based API proposal
  • (58:03) - Classes with Vue's reactivity concept
  • (59:38) - Whaat, there is a Part 2?

Links and Resources


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.

Alexander Lichter:

Hey, everybody. Welcome back to another episode of DejaVue.

Michael Thiessen:

It's your favorite Vue podcast. You just don't know it yet.

Alexander Lichter:

Exactly. And today, well, I'm here. I'm Alex. I am a Nuxt team member, also a web engineering consultant and content creator around in the Vue ecosystem. I'm here with Michael Thiessen today.

Michael Thiessen:

And I do education around Vue, full time. And that's my job doing content, courses, articles, all that, that good stuff, teaching you more about Vue as best as I can. And today we've got a special guest. We've got Evan, the creator of Vue himself.

Evan You:

Hello.

Alexander Lichter:

Hey, Evan. How are you doing? Thanks a lot for joining us, first of all.

Evan You:

Doing great.

Alexander Lichter:

Perfect. So, yeah, we're looking forward to an episode of lots of interesting questions and, of course, the big topic before the Q and A, 10 years of Vue and 4 years of Vite. First of all, amazing, like, frameworks nowadays in the JavaScript ecosystem surviving for 10 years still being actively maintained and used. That's already a great achievement. So

Evan You:

yeah. Yeah.

Alexander Lichter:

It's I mean, like, it's it's crazy, like, also how how the ecosystem has developed over the years. What what are your general thoughts about the the whole, like, progress, the whole journey? Maybe, like, let's say, we start with a little summary of, like, how how it gets started, how you started with you over to what it is now.

Evan You:

Mhmm.

Evan You:

Yeah. It's it's a very long story. Right? When I guess got started, it was mostly a side project like most things in open source. And I put it out there mostly because I felt I've spent a lot of time on this.

Evan You:

You know, it would be great if it can be useful to other people and turns out other people liked it. And we have more and more people that's liking it, so that comes with a lot of motivation and also responsibility. So it kind of pushed me to want to make it better, make it, you know, catered to what the users want. Also, just trying to think about bigger plans like what can we do single page routing, added state we started adding single page routing, added state management, added a tool chain, build tools. We added dev tool extensions, and of course along the way adding more features to core, writing more documentation.

Evan You:

So in that process, we started to have people joining the team, people who are passionate about the project as well. So, a team kind of formed very organically and, yeah. And in 2016, I decided to just do it full time. That's kind of a story of its own, but, the idea is, you know, Vue was growing beyond my expectations, really. And I realized there might be something in it that's worth pursuing.

Evan You:

And in the beginning, I had no idea how big it's gonna be. I had no idea whether even it's gonna be sustainable. I just, you know, started doing it mostly because I was quite young and had a bit of savings and for me the most important thing at that time was to be able to focus 100% on the thing I wanna do. That's really the the main reason I decided to do it full time. Right?

Evan You:

So the plan was to just keep doing it for a few months, and if it doesn't work, you know, just find another job or whatever. But turns out it worked better than I expected. The sponsorship money slowly grew to the to the extent where I can just really just work on it full time. So at that point, I was just completely full time open source and that's probably the most amazing thing ever. I still feel like, it was a risky decision, but it's probably the best decision in my life.

Evan You:

So

Alexander Lichter:

Definitely, like, a big point there. Like, may maybe to to take, like, that first part of, like, the the journey of you. You said, okay. You put it out there. You worked on it as, like, a side project, while you were still working on your day to day job back then at at Meteor, I think.

Evan You:

I started at Google, actually.

Alexander Lichter:

Started at Google even. Okay.

Evan You:

Yeah. So the first commit to Vue when it was before you even called Vue was when I was, was in 2013 when I was still working at Google. I left Google in 2014 to join Meteor, and went full time in 2016. So that's the timeline. Okay.

Alexander Lichter:

I see. And, like, you said, you you put it out there because you felt it's a it's a cool thing and, apparently, other people felt it too. Could you trace down, like, where the initial growth came from if, like, I don't know, number 1 in hacker news nowadays, like, a a big thing? So do you know what happened?

Evan You:

I think the idea is the idea of modern front end, which most of us are kinda taking for granted nowadays, is you have some reactive state. The framework is responsible for mostly 2 things. 1 is reactive state, and second is how do you declare what you want to render? And then you the framework kinda just links the 2 together to make it work automatically. Right?

Evan You:

And then aside from that, you probably also need a component model so that you can compose larger applications. These are really the 3 things modern frameworks, all modern frameworks provide. That's the the the bottom value that we see nowadays. But back then, it wasn't it wasn't that common. I think a lot of people were still, you know, using just jQuery, jQuery spaghetti everywhere.

Evan You:

And then a lot of people are using backbone, which give you some sense of structure, but it wasn't you know, it doesn't really handle the view rendering part. Like, the whole, like, wiring up your stage to your to your rendered view is, like, manual. It's completely manual, and it's madness. Mhmm. So Angular was already out. Knockout was already out there. So these are the early pioneers of AngularJS. That's version 1. Right? So these are the early pioneers of, like, I think back then, Knockout.js was still known as MVVM.

Evan You:

That's model view view model, and that's actually the initial term that Vue used to describe itself as well. So it was heavily inspired by Knockout, heavily inspired by Angular JS, and to some extent, Backbone. So I think the idea was that the way AngularJS work aligns better with what people want because, Knockout actually had something called Knockout Observable, which is not to be confused with RxJS observables, but they look almost the same as solid signals today. Mhmm.

Evan You:

So Knockout was, like, the first framework to really, like, introduce, like, something like a signal in a browser. I like the, like, the dependency tracking based reactivity that Knockout had. Right? But at the same time, I also liked the way that you can like, in AngularJS, you can just say this dot foo equals something, and things will just update. So I was like, how can I, like, implement AngularJS without the all the extra concepts?

Evan You:

Because, like, there were a lot of additional things like dependency injection, ng module. I'm not sure if it was in AngularJS, but to get started with AngularJS, you had to, like, learn a bunch of jargons that's typically, like, kind of carried over from Java, which I just I didn't know, like I think I I took, like, 1 semester of Java in college, but, like, I just hated Java. I didn't I didn't really want to dig into all those concepts. I was like, I'm just working on the front end. I want something that's as simple as possible.

Evan You:

I want to link it from a script tag with, you know, write some templates, 1 line of code, and I wanna see it become interactive. That's really like the the core experience I wanted for Vue in day 1. And when I looked into the implementation of AngularJS, it's what it was using dirty checking. So, didn't really like that. Thought it was inefficient and a bit brute force.

Evan You:

It was like it was a smart way to get around a lot of the browser engine limitations back then because I think AngularJS supported all the way back to IE 6. But I wanted something that's more feels like more elegant, which is dependency tracking, but want the same just like mutate object kind of syntax. So the the answer to that was using ES5 getters and setters to intercept all these property operations, but that required ES 5, which means, Vue started with IE9 as the bottom line support. Right? So in 2013, that was kind of, you know it's about the time where people are starting to consider dropping IE8 and below, but IE8 was still kind of a, you know, a big thing that some people are like, if you don't support IE8, I won't ever use your stuff.

Evan You:

But for me, it wasn't a problem. I'm like, I don't care about IE8. I'm just gonna use ES5. So that's, that's the initial idea. So we made the I made the initial version of Vue.

Evan You:

The whole idea is you write some very simple template syntax. You declare an object of your state, and you do a new view, and boom, you got a page running. Right? And then I think the standard steps was to replicate a bunch of commonly seen UI examples to verify that your system is actually working. So I wrote some documentation and put it out there.

Evan You:

I think it came out at the right time with the right level of, abstraction, right level of entry to barrier so that a lot of developers the early adopters, I believe, for Vue come from a background where they are not professional front end developers by trade. They are probably working on some back end applications like Rails, Laravel, or traditional back end that's already render HTML. They want some interactivity on the page. They're fed up with jQuery Spaghetti. They find Angular JS a bit difficult to get into.

Evan You:

They find React also difficult to get into probably because having to require a build tool chain to handle JSX was just a no you know, it's just a deal breaker for a lot of people back then. Right?

Alexander Lichter:

Probably still today to some degree. Right?

Evan You:

Yeah. I mean I mean, today, if you're coming still from coming up primarily back backend background, a lot of people are still prefer would still prefer a no build setup. Right? Or some of them are gravitating more towards HTMX, stuff like that. So traditionally, I think Vue just provided really nice middle ground for, for a lot of developers who not necessarily want to do heavy investment in front end engineering setup, but they need, you know, more than triple interactivity.

Evan You:

It's like something that's difficult to handle with just straight up jQuery or DOM manipulation. So that's, I think that's why really it it caught on. It allowed you to just write templates on the front end and, do interactive stuff with the lowest possible entry to barrier of entry.

Alexander Lichter:

Yeah. I think it's also still so nice that you can just straightaway start with a script tag. You don't need a build step necessary. Even just, like, to get get used to it, to just try it and learn it.

Evan You:

Exactly. So that is, that is something we've always kept all the way through up to in the view 3 today. It's like, but that has come at a cost. Like, in order to get the templates running in to be to be writeable directly in the DOM, you have to make it HTML syntax compliant.

Michael Thiessen:

Mhmm.

Evan You:

So we're restricted to syntactically valid HTML, and, there are some gotchas people kind of like the way browser handles raw HTML that you written, it would, like, format like, normalize it in in some cases, like sometimes adding tags confuse people. But it's it's funny because sometimes this ability to run directly in a browser and write your templates directly in the DOM is fundamentally what made Vue popular in the early days, so we stick to that. But for example, something like Svelte, it does not run directly in the browser. It requires a build step.

Alexander Lichter:

And need the compiler magic.

Evan You:

Yeah. Yeah. So and at the same time, so spell syntax is more detached from HTML in a way. It's like it adds all these like tags, syntax to do control flow. Its, attribute bindings doesn't have to be within quotes.

Evan You:

So, like, the most annoying part about raw HTML is, like, unquoted attributes cannot have spaces. So you cannot just you cannot use single curlies and then put arbitrary expressions in there. That's like so in the past, people have asked, like, why don't you just do JSX like binding syntax review? It's you know, it goes all the way back to how you started, how it was designed, and the, you know, this, this requirement of us to allow it to just be written directly in the DOM and compiled, is is the reason we stick to the syntax.

Alexander Lichter:

And I mean, you still allow, for example, people to use JSX if they want to with you, which is Yeah. I think not not super popular and not super well known. But if if people want to do it, especially for offering libraries, it's super useful there.

Michael Thiessen:

Yeah. Do you think that there's still a lot of people getting into Vue and just dropping in that, that script tag or is it has it shifted more to people being more comfortable with build tools and so that's less important now than it once was?

Evan You:

I would say, objectively, definitely more people are more much much more comfortable with build tools nowadays. It's much more common to assume you need a build step for your front end. It's also I would say it's less like, overall percentage of people who use you without a bill step is definitely lower compared to the early days, but the absolute amount of people that still do that is still huge. Like, we still get 1, 000, 000, 000 hits on just deliver every month. That's a lot of hits.

Michael Thiessen:

Wow. Yeah.

Evan You:

And that's just just just deliver alone. So if you consider all other forms of CDNs, so the absolute number of people who still use Vue that way is just huge.

Alexander Lichter:

That's it must be massive. Also, like, given all the applications that are written in, like, in that way using Vue and maybe maybe not even getting updated anymore, still being updated because, well, it it works. It's fine. It just maybe needs a little bit of progressive enhancement.

Evan You:

Yeah. Exactly.

Alexander Lichter:

And I also I also think in a way, like, when we as, like, the Vue community, we often take a look at typical, okay, we have single file components. We have a build step. We have all that. When we build our whole application front end in in Vue. Js or use a meta framework like Nuxt, well, sometimes we still forget, okay, there is, like, inertia.

Alexander Lichter:

Js and Vue and people just using a plain script text. So sometimes I think this is a little bit forgotten in, like, the modern quote unquote or, like, the the typical build step approach. Well, it's still super important, especially for library library authors as well to provide a way so everybody can use the the Vue plug ins libraries and so on.

Evan You:

And I just wanna add, like, in a way, if you definitely you know, we deviated from the early kind of script tag only kind of use case to expand into a much wider range of use cases. Right? So we now have, like, a full single page application, or you can do a full stack with Nuxt. We have all the things to support all that. But in a way, like, our definitely, our main user base has kinda shifted towards a more heavier front end kind of use cases.

Evan You:

So I think that actually opened up a bit of a space for even the lighter end than views today. For example, Alpine JS. Right? I call it Alpine because that's how the f 1 team is called. Some some people call it Alpine.

Evan You:

I think the French pronunciation is Alpine like Vite. So, I think Alpine is cool. Actually, uses Vue's Reactivity system under the hood, and it just, like, it just goes a bit more awing towards this, like, directly in the DOM, directly in the browser kind of approach. So it allows you to directly declare a state right in your template so you don't need to write any JavaScript at all to do a lot of things and that actually kind of fits the use case of, like, lightweight progressive enhancement even a bit better than the way view it is today. And in a way, Vue proper doesn't really provide any way for you to directly declare your state in your templates because that would just be very confusing when you mix that with your standard SFC based dev setup.

Evan You:

Right? So that's why I kinda I built a petite Vue to kinda provide the same functionality, but I feel like petite view was more like a proof of concept because, like, this is really something I've always wanted for myself in day 1, but today's Vue, our user base have shifted so much. It's just not something suitable for Vue core anymore. So I have to just, like, put it out in a separate package. But, you know, overall, the long term focus for Vue proper is just to cater to our the most dominant use case from our users today.

Evan You:

So it's good actually to see something like Alpine that covers, you know, the space that Vue has now left open. And also, going back into the server integration side, the Laravel community is a lot of people are now using LiveWire

Alexander Lichter:

Yes.

Evan You:

Inertia. Right? So I I think, you know, that space is more connected to the traditional back end developer space, whereas Vue over time kind of shifted a bit more towards, like, single page applications, talking to APIs, or full stack with Nuxt.

Alexander Lichter:

That makes sense. On that note, I have to ask a question from the q and a because it fits pretty well. Someone, on Reddit was asking, about petit view as well and was basically asking, is Petit View dead? Because it didn't get any updates for 2 years, and you, back then, also decide, okay. I'll put it out there.

Alexander Lichter:

It works. I don't accept, any, like, PRs issues and so on.

Evan You:

Yeah. So the question is what defines an open source project as dead. Right? I think it's just weird that people think if something not doesn't get updated, it's dead. Like, there are packages on NPM that works, still works really well, gets millions of downloads, but hasn't been updated in 5 years.

Evan You:

And it's a finished piece of software. Right? I prefer the term, you know, done rather than dead.

Alexander Lichter:

Maybe let's say, is it is it still maintained as in, like, would you would you say you added a hit time to, like, maybe fix bugs, like, triage issues, people raising, or just, like, it's out there. You can use it, and it's basically feature complete and done.

Evan You:

I would say I think it's done to the extent where even if I don't fix any bugs from now on, it would cover a lot of people use cases really, really well. Right? Because the intended scope for Partigee to cover is intentionally small.

Michael Thiessen:

Mhmm.

Evan You:

So if your use case falls within that, it serves your purpose, and it's good. So in terms of maintenance, there are 2 types of maintenance. 1 is you fix bugs. That is something that's objectively just not working as intended. And because the scope of petite Vue is so small, there's just very little such things.

Evan You:

I mean, I could I will probably, like, just, like, occasionally when I think of it, I'll go there and just take a look at the existing issues and see if there's any real legit bugs. I would still consider fixing them. That's, you know, that's something we can do. But I think in terms of scope, if people are coming to me and say, I want this feature in petite view. Sorry.

Evan You:

That's just not gonna happen because this is done. Like, this is the scope we wanna do. If you want anything beyond petite view, you don't have it, you can either use Alpine or you use Vue "proper".

Alexander Lichter:

Totally makes sense. Yeah. Then, I'm I'm very happy, for for that answer as well. So it's not like petite Vue is is not recommending where it's just like it's feature complete. If they are, like, actual bugs as in, like, it should be different than it's than it is right now, you You might gonna fix them at some point, but as the service is small, it's also very unlikely that lots of these bugs will happen.

Alexander Lichter:

So yeah. Good news, I would say.

Evan You:

Yeah. It's also extremely simple. I would be totally fine with someone just forking it if they have a bug they wanna fix themselves.

Alexander Lichter:

I think someone forked it even to make a, like, CSP compliant version, to make sure it, like, it all works with Conner security policies, also, like, some some time ago. So, yeah, also very fair. So, like, it's it's that narrow feature scope. You can just fork it, apply it. It's it's all good.

Alexander Lichter:

That's also a spirit of open source. Right.

Alexander Lichter:

And then going down from there, now we, I think, kind of landed in the area where where Vue 2 came out, like the the first, like, major version bump from from vue 1 back then. What made you do, breaking changes in the new major version? What's what changed compared to vue 1?

Evan You:

So, v 1, I think when we did v 1.0, from 0.x to 1.0, it was mostly stabilizing the template syntax. And the template syntax was pretty much set, since the 1.0 era. I think the only thing regarding campaign syntax that changed after 1 0 was the slots, the slots syntax. That was really the only thing. For so for 2.0, I think the main idea is because first of all, Vue 1's rendering strategy is coupled to the DOM, which means it actually for example, even if you write a string template, the thing that Vue 1 does is it will insert your whole template as inner HTML to an empty div, then grab the so then it it's initiated as real a tree of real DOM tree and then Vue will walk it, find all the directives as attributes, and then turn them into live bindings.

Evan You:

So So it's kinda like how petit Vue works. So petit Vue is very similar to how Vue 1, works, but this strategy has limitations because it's the whole idea the whole thing is, like, depending on the DOM, depending on inner HTML. Doesn't really have a proper compiler so we can't really do any advanced stuff with the with the template. It also, when you have a lot of components, the cost of creating a real DOM tree for that component and then sort of throwing away is kind of expensive in a lot of cases. So, so there are a lot of things I wanted to improve in v 1 and also like the the overall architecture of the whole thing.

Evan You:

Right? So Vue 2 is pretty much a rewrite from the ground up, compared to Vue 1, and luckily, we didn't have that many users compared to nowadays. So most of the breaking changes in Vue 2, people are like, okay, fine. Yeah. We I don't think we even had any major discussions about the things we did in Vue 2.

Evan You:

We just like, here's Vue 2. It has a bunch of changes. You probably wanna just start a new project with it. But but Vue 2 really came along together with a more proper like build tool chain. We then quickly built Vue CLI for Vue 2.

Evan You:

We started doing single file components. I'm a little blurry on when we exactly did that, but but I think Vue 2 kind of marks the transition from a primarily in browser kind of progressive enhancement type of thing to something that's more designed for heavier, single page application, server side rendering. Right? Server side rendering was also the major thing in Vue 2. So in order to support server side rendering, we actually introduced virtual DOM internally.

Evan You:

So Vue 2's compiler is a step up from Vue 1's, but it was still really, really rudimentary. It's like it's it's based on HTML parser written by John Resig. It's like a very simple HTML parser. And then, on top of it, we did really hacky implementation. It's a we call it a compiler, but it's, like, just a really simple and rudimentary.

Evan You:

So but it is able to compile a view template into a virtual DOM render function, and, that allowed us to have something more proper for the build tools and allowed us to actually have builds that's CSP compliant without a lot of overhead. Like in Vue 1, if you want a CSP based build, you actually have to include a, I think, a JS tool called s prima bundled in there. So the Vue 1 s CSP build is, like, very heavy, like Mhmm. More than twice heavy as standard view itself. So in Vue 2, we kind of finally fixed that.

Evan You:

So if you build it with a build tool chain with a build step, we're now able to also drop the runtime compiler so you have you don't have to ship the compiler to the browser. So that Vue 2 was really kind of like where we started having look more like today's framework. Right? And in fact, a lot of people still use Vue 2 even today, and it's still working pretty well for them. You can build pretty much anything you can build today with Vue 2, I would say.

Evan You:

But this kinda ties into why we did Vue 3 as there are still a lot of things today we take for granted, but that wasn't there in Vue 2.

Alexander Lichter:

So you you would say also with the Vue 2 introduction of server side rendering that the shift towards, like, the more this is, like, built for for web apps, not just, like, on top of of, like, a server rendered application already for, like, Laravel, Rails, and so on.

Evan You:

Yeah.

Alexander Lichter:

And did you did you see in terms of the community, did you also there see changes to, like, maybe attract people saying, oh, yeah. I wanted to build, I don't know, my my full front end in Angular or React, or or all the frameworks as well before and then moved over to Vue because of its, for example, single file components, its easiness to learn, and so on.

Evan You:

Yeah. I think so. I think single file components was definitely 1 thing that attracted people. Like, it's still today, like, people will have very strong initial preferences when they just see an example component. Some people see the way React works and they immediately will be like, wow.

Evan You:

Like, JSX looks terrible. Like, I prefer something that's more HTML like. But on the other hand, there will be other people who are like, well, like, JSX, awesome. It's everything in a single language component to the function, elegant. And and they look at HTML, they'd be like, wow.

Evan You:

I don't wanna write strings, like JavaScript inside HTML. What is that? You know? So, people will have very different strong opinions. I guess back in the days, before React was this dominant, people had a lot more leeway in just deciding which 1 they wanna go with.

Evan You:

Like, in a company, you can just because everything was pretty new back then so people can just I think at 1 time there were like 40 different implementations in to do MVC and picking a framework was kind of like this really, really, really difficult thing. Like, there wasn't a clear winner back then. Like, some bigger companies would go with Angular, but I think Angular 2 kinda helped with use adoption in a way because of the huge breaking changes. A lot of Angular 1 users kind of probably moved towards Vue. People back then wouldn't say I will learn React because I want a job.

Evan You:

You know? They they'll be more like, this is what I like. I'll learn this. Nowadays, unfortunately, a lot more people use something they prefer less for work because it it makes them money. It's unfortunate, but that's the way it is nowadays.

Evan You:

But I think, like, you know yeah. Like like you said, I think in the in the early days, you know, Vue 2, the way SFC works, you know, the way we have a CLI, hot module replacement, state management routing, you know, it's kinda like I think Vue 2 is also the stage where we essentially coined the term the progressive framework and we define Vue as this, like, incrementally adoptable framework compared to something more monolithic like Ember or Angular, which are intentionally monolithic, is like all or nothing. If you use Angular or Ember, you need to just give in to the way the framework is orchestrated and just, like, accept there's a way to do everything the Ember way or the Angular way. I think Vue is a bit more like because it started with this very, like, progressive enhancement base. Right?

Evan You:

So you can still use Vue core for just that. But on top of that, if you want a single page routing, you can add the router. If you want state management, you can add it. If you wanna start with the CLI, you can you can do that. So when you start with the CLI, it becomes more framework like.

Evan You:

It will guide you to set up things like Babel. It'll guide you to set up the router, unit testing, end to end testing, and all that stuff. So it becomes much more engineering and framework oriented. So we give you this whole spectrum of how much you wanna use from Vue. Right?

Evan You:

Try to cater to different use cases. I think that's a strength of Vue still today, but it also, you know, creates a lot of design constraints on what we can and cannot do. Right? So, I would say there are trade offs, but it's also what uniquely defines you in today's landscape.

Michael Thiessen:

And I I like that approach of having all of these batteries included is kind of the phrase that's often used and, like, a framework like React. 1 of the challenges that I I know people have with it is that you have to decide what state management you wanna use and what router you wanna use. I think it's maybe less, less of a, of a thing now, like you were saying, it's, you know, several years ago there were a lot, all these different options, so you could kind of pick and choose whatever you wanted. And that was kind of the fun part for people is that, oh, Hey, there's this new state management thing. I could try that.

Michael Thiessen:

I could try Redux or I could try this, whatever thing, but you had to kind of like assemble it on your own. Whereas with Vue, it's more of like the rails approach or other, like these other frameworks where there's just kind of like the standard solution and like everyone uses it. And so you don't have to, you don't have to, like, worry about, is this gonna be supported over the long term? Is this the right choice? Like how how do these things interact?

Michael Thiessen:

You just kinda like decide if you want it or not.

Evan You:

Yeah. I think we are more in between, say, React. React is on 1 end of the spectrum. It's like, before React started with server side components. So for a very, very long time, React is just like we are only a rendering library and everything else is up to the community.

Evan You:

And Angular and Ember on the other hand is we take care of everything from build tooling to data fetching all the way that touches the server. We're gonna cover all that. Right? And Vue is somewhere in between. It's like you can use Vue just as a rendering library, but you can also use Vue like a full framework.

Evan You:

But we're less opinionated than these full monolithic ones. We are a bit more opinionated than something like React. So give you a good balance. Like, to some people actually, I've heard some people who love Angular because they just love the strictness. They love having the framework guide their hand every step of the way.

Evan You:

To them, even Vue is too, like, flexible too too loose. So different people will have different preferences.

Alexander Lichter:

That's for sure. I also wonder, like, where to make the cut as in, like, okay, now we provide, like, data is the Vue router, data is state management, like, in terms of UX, of course, pinion nowadays. But for example, there is no there was never a default, like, HTTP fetching library, like, Angular had with HTTP client. What was it difficult to, like, find a good balance to, like, make sure, okay, that's what we want to include out of the box, like, as an add in, but support it straight away from the team versus that's something that's up to the community or the people using the framework?

Evan You:

Yeah. I think, fetching library is a good example because it's just not framework specific. Like, there's no nothing that requires the fetch implementation to be coupled to view in any way, because, I think 1 of the reasons Angular always had its old HTTP fashion is because it uses dirty checking. And when it does dirty checking, it needs to know when something when a data request is finished so it can force the digest cycle to run again. But Vue doesn't have that problem because when you have to finish data fetching the data, you will always set it back into some reactive state, and that will trigger the rendering.

Evan You:

So the framework knows exactly when the data efficient is finished. But in Angular land, they don't have that, so they have to kind of sort of take over. In Angular 2, they use something like zone JS that tries to, like, just intercept everything, all the async stuff, which still isn't fully bulletproof. Right? And so it has caused a lot of problems over the years, and people are still trying to get rid of it.

Evan You:

So, to review, it's like in the early days, a lot of people used Axios, but later on, there's native fetch nowadays. So right? I think that's a good decision. Now we don't have to tell people, say, hey. View HTTP is now deprecated.

Evan You:

Use fetch instead.

Alexander Lichter:

It's true. While, like, on the Angular side, okay. Like, the zone JS could do it off. We have all signals there and then, like, okay, do we really need HTTP client, or can we just use, like, normal fetch? So, like, yeah, it's a bit of the extra burden that the necessity of having a fetch library, gives them now.

Alexander Lichter:

And, and that's a, that's a good point of like, okay, we want to add framework specific things and give them, like, kind of the 1 way to go. And if there are, like, community options, sure. Why not? But, yeah, there's there's 1 big Vue router. There's 1 state management tool.

Alexander Lichter:

In a way, like, their Vue's opinionatedness, let's say, shows, but it's also good because then people don't have, like, the analysis paralysis of, like, the fatigue of choosing things like JavaScript frameworks in general.

Evan You:

Yeah.

Alexander Lichter:

So that's that's definitely a good thing. And it's also it's also nice to see that Vue 2, like, grew eventually into into all that saying, like, okay, we bring we ring VueX, we bring the router, we have concepts for that, and people could always rely on that these these things, they will work, they are maintained.

Evan You:

Mhmm.

Alexander Lichter:

So I I think also, like, the the stability of of Vue 2 was was a key part as well. The people aren't like, okay. Here's another major version we have to update now and again and again. I think that's also a big big factor.

Michael Thiessen:

So with Vue 3, you you had mentioned, Vue 2 kind of gave people some options. It wasn't super strict like angular, but it wasn't like, you know, choose your own adventure completely. And I think in Vue 3, 1 of the interesting things is that you added in the composition API, which sort of gave people choice in how to write logic, where the options API gives you is a bit more strict in how you structure things, whereas a composition API gives you more flexibility. So Yeah. How was that transition from Vue 2 to Vue 3 along with the composition API and Mhmm.

Michael Thiessen:

And all of that?

Evan You:

Yeah. I think so Vue 2 to Vue 3 Vue 2 to Vue 3

Evan You:

is definitely probably the big the most challenging and, you know, grueling process or period life experience in the whole 10 years of working with you. I think even to this day, there are still lingering just, like, arguments about options versus composition. It just takes a very, very long time, to for the community to move on. Right?

Evan You:

So kinda wanna go back to why we started the idea about composition API in the first place. Right? So 1 of the big issues in v 2 is TypeScript support isn't quite there. So options API, when it was designed, didn't really even take type inference in mind. So it wasn't really designed in a way to be easily type friendly, especially with mixings.

Evan You:

Mixings are extremely hard to type properly. So so nowadays in Vue 3, if you use options API with mixins, we can actually infer most of the stuff, which is amazing. But if you look at the types that we have to write to get mixins inferred properly, it's just, you know, it's just so much extra effort compared to Composition API where everything is just functions. It just naturally works with TypeScript, has better type inference performance. It's easier to reason about in type land, in most cases.

Evan You:

So that's 1 of the things that kind of pushed us to think about an a different API that is designed with type inference in mind. Unfortunately, we can't we can't just get rid of options API, so we have to carry along the burden of all the types that we wrote for options API. But, you know, in a way, like, we we want a new API that's just more type friendly from the get go. And also mixins mixins is like the bane of both maintainability and type inference. Right?

Evan You:

It's hard to it's hard to infer types also to users. If you use a bunch of mixins, you don't even know where these properties come from. Right? So we really wanted a API that enables better logic reuse compared to mixins and also wanted an API to allow people to have a more higher upper ceiling in how to organize your code. Right?

Evan You:

Options API forces you to group everything by type. So if we go back to, like, single file components, when it first came out, there were a bunch of people who were like, oh, you're mixing 3 different languages in a single file. Where is separation of concern? Right? This very old argument about you should have 3 directories, HTML, CSS, and JavaScript, and put all your files in these 3 categories.

Evan You:

That's like options API to me nowadays. Right? So when you transition over to thinking about components, a component is a unit self contained unit that that contains the cross cutting concerns from all 3 different layers, but they are grouped they are related to the same unit of logical concern. And Composition API essentially gives you the ability to think about all your logic in the same way. So instead of thinking about here's data, here's computer, here's methods, it's like HTML, CSS, and JavaScript, you can now choose to cut a piece of it out and say here's a composable.

Evan You:

It has all the things that's related to this specific logical concern. I can move it anywhere I want. I can put it inside my component. I can move it outside of the component and share it between multiple components, or I can even extract it into a library and share with other people, share with other projects. I think that's super powerful, and you can do that while having proper type inference all the way through.

Evan You:

You never get lost with where a property comes from because they always get returned from function calls. You can always just go to definition. You see exactly how they are created.

Evan You:

So this all of these just adds up to the overall maintainability of large projects with, which we have seen over the years people just struggle with Options API. Like, I think a lot of proponents of Options API really, like I think it works for them.

Evan You:

It's great because their projects just isn't huge. Right?

Evan You:

There is a scaling limit to options API where if you have a huge project, multiple people working on, you have a component that's 100 of lives long, it's not gonna be fun. It's just not. But with with composition API, a thing people don't realize is, it's kinda like building, some model kit.

Evan You:

1 version is like it only has a fixed way of putting it together, and you have to strictly follow instructions. So you don't need to use too much of your brain. You just follow all the instructions and things falls into place and you have something. But that's the only thing you can build. And if you follow the instruction, that's the only outcome.

Evan You:

That's possible. Right? But on the other hand, if you're something like Lego, like, you can use your creativity a bit more. But if you don't use your brain, you just randomly put things together, it's gonna be a mess. But if you use your brain and think about a design and you think about, I'm going to build this nice piece of Lego.

Evan You:

Now you can use your creativity to build something that's probably better than an off the shelf, you know, thing that you can you can think of. Right? So the upper ceiling is higher without composition APIs. And I also compare that to writing composition API code is more similar to writing normal JavaScript. Right?

Alexander Lichter:

Definitely.

Evan You:

Right? So it's like if you write messy code with a composition API, you probably write messy code with normal JavaScript modules too because you don't think about how to group your variables and your functions together. How do you, like, make abstractions? How do you split out modules? You think about all that when you're writing normal JavaScript.

Evan You:

Composition API kind of forces you to think about these same concerns. You're writing new component code. So that is indeed a lot more you need to think about compared to options API, But that also allows you to apply all your JavaScript skills in terms of, like, how do you write nice abstractions, How do you organize code neatly? How do you make them maintainable? All these skills that's applicable to writing good JavaScript now apply to writing good composition API code.

Evan You:

Right? So so anyway, if you are a good JavaScript developer, you will find composition API more, you know, liberating because it now you can app you you can, like, fully leverage your skills as a JavaScript developer. Right? But I also understand, like, if you don't want to just spend time thinking about writing good JavaScript code, you know, like, I want to just get my hands held all the time. I don't wanna think.

Evan You:

Right? Options API might still be a better fit, but as I said, views user base changed over time. Like, we now have real Vue users who are trying to build really complex stuff, and maybe they are really good at skilled developers who can write really well maintained JavaScript code. So it would be a pity if we lock them into the upper ceiling created by options API forever. Right?

Evan You:

So in a way, my motivation is to create this alternative API that unlocks that ceiling for them. Right? So, unfortunately, to some users, it might not be the most, you know, ideal trade off because they probably never hit that ceiling. So to them, composition API is just there's something I need at. Right?

Alexander Lichter:

Overhead.

Evan You:

Right? Which is unfortunate, but I think it's a result of these user base being really, really diverse. Mhmm. And, you know, tough decisions have to be made.

Evan You:

We try to, you know, make sure that if the existence of composition API won't affect how your options API code works. Right? In fact, you can even easily leverage composables used by other people if you still prefer to write options. Right? You just use the set of a hook and you can still use composables.

Evan You:

So we definitely tried our best to find find the right balance. I think it's just it's not quite possible to make everything perfect for everyone. Someone will complain, but I think we tried our best. I'm pretty happy with the outcome in general. I think composition API achieved all the goals that we set out to to do.

Evan You:

It had better types of support. It unlocked logic reuse and composition. It increased the maintainability ceiling. Right? It spawned projects like view use, and it's now the preferred way to write components for most new users.

Evan You:

So, so I think we achieved the most of the things we wanna achieve with composition API, but options API is probably gonna be here to stay for as long as we know.

Alexander Lichter:

That's a good 1 because, like, that's that's definitely what 1 of the big questions. It also, like, came up, in in the last weeks, weeks before. The recording here, like, there was a bit bit of social media drama about, like, oh, yeah. Composition API was Options API. Here we go again.

Alexander Lichter:

And, of course, people were like, okay. Will the Options API stay? Like, you you said multiple times it will. You also made this to you on Twitter. But, like, is there is there, like, an end of life at some point plan for the options API?

Alexander Lichter:

Will it probably around for for years to come or even, quote, unquote, forever?

Evan You:

The cost of keeping options API around is, like, very, very low because there's literally no maintenance burden for it nowadays. Like, it's just a really thin layer, that's on top of composition API. Like, all the things, all the bugs we fix, it applies to both API styles pretty much. So yeah. I don't I don't really see like, there's no really no reason for us to remove it, other than I think even if we wanna encourage people to use Compass Center API, we will do so by just tweaking the documentation.

Evan You:

You know? Like 1 thing that we acknowledge is that actually I've heard this from some people who've recently picked up Vue, and they're pretty advanced developers. So their primary question is when they first look at the documentation, they see the API style toggle. Yep. And, naturally, they want to understand what both how both API works because they want to make an informed decision.

Evan You:

But unfortunately, that just creates this extra mental overhead for it. Like, people hate having to make decisions when they first learn something, but we throw this big decision right in front of them at the very beginning. It's kind of off putting to new users. I think at 1 point, we'll just have to be more opinionated and just, like, be the dot. Like, we will assume a lot a lot more things because right now, like, we have to assume, do you use a build tool?

Evan You:

Do you prefer options API or composition API? Like, this just leads to all these different branches. It's a whole decision matrix, and that kind of blurs people because I think most new users nowadays, especially when they try to compare Vue to other frameworks, for example, Svelte, it has only 1 default way of using it. That's with a build tool. Right?

Evan You:

So, so if people are comparing that, they're like, okay. Svelte just directly shows me the only way of doing things, but Vue gives me just like 4 different branches. Now I have to figure it out and just kind of, you know, creates a bunch of barrier they have to jump through before they get to know, oh, this is actually the happy place. But but that takes time, right, because when we first did 1 view 3, the new documentation, I think having both conversation and options API in there is still definitely necessary. Like, we kinda want to give them equal weight, equal treatment.

Alexander Lichter:

100%. I mean, there's there's so much content also still in the options API Yeah. Which is which is another thing. Like, I I personally like to know both APIs. Not, like, forced straightaway jumping in development, but more like, okay.

Alexander Lichter:

It's still good to see. Oh, wait. There's an older resource about, I don't know, a certain library to use certain pattern, and it's it's still good to see, okay, this is options API, but I can still read it and transfer it over composition API because I know both.

Evan You:

Yeah. I I think, like, over time, like, we will, you know, have we unfortunately, we will always have these existing content that's created using, like, certain dialect. I think the most damaging part, the period where we shipped to Vue 3, but we didn't have script set up. That's, like, between 3.03.2. Yep.

Evan You:

That was probably the most hurting period where there were a lot of articles written online introducing composition API, but it's using this whole, like, setup return syntax.

Alexander Lichter:

The verbose 1. Yeah.

Evan You:

Yeah. And some people using other frameworks during that period will be like, oh, let's check out Vue composition API. And I see that. They'll be like, I don't know about that. Right?

Evan You:

So that's I think that's that's kind of a mistake on our side. We should've just, like, shipped with script setup straight away, but, unfortunately, we kind of, again, didn't do that upfront. In hindsight, we should have just maybe ship composition API with script setup from day 1. But when people say, show me what a view component looks like, we'll show them the default. That's SFC with script setup because we believe that is the most reasonable way for you to, start a new application nowadays given all the support, given all the ecosystem tooling and everything and the maturity.

Evan You:

So, it's at a point where we can now recommend that as the default. So probably, in the next year, we're gonna do another revamp of the documentation and start to kind of be more opinionated on, like, if you're just getting started, this is the way of doing things. There's no decisions to make. When you get a bit more comfortable with this, you can then explore auxiliary options. We'll make you aware of those options exist.

Evan You:

We'll still properly document them, but we want the default onboarding path to be to get rid of all those decision matrix in just like 1 straight away. And you get to something that you can, like, confidently say, now I know how Vue works. I can build something with it. And now I discover, okay, there are also other all these other ways of doing it. But if I am I'm already happy with the default way, I don't I probably don't even need to, you know, spend too much brain trying to figure out whether I should even use them.

Evan You:

You know?

Michael Thiessen:

Yeah. And if it's not a lot of cost to keep the options API around, I think it makes sense for sure to keep it around, especially because of the, the, the whole spirit of of Vue in keeping oh, you can just drop it in a script tag. Yeah. You can use the options API. That's a little

Evan You:

Yeah. I think options API is still better suited for the drop drop in through a script tag case. Right? That's also 1 of the big reasons we wanna keep it around.

Alexander Lichter:

Very good point. Yeah. Like, maybe you've seen, Justin Schroeder's proposal saying, like, hey, at some point, maybe it would be good to to, like, put the options API behind a flag. I mean, there's a compile time flag already or a compiler flag already saying, let's remove the options API, fully to make the bundle even leaner if you really don't use it at all. Have you have you thought about that a bit more?

Alexander Lichter:

And there's still a way you could imagine pursuing or or maybe not, like, in the in the future, like, not tomorrow, of course.

Evan You:

Yeah. I think you can already do that today. Right? It's really just a matter of flipping a boolean as the default. I think we'll need an RFC on that probably.

Evan You:

I'm personally leaning towards we probably can consider doing it in view 4. You know? I think in a lot of things we do in view 4 that will be considered breaking changes just really like changing how something works by default rather than changing the way it completely works. You know? Like, I think future to view 3, the biggest, like, issue in the breaking changes, a lot of them are kind of like these low level changes where it makes it really difficult for automatic migration.

Evan You:

Mhmm. But something like, you know, a configuration flag that changes the default value or just like options that flips the value, these are extremely easy to migrate. So we, you know so breaking changes in Vue 4 were probably more along those lines. It's really just like, we will also most likely have a version where you can say like turn a flag on opting to all these individual it's kinda like migration build, but much easier, more compatible. Yeah.

Alexander Lichter:

That totally makes sense. And I I hope somebody will come up with the RFC just to see where where things are going.

Evan You:

Mhmm. Yeah.

Alexander Lichter:

Maybe let's stay a little bit longer with with Vue 3 and the Composition API because, maybe some some of the listeners or viewers don't know that. Like, composition API as it is now, even without script setup, was not the first way, of of proposing a different API. Before there were experiments with a class based API. Maybe you can you can tell a bit about that and why eventually it it wasn't used and, the composition API as we know it now is a thing.

Evan You:

Yeah. We definitely ex we did have our RFC exploring class API before we went with composition API. It was also motivated by type checking because classes are quite type friendly as well. Unfortunately, in order to support the full range of features that we want and be expressive, we really needed decorators. Like, you can't really cover the full range of things you wanna do without decorators.

Evan You:

And so when we look at the decorators, it was still a stage 2 proposal, and it was really influx. Like, because I follow along the TC39 discussions for decorators during that period, and there's just so many disagreements and, seemed discussions seem to be going nowhere. And, it just feels extremely risky to rely on that behavior because TypeScript app back then implemented a decorators, which is now considered legacy. Right? The behavior is completely different from today's standardized, decorators.

Evan You:

So at the time we were considering it, I just felt it's just way too risky to base a whole new API design on something that's that's still, like, highly influx. And I think that bet was kinda right because, later on the the decorators proposal went through a complete overhaul. So the stage 3 version of the decorators was, like, completely different from the stage 2 1 that that was there when we were discussing class based APIs.

Alexander Lichter:

It was also, like, a totally new thing, I think, for TC39 proposal changing that much from 2 to 3.

Evan You:

Yeah. It's just, like because I was a bit you know, I saw the the way people went about the proposal. I just felt like people seems to be just disagreeing on a lot of things, and I don't think the proposal is gonna stay the way it is when it eventually lands. Right? So it's it's kinda like not just because of stage 2, but because I was also a bit involved in the process and saw how it was going and felt it was just really risky.

Evan You:

I think like when when decorators change a bit, like it also caused issues in Angular, for example, like where can you place the decorator on, like, at default exports. Right? Does that kinda change how where you like, can you place it before the export default or do you have to do export default then decorator? Then the thing, You know, that kinda caused trouble in Angular too.

Alexander Lichter:

Yeah. I think all in all, like, it was a it was a very good bat to to go on, the composition API as it is now. It I think the only thing that probably people used class based components in Vue 2, then they might have a harder time or, like, had a harder time migrating to the composition API. That probably was more 1 of the downsides.

Evan You:

Overall, I just think I think in Vue 2, we definitely, like, try to support different kind of use cases. Like, someone builds Vue class component, people like it, so we're like, okay, sure. Because at that time, it was really an a way for people to get better TypeScript support, And, basically, we're saying if you we are willing to opt into this experimental decorator stuff, you know, this might be the thing for you. But I think once we had composition API, we realized there's just too many ways of writing a few components at 1 point. And we really need to just kind of narrow it down once again.

Evan You:

So in Vue 3, we just decided, okay, like, class components. Now it's just a completely community thing. If you wanna use it, there are still people maintaining something called Vue facing decorators, I think. Which is, in my opinion, like, if you really like classes, you can use that. But at the same time, I think from a framework perspective, it's not really reasonable for you to demand the framework to bend the fundamental way it works to cater to your personal preference.

Evan You:

In that case, you should just use a framework that better you know, is, like, class by default, like Angular. That's fine. If you prefer classes, right, or you maintain your own abstraction on top of Vue and leverage everything that we provide that suits your needs. But in a way it's we just decided we don't want we no longer want to take all the responsibility and maintenance burden of having to make everything class component compatible.

Alexander Lichter:

Totally makes sense. On on that note, you said, like, classes in Vue, like, not only class components, but using maybe classes with the reactivity API that Vue provides. Do you have the feeling that's also a bit more tricky than objects and and, like, erase, like, the more primitive types?

Evan You:

I think it's work it works fine in most cases. I actually see quite a people do that, like, from reproductions or or things we see. The only tricky part is classes can have all kinds of edge cases, like compared to plain values in closures. For example, some people want to use private fields, with a reactive object. That causes problem.

Evan You:

Some people want reactivity in constructors. That has a problem. Right? So classes is just a native construct that's a bit difficult for for you to cover all the edge cases. That's why we generally do not recommend people doing it.

Evan You:

Like, if you know all these gotchas and know how to avoid them, like, don't expect reactivity in constructors. Don't use private fields. You'll be fine. But it just feels you know, if you have to, like, remember these rules in order to use the reactivity API, why not just, stick to the recommended way of having these things declared in a function scope? Yeah.

Evan You:

But if you you're willing to just step around those pitfalls and you're like, I still prefer classes, that still works. Yeah.

Alexander Lichter:

Fair. This was part 1 of the amazing interview with himself. We recorded almost 2 hours of raw material, so we decided to split it into 2 parts. The next 1 will come next speaker on the same time, so until then, take a look at the earlier episodes of Stage Review, for example, with Daniel Roe and other amazing guests. Tune in, and let us know what you think.

Alexander Lichter:

Of course, if you have any more questions, let us know on Twitter, write us an email, or comment on your favorite platform on YouTube. Stay tuned, and talk to you next week. See you. Until then.