Kate: Awesome. Welcome to PodRocket, I'm Kate, the producer of PodRocket. With me today is Noel Minchow, one of LogRocket's engineers and also Evan You. Evan, welcome. Evan You: Hello. Hello. Kate: Thanks for joining us today. I have to say having you coming on the show has been the biggest request that PodRocket has had, so we are super excited to have you on. Yeah, thanks so much for joining us. Evan You: Cool. Excited to be here. Kate: Awesome. Yeah. So Noel, do you want to get started? Noel Minchow: Yeah, I mean, I think just kind of to start with, I feel like most listeners will probably be familiar with you and know what it is. I guess, if you could give us a quick intro on yourself and who you are, that'd be awesome and then we'll jump into... I have a whole bunch of topics I want to cover but jump into all kinds of stuff from there. Evan You: So the whole thing starts... I think the first commit on Vue. Well, originally it wasn't even called Vue. It was called CJS. That was just a random name that I picked. I was working at Google back then in New York and we were doing a lot of quick prototypes iterations, a lot of these explorative UI prototypes. So we needed something to move fast and I just wanted to build something that allows me to feel comfortable cranking out stuff fast. So that was the reason I started looking at Angular, which was used in some of the projects we did. And I felt there are... The Angular already has this template syntax and you have this reactive binding between the template and your state, but there are also a lot of other concepts, which I just felt I didn't really need. Evan You: So the initial attempt was really just to replicate a reactive templating system but without all the burden that I didn't want. Also, I wanted to play with the idea of using ES5 getters and setters for a reactivity system. And back then, because people still wanted to support IE8 so a lot of people were like, "No, no ES5." And I was like, "Whatever, we only support Chrome internally anyway." So yeah. So that was the first iteration of Vue pretty much but it was really just a side project. I was just building it my spare time. It's more like a technical toy in the beginning. So I worked on it occasionally but never really thought about, "Hey, I want to like push this thing to be public or anything," but eventually I guess I started using it in some of the personal projects and I felt like, "It actually feels pretty good." Evan You: So I decided to eventually write the documentation and design a logo, switch a new name, found the name... Vue was available on NPM. So that was really good. I think all the three letter names are taken now, but it was still available back then. Then I think I published the first version in February, 2014 and that was the beginning, but still that was just a personal project really. Noel Minchow: Yeah. Cool. Cool. And then I think and you moved to media after that and spent some time there and then while you were there, you made the jump to start working on Vue full-time. Is that right? Evan You: Yes. Yes. Noel Minchow: Yes. Were you like nervous at the time, I guess, was there a definitive point where you went like... Was there an event that occurred that made you think I should probably make this switch or was it a slower, you just had this creeping feeling that Vue might be where your future was? Evan You: Yeah. I guess it's a slow process. I think the biggest driving factor was burnout at my day job. I guess the burnout is also partially caused by the pressure of having to work on an open source project with growing demand in your spare time. So you essentially... I was essentially working like every hour I was awake. I was either doing my day job or answering issues or fixing bugs in Vue. So I didn't really give myself too much time to relax. I think that was around 2016. Yeah, late 2015, early 2016. So that period of time, I was really burned out and I was struggling to just feel like I wasn't really feeling fulfilled at my day job and I feel like, I'm more alive when I'm working on Vue. Evan You: So that's the biggest reason because for me, I knew that if I quit into to do any open source full time, I'm probably going to make a lot less money, at least initially and it's not as stable, it's always a leap of faith but for me being able to just work on it as the... Because it's the thing I really want to do, it's a big utility plus. So I was willing to take a pay cut to do it and the worst case scenario is if after year, I'm like, "No, this is not working." I mean, I can always try to find another job, the option is always there. So yeah, I decided to do it in early 2016 and luckily it all worked out, so I never looked back. Noel Minchow: Yeah. Nice, nice. I feel like, yeah, such like a story that so many devs love that whole kind of like, "I quit my day job then went to open source and now it funds me." And I feel like that's why people like hearing you tell it so much. Cool. I guess did you consider any other funding sources or anything when you were making that decision, were you eyeing other projects at the time and seeing what was happening out there in terms of open source funding? Evan You: Yeah. Interestingly, so Rich Harris just got hired by Vercel, right? So I recall when I was... Right before I was about to quit, I was actually sending out resumes and basically the... I was sending also a few job applications on those open hiring platforms like Level or something like that. Then basically my description was, "If you want to hire me, you need to basically... Your company must use Vue in your product and I need to spend this amount of time on Vue." So that was a condition in my job application, nobody picked it up. Evan You: So I was like, I probably can't use that word here, but I was like, "Fuck it, I'm going to do this." And yeah. So I did try, right? So but it was difficult, right? Especially when your project is... I think Vue back then was probably in this limbo of, it has quite some traction, it's a lot of work. It really demands my full-time attention, but it wasn't as big as today where it's enough to generate enough ecosystem and all this sort of support from the community to make it possible. So I had to rely on some sort of... Basically I was just ready to fall back on my savings in the beginning. Noel Minchow: Yeah. Got you. Got you. Yeah, it must have been kind of scary for sure. I mean, did you ever... Like in the early days, did you ever consider not having it be an open source project or did you know that it was like... This is going to be an open source front-end framework and that was just how it was. Evan You: Yeah. It has to be open source. That's the whole reason I'm doing it. Noel Minchow: Yeah. Evan You: I just feel... It just feel... Because Vue started as open source project and it only got traction because it's an open source project. I don't think... Interestingly because front-end landscape is quite interesting. If you think about the current generation of frameworks, one is from Google, one is from Facebook, Vue and Svelte are independent, but prior to that, there were actually successful paying models in front-end like Centure. So they were actually making a lot of money but their target really is these wholesale component suites to enterprise. Evan You: If you're working in a framework layer, it's actually really difficult to monetize because they are these big players like Google and Facebook who don't really expect to make money from this. For them, it's more like React is strategically more like a hiring weapon. It creates this whole ecosystem developers who are familiar with React, which makes it really easy for Facebook to hire people. But for Vue the only reason that I'm working on it is because it has created a lot of... A very vibrant user community, people like it and that's why I work on it. Noel Minchow: Yeah. Nice. Yeah. Very cool. Yeah. There's definitely that network effect, I think in front-end frameworks. Were you, I guess, acknowledging that? Were you... Did that even add more hesitation when you were starting with Vue? Like, "There's no way we can overcome these big players." How did you get over that fear? Evan You: It's a constant uphill battle. I mean, even today, I wouldn't say Vue has... People still consider Vue the underdog when compared to React, right? It's much bigger in the early days and funny enough, ever since day one I released Vue, there's always been this kind of some user from like, "This is from an indie developer, it's going to disappear next year." Every year I see a comment like that. It's funny, right? It keeps going on. So I'm happy to prove those people wrong though. It's always cool to be able to just... I think it... I wanted to talk a bit about this on Twitter but it feels weird because a lot of people seem to think React has won quote, quote won, they believe, "It's the React world. Everybody just learns React. Everybody uses React." Evan You: But in reality, there are a huge group of developers outside the React world who just... Who don't use it. A lot of people especially in PHP or WordPress world, a lot of people are still on jQuery. For them, even Vue is like the new stuff. And Vue itself has over 1.5 million weekly active users. And if you look at this, the dev tools extension number, if you actually, definitely isn't small compared to React, they're on the same order of magnitude in terms of user count. So a lot of times, Twitter really is an echo chamber where I sometimes feel like, "Why is everything in React?" Because I follow a lot of people in the React ecosystem as well. But in reality, when you look at the numbers, you realize, okay, there are so many people, so many web developers in the world, it's extremely diverse. Even if you look at all the web component libraries, sometimes numbers may surprise you. Noel Minchow: Yeah, totally. Yeah. There's so many out there and yeah so many players in this space. I guess, yeah, going back to the early days again, when you were working on Vue maybe when you first had the dev tools installed, were there any sites that you came across, like big players that you were surprised like, "They're using Vue, that's pretty cool." Were there any moments you had like that? Evan You: Yeah, I guess Louis Vuitton is actually using Vue. Yeah. And there are a lot of recent movie trailer sites are using Nuxt. Like the Matrix 4 trailer site, the Dune trailer site, they're both using Nuxt. I just recently moved to Singapore. I was buying furniture online and found out a few local Singapore furniture shops are using Vue. It's always nice when I'm actually just randomly stumbled up upon this site, I'm like, "Wait, my dev tools icon light up." Noel Minchow: Yeah. Yeah. No, I totally... I have that experience all the time as well. I think I feel it more when I see like I'm on a big player's site and I just wouldn't expect them to be using Vue, I'd expect like a React shop or something but it's always cool. I should have like came up with a list before I got on here but I feel like that happens like at least a few times a week. I'm always like, "Cool, look, Vue what's happening?" Yeah, cool. I guess on that while we're in this mode of comparing frameworks a little bit, I feel like a lot of people think about like Angular when Vue was starting, how Angular was in its transitionary period and that led to a lot of Vue success. Do you think that that's true? Evan You: I honestly don't know. I think Angular still largely appeals to a very... Its own dedicated group of developers coming from a more Java, C sharp enterprisey background because the thing is about Angular is if you are a Java developer, it feels very, very... You will feel very at home in Angular both one and two. A lot of concepts carry through, right? But if you are a say like me I'm self-taught in terms web development or you're coming from a designer background or you're just starting from basic HTML, CSS, JavaScript, Angular will feel very intimidating. So I think Vue's initial success or Vue's long term success has always been based on this sort of, we assume our users... First we acknowledge the fact that web development has a very low barrier of entry, right? Evan You: You can literally just open an HTML file and you can write a webpage without any prior knowledge, right? So we want to use that as the baseline. Like how can we have someone with just the basic, basic HTML and JavaScript knowledge and be able to build something interactive and that's always been the premise of Vue. So to this day we still... We guarantee that every build of Vue will always be usable without build step. You can put it directly from a CDN with no MPM whatsoever and you can write it directly in an HTML file. The whole application can be in a single HTML file, that's the... And it can be used in production. I mean, people use the argument all the time they got. You can use the whole JSX transforming in the browser too, but you wouldn't do that in production, but you can shift something like with Vue to production and a lot of people actually do that. Evan You: People use it as a jQuery replacement in some cases, right? So that's an important factor. I think this really helped people from the backend developers from like the PHP developers, Laravel developers, they loved Vue a lot. So I think a big adoption wave came from the Laravel community when Taylor Otwell, author of Laravel started using Vue himself it resonated with them because it just felt easier to pick up for backend developers. And I think that's... Sometimes senior developers like to talk about how simple is not easy and they imply that something being easy means it doesn't scale or it's inferior in some other aspects. Evan You: But I think in practice, easiness is underrated because in the end, in the world, not all software... Softwares are meant to solve problems and having an easy tool to have you solve that problem in itself has value. It doesn't necessarily mean you have to always craft the most delicate and sophisticated software in order to solve a problem. If you have a hammer that can solve a problem, use that hammer, right? So in that sense Vue is always trying to be the pragmatic solution instead of being the one where you can say, "Look how advanced I am. Look how... What crazy pattern I just invented with this framework." Noel Minchow: Yeah. Yeah. I think a lot of people get in that head space like, "Credit apps are solved and the front-ends that aren't complicated, they all work well and everything's fine." But I feel like, I don't know, if I'm just reflecting on even like the UIs I've used in the past day. There's been several where there's like some crippling front-end bug happening and it's like there's just like the tooling isn't there to help these people build sites easily, at least they're not finding it. Yeah. So I totally agree. Yeah. Cool. Yeah. Let's see. I think I want to start talking about newer stuff here. Again, I feel most listeners are probably familiar with Vue at least and it's like comparing Vue and React isn't that interesting, except for in a couple narrow cases. But can we talk a little bit about the shift to Vue 3 and what you think are some of the cool new features that people who are familiar but haven't used Vue in a while they might want to come back and check out? Evan You: So Vue 3 at the fundamental level, there's just a lot of fundamental improvements, like it's smaller because it's now tree shakeable, a lot of parts are tree shakeable. It's faster, I mean, if you do a rewrite and it's now faster, it probably failed. So luckily we have very pretty significant performance improvements compared to Vue 2. It has better TypeScript support, significantly improved. And in fact, in the past year we spent a lot of the efforts in the surrounding supporting tools of the framework. Like we have a new dev tools extension that supports both Vue 2 and Vue 3 and it's also extensible. So you can actually write your own. If you have library, you want to lock some events into the Vue dev tools. You can actually do that. And then we have a new VS code ID extension, which has significantly better... Overall the tooling support is just significantly improved. Evan You: Now even inside the template, you get TSX like type inference and type checking and everything. So it feels like TypeScript is part of the... Part of your Vue single file component. And then server side rendering also greatly improved performance and probably the most significant part about user facing API is obviously the composition API, which is inspired by React Hooks. A lot of people say, "It's just React Hooks," where I have to explain every time, no, it's not... The two works. So when you extract a reusable function, the pattern looks very similar but fundamentally how they work is very different. So Vue is like one shot, you set up all these objects once and then you just reference them. It represents two ways of thinking about reactivity in front-end, React is like, "Let's go immutable, we're going to pull the world every time we render," whereas Vue is let's go truly reactive, we have these reactive objects that you're going to hold a reference to and you watch them. If they change something happens. Evan You: It's quite interesting but I won't go too much into that. But for Vue itself, Composition API unlocks a lot of interesting capabilities. Like people... What people were excited about with Hooks Composition API can do a lot of that too. You can extract your custom utilities, use this, use that but at the same time, it also has better TypeScript support. And more importantly, it's a similar argument for how Hooks improve the coder organization compared to class-based components in the sense that you are no longer bound to this context, you're not able to move around and organize your code just like normal functions. So that... It's an interesting tradeoff because we've gone through a lot of debate on the introduction of the composition API and the consensus now inside the team is that it essentially, because it's more free form, it allows beginners to write worse code, slightly worse code, but it allows experience developers to write significantly better code. Evan You: So that's the tradeoff we're taking. So you can think of the Options API versus the Composition API. The design tradeoff is options API is like, even if you give it to beginners, they can write somewhat okay code. But when they write very complex components, it's going to be a mess. With Composition API... And the problem with Options API is even in the hands of experienced developers, they sometimes will struggle to make things maintainable, but with Composition API, it's sort of like, if you are experienced, you can organize it just like how you write normal JavaScript because we as developers, we know how to organize functions, extract functions, type them, organize them, test them, right? So Composition API makes that all the same with normal JavaScript code. So you can apply all your code skills on them. But on the other hand, if you don't know how to write good code in the first place, you might still write a mess, right? Evan You: So it's kind of unavoidable. So, which is why we still don't really tell people to say, "Hey, you should definitely go with Options API or you should definitely go with Composition API." So we are currently working on the new docs where we try to explicitly discuss what I just talked about. Like in what situation you might want to consider this, in what situation you might want to consider that because a lot of times really there... It's not a one size for all kind situation. So I guess the best way for us to solve that is to explain that with documentation to give people... Help people understand when they should use what, like what fits them specifically better because different experience level kind of you will... It'll probably suit... One API will suit you better based on your experience level. Noel Minchow: Yeah. Got you. Yeah. Again, like I'm a hobbyist Vue dev that's where I do my side projects and stuff. And so I'm in that space a lot where I'm Googling stuff and trying to read the docs. I have found recently that with the Composition and the Options API both out there now I've found it a little bit harder to search for and find an answer to a specific problem because both exists and there's conversations happening around both. Did you anticipate that increase in complexity around the discussion of how Vue works? Evan You: That definitely is a problem. I think it's interesting because we... For the past year, it's pretty much a transition period where because both APIs exist and we were... I wish we did the... We push out the new docs earlier, but I just spent way too much time on Vite. Noel Minchow: Yeah. We'll get there. Yeah. I'm excited to talk about Vite too. Evan You: Yeah. Yeah. But I think definitely the new documentation probably should have been out there earlier to give people a clear picture of what... To give people the guidance. Right now the confusion mainly comes from, you're searching for something, the docs itself is still like the main paragraphs are in Options API and then Composition API is tucked away in a separate section like how the React docs has been, right? It's like still Class API and then Hooks is in a separate section. But I think the React road has pretty much consolidated on Hooks whereas in the Vue world, we're probably going to see them coexist for a bit longer, which is one of the reasons why we work on syntax sugar like script setup to help make Composition API more ergonomic to use because the little bit more for verbosity when you're using it is what turned a lot of people away. Evan You: But we believe with more compile time, we're actually investing more in the compiler front because we can see how compile time optimizations and syntax transforms can unlock both performance and development experience gains. So script setup is inspired by Svelte, right? So we essentially took some of the good parts from Hooks and also some good parts from Svelte and now you have a very concise, succinct syntax for using Composition API within single file Vue components. At the same time, the benefit of this is we Vue's reactivity system, the Composition API works both in and out of components, it's the same API. So you can move any code inside a big component out of your component and refactor it or extract it into reusable functions. You can do that very easily. So it's not bound to a component based compilation model. Evan You: So I think we hit a pretty good sweet spot in this in terms of having decent in component ergonomics versus still being able to allow refactoring extraction and cross component logic reuse and that's... Yeah. So this will be essentially be the focus of the new documentation. We want to highlight because we arrived at this after a long time. A lot of these went RFCs went through some really long discussions. So the new docs is essentially trying to consolidate all of this. This is the new recommendation, if you want to use Composition API, it'll give you a quite... I would say it's quite different from what Vue 2 looks like but I believe a lot of developers will feel actually right at home because the fundamental concepts in Vue is still the same. It's the same reactivity model, it's the same template syntax, all the component building directives and features are the same. So it's really just a more flexible way of expressing your stateful logic. Noel Minchow: Yes. Totally. Yeah, I mean I feel like, yeah, every time I've delved it, I'm always like, yeah. I feel like I'm just writing more functional JavaScript code and it's always... It's really nice when I'm putting those together. So I agree. Evan, when you guys were writing up the Composition API and again, it's its loosely modeled over... Loosely modeled on React Hooks. Do you worry about devs when they're coming over, who are super familiar with Hooks, like conflating those two ideas and how they work under the hood? Evan You: I don't think that's a big concern because... So funny enough, you need to really understand how Hooks work to be able to use it. So when people come over, I think the common confusion I've seen is people assume that simple variable destructures would stay reactive whereas in Vue, you have to switch your mindset back to... So when people use React Hooks for a long time, your mind gets reconfigured by React and you start to think everything in Hooks mental model and, but when you use Vue you have to switch back to normal JavaScript heuristics. So basically if you destructure an object... Destructure properties often an object, it loses the connection to the original object, right? That's how JavaScript usually works and it's the same way in Vue. That's probably the only thing that trips people up if they're coming from Hooks but they would adjust really quickly because they're basically just trying to say, "I'm no longer using React Hooks. This is just like normal JavaScript." If I want things to stay reactive, just keep accessing it from the original object. Noel Minchow: Yeah. Got you. Totally cool. Yeah. Again, I just like... They function differently. So I wonder if other devs would have those kinds of issues, but got you. I guess the only other big Vue 3 migration question I have is are there... Have the libraries been slower to migrate than you anticipated? I'm thinking like BootstrapVue, Vuetify- Evan You: Yeah. Noel Minchow: Vue Material. Yeah. Evan You: It's somewhat anticipated. I mean, I anticipated the migration to be slow because when we started the redesign, I knew that for better internal implementations, for better performance and memory usage, we had to completely rewrite the virtual dominant implementation and as a result of that, some of the internals of like say how VNode is represented and how they are created was reworked. And because of the structure changes of the VNodes, which was technically a private API, people should not rely on it but unfortunately a lot of the libraries, especially the ones that has complex like UI components sometimes they reach for those things and Vuetify 1 relied on a lot on these, I know Chakra UI Vue also did this. So we evaluated this when working on the migration build and I was able to get some of the basic components that's not using the private APIs to work, but unfortunately, getting all these existing libraries to be a 100% compatible is just very... It is just way to costly. Evan You: So the migration build eventually only focus on the public APIs. So if your library only uses the public APIs, there's a very good chance that'll just work. For example, the migration build was able to work with the Vue 2 version of the Vue router and Vuex without much modification. And then you can... So in our migration example, there is a step by step commits. We move to the hacker use Vue 2 example to Vue 3. So also moved to from webpack to Vite in the process and then we swapped Vue 2 with Vue 3 migration build then we swapped away the Vue router then we swapped away Vuex. So that all worked but in practice, when you have a large library with a long history, there's just always be this technical debt where people reach for your private APIs and rely on specific behavior, which are particularly difficult to retain when you're doing a big refactor or rewrite. Noel Minchow: Got you. Yeah. Cool. I guess, yeah, the only other... I think we have a one... We'll have some more time for listener questions here but one of those was, how long until Vue 3 is no longer Vue next and it's like the main version. Evan You: Well, I originally hoped I could do that before I move but I wasn't able to and now after the move, it's been a battle going back into work because of all the post move, cross continent move, logistics and then the kids can't really go to school until January. So it's been a bit tough getting stable work hours in but we're really hoping to do that as soon as we can. And that is... The only blocker left really is the documentation. The new documentation is currently being worked on. It's completely redesigned with almost all the chapters receiving major revisions to reflect Composition API usage, latest best practices. We also updated some of the framework level concepts and descriptions because Vue has evolved from just library into more like a proper framework. So a lot of this work going into the new documentation and hopefully... I don't want to rush it because I really want to... We take documentation really, really seriously. So we really want to show it... Show the best form of it. So at this stage, I think it's probably realistic to aim for Christmas. Noel Minchow: With that, let's talk about Vite a little bit. Maybe just for listeners, I feel like it's probably not quite as pervasive. Can you explain what Vite is? Evan You: Yeah. So Vite is a new build tool that I worked on since early last year. So it's not really that new, it's being out for over... How long has it been out? It's quite a long time now, crazy to think about. But anyway, if you use webpack, Vite is... Think of Vite as a combination of webpack plus webpack CLI plus webpack dev server plus a bunch of conflict loaders that you have to write yourself but they're all sort of... Works out of the box and it's slighter, it's faster, in some cases the speed difference can be quite astonishing. You have to try it yourself. If you're reactive and you still use create React apps, try run MPN in it Vite now and just test the speed difference yourself. I think that's the best explanation. But internally the key feature of Vite is that its dev server is unbundled. Evan You: So your modules, your source modules are served over native ES modules, ESM by the browser and we do compilation transforms on the fly and over ESM, we are able to implement extremely fast, hot module replacement and more importantly, the hot module replacement performance is decoupled from the total size of modules. So this is what makes it fundamentally better in large projects when you have a project with 1,000 components, right? And with webpack, you probably experience like you save something, you wait a few seconds for it to change and even with hot much replacement, it's still like two to three seconds, right? But with Vite it's always going to be 100 milliseconds, regardless how many components you have. So that significantly increases the feedback loop, just like accelerates your feedback loop so you can stay in the zone, you can constantly make tweaks without having to wait for it to update. Like personally, for me, after I successfully implemented the hot module replacement, I just could never go back to webpack anymore. Yeah. Evan You: And another part of it is we use ESBuild, which is a go-based JavaScript transpiler slash bundler. It's a very awesome project by Evan Wallace. He's the CTO of Figma. And we use ESBuild insight Vite as the pre-bundler, which handles your... Pre-bundles your dependencies. We use it to transpile chat TypeScript and TSX and JSX, we use it to do CSS and JavaScript modification. So Vite is this hybrid tool where we leverage these native parts whenever possible. Like in the dev server, we leverage browsers native BSM. On the build tooling side, we try to leverage ESBuild whenever possible because it's just so fast. But we also recognize that for JS developers, it's important to have a plugin system that you can understand and easily write plugins for, which is why Vite is also compatible with Rollup. So we use Rollup for production build under the hood but during development, even though we're not using Rollup for development, we do allow Rollup compatible plugins that'll work both in development and production. Evan You: So we simulate a Rollup plugin pipeline during development so that plugins can work. Actually you can directly use a lot of Rollup plugins in Vite, it'll working development too. So this is why the current maintain of Rollup actually recommends Vite as the dev server for Rollup. So if you are using... Still using plain Rollup, you should really switch to Vite, you're still using Rollup in under the hood, but you get a better dev survey experience. Noel Minchow: Yeah. Very cool. Yeah. I guess personally, I can speak to that as well. I remember spinning up my first Vite project being like, just blown away, so fast, making large scale changes and changing dependencies and stuff is just staggering really quick. I guess, yeah, is there any other motivation for people using webpack, especially webpack without Babel? Because I feel like that's what's really slowing down a lot of those bills. Is there anything in particular you'd recommend like you'd... I guess you'd say to them to persuade them to come give Vite a shot. Evan You: I mean, if they're happy with webpack I don't... The funny thing is a lot of people ask me that question and my stance is that you should try it regardless because it's likely faster even if you're not using Babel but whether it's worth it is up to you because the reason I built Vite is not to convince people to switch from webpack, that is not my goal, right? And there are actually also cases where webpack is sort of... Webpack features that Vite doesn't do and it's totally fine. The key idea is Vite is designed to be a happy path for maybe 80 to 90% of average web developers who don't really want to handtune every single config that build tool has to offer. I just want a build tool that works, allow me to ship stuff. Evan You: And Vite is, again, I always try to do pragmatic tools. If you have a 90% common case that can be solved in a simpler and faster way, there should be something for that. It doesn't necessarily mean this tool should replace the tool that was there before it, maybe now they just each fit a better niche, each fit a better use case. There's probably still overlap and if it overlaps, you probably want to use the faster tool but again, it's not the goal to say... To replace a competitor. The goal is to make more developers being able to build things faster. Noel Minchow: Got you. Totally, totally. Yeah. I guess while we're on the topic of replacement, do you think Vite will ever replace or consume Nuxt's webpack like default? Evan You: I hope so. So Nuxt 3 has been made compatible with Vite, both Vite and webpack. I think the smart move from the Nuxt team is making Nuxt score essentially built to agnostic in some way. I think they did this mostly because they designed Nuxt 3 in the beginning to also be end deployment environment agnostic in the sense that it can be deployed not just as a no JS, long running no JS process but also for serverless functions, CloudFlare workers and all those environments. They had those in mind when they first designed the scene. So it also makes sense to decouple itself from the build tool if possible. Although I don't really know... I haven't really looked into the tradeoffs that they made in this, because I think by making a framework, meta framework built to agnostic, there's probably some tradeoffs in it. Evan You: I'm not fully aware of that because I haven't really read the code but there are a lot of interesting solutions that's specific Vite based like SvelteKit is Vite based. Astro is now a Vite based. Shopify's new framework, React framework, hydrogen is Vite based, it also supports React server components. There's also some framework agnostic Vite SSR solutions like Vite plugin SSR and which is... You can render Vue or React or other frameworks using that but it's like a meta framework for frameworks, framework for meta framework sort of. Evan You: Yeah. So it's... I think this whole space, the Vite dev tool space is super interesting because we... Originally, I created only for Vue but after realize it could be just framework agnostic, it actually now have this very, very cool ecosystem of cross component collaboration, a cross framework collaboration like solid JS, Marco team Sphel team and Astro and Vue of course. Our bill tooling is now all aligned with Vite. And so anything that we commonly share between the frameworks we can drop it down into Vite and make it benefit more people. Kate: Okay. So we do have some listener questions. We've got quite a few listener questions. We don't have time for all of them, but here's one that I think is interesting. You touched on it a little bit at the beginning but what motivates you to do what others don't and how do you deal with burnouts? Evan You: I guess the motivation is really knowing that my work makes people's life easier. I mean, I also make money from it, which is good, but that's like... When I started doing it, the motivation is primarily because want to... Because people use my software and when I see people use my software and they're like, "Wow, this makes my life so much easier. Thank you." These are the really like the main reason for me to keep doing open source. And this... Another important part is because we started have a... When Vue got a little bigger, we started to have these offline conferences and when I meet people offline, this feeling realizes much more intensively. Like when people coming in front of, you shake your hand and like, "Thank you so much for making Vue," that feeling is really something you don't get by doing a 9-5 office work. Evan You: I never experienced that when I was just being an employer but when you create something that you make sure that you put it out into the world and people start appreciating it, it's really amazing. So for me, that's the main motivation really. Kate: Awesome. And another one, if you had to start over, what would be the biggest rework you would do? Evan You: Rework? I would probably design the whole migration Vue 2 to Vue 3 migration a bit better. I think we tried our best but looking back, you can always do better with all the things you hindsight that you now have. We could have probably avoided some of the small breakages that caused too much... There are some small breakages but makes the whole upgrading process more difficult than it should be. So if we had time to go back, I would probably, tweak it a bit more so that they have smaller impact in the whole migration process. Kate: Sure. Well, Evan, thank you so much. This has been awesome. Thank you so much for coming on PodRocket. We really appreciate it. Evan You: Thank you. Kate: And yeah. We'll see you around. Evan You: Great questions. Thank you. Noel Minchow: Yeah. Thanks Evan. Super nice to meet you. Good chatting. Thank you. Brian: Thanks for listening to PodRocket. Find us at PodRocketpod on Twitter or you could always email me even though that's not a popular option. It's Brian@LogRocket.