Episode 12
Evan: The challenge is obviously it's quite big of a paradigm shift compared to options API, and also There are some strong attachment to existing APIs from some users because people just don't like seeing what they're familiar with being considered a deprecated or second class citizen in their framework.
Andrew: Hello, welcome to the devtools.fm podcast. This is a podcast about developer tools and the people that make them I'm Andrew. And this is my co-host Justin!
Justin: Hi everyone. I'm really excited today to introduce our guest Evan You. Evan is the creator of Vue JS but he's also. Prolific tool author. The Vue ecosystem is really rich and high quality tooling from the relatively recent Vite project, to the documentation vuePress, well, I guess it'll be Vite press soon.
Yeah. Evan, is there anything else that you'd like to tell our listeners?
Evan: Not much. Yeah. I work on Vue and Vite and all the related stuff to these projects and yeah, I'm I'm self-employed so I'm like independent open source developer. Yep. And I've been doing this for a few years now.
[00:01:16] Living off Open Source
Justin: Yeah, you do open source full time. That's just like your primary purpose in life. That's amazing.
Andrew: how did that end up happening? Did you set out to do that or did it just happened because of the success of your various projects?
Evan: It kind of just happened. I started working on Vue when I was still at Google. But that was purely a side project. Just wanted to see, like what can I do with JavaScript? So I can prototype my own stuff quicker but turns out it kept growing and it's like this cycle of, "Oh, more people are using it maybe I should spend more time into it." And then when I spent more time into it, it grows even further. It remained a side project for maybe I think I started in 2014 remained a side project for almost two years. And eventually in 2016, when I was at I was working on Meteor, but a Vue kind of grew so big. I decided maybe it's it's worth giving it a try to see if I can just work on it full-time. I mean, it's a combination of being burned out at actual work and I always felt like working for someone else's mission is especially if the mission doesn't a hundred percent align with your own sort of interest or curiosity.
It's a struggle for me. I don't know if that categorizes as ADHD or something, but. Yeah. I've always struggled with that, right. Where the goal isn't a hundred percent aligned with my own interests. So I was like, you know, even if I'm going to make a lot less money, the utility gain of being able to just work on something I absolutely want to do is huge.
So that's pretty much what drove me to do that.
Justin: I completely feel that I definitely have ADHD. And then the motivation factor is. huge. If It doesn't align with your interests, it can be really hard.
Evan: Yes,
Justin: Even if something is. interesting to you for a little bit maintaining long-term interest in something can also be hard. How have you sort of been able to do that?
Evan: I think it's really because the original drive of wanting to make something great. It allows you to just force through some of these smaller, like reluctancy of doing the dirty or hard work. It's a long process. There are times where I've felt really burned out because sometimes you just wake up after a new release, there's like 10 bug reports or are you originally planning that I'm going to do this thing today, but then someone reports one weird bug and you spend a whole day just fixing that bug and maybe not even being able to fix it.
It's like super frustrating. But over the time you just get used to it. I mean, I guess the good part is because it's not technically a job anymore. Right? So, you don't have a boss telling you, like, you must fix this bug today. So I can juggle around the priority a bit just to fit my own mental, status.
I feel if I'm feel I'm burned out, I can take a break. No, one's gonna yell at me for doing that. I don't need to get my manager's permission to do that. So that's a bonus. So I get a lot more freedom in terms of how I want to actually allocate my time, when to work when not to work. Yeah. So that kind of helps.
Justin: That's the dream.
Andrew: So, when we were talking from Dom, from storybook, he mentioned that you work at Meteor and you just did too did working at meteor and on those technologies Influence how you approach software development or was like all of that kind of already set in stone before?
Evan: I wouldn't say it's set in stone, I don't really adhere to any sort of strict rules of how to do things. I'm the figure it out as we go type of person. While I was at meteor it gave me a glimpse into how a already really huge, really successful project operates, but it's also quite different in the sense that meteor was a venture capital backed company.
The goal of the company was to eventually make money on top of meteor. So, so actually I think the thing I learned when I was at meteor was that it wasn't really I don't know, there, there are a lot of things that I learned there, but some of the more important takeaways were probably on the business side. Because meteor was initially got a lot of traction, but it was like, let's take a lot of investment and then we'll figure out how to make money. But turns out they just never actually figured out a good way to make money on top of meteor. So they struggle with that and I was with them through that process and I was worried too. Right. I was trying to see like, there are also some technical side of things. The initial position of meteor was to make itself a complete ecosystem with its own package management. It even bundles node inside its own distribution. So that creates a lot of unnecessary hurdles when people are used to just having their own node installed their own NPM packages, but then to make all of their work with meteor was a headache in the early days. So I was strongly advocating to embrace the node ecosystem to restructure meteor to just be a collection node packages.
But I guess the initial architecture was just so monolithic it, which made it really hard. So that was Vue my frustration on the technical side. I vented all that into working in Vue because I had more technical freedom to do what I wanted to do. Being too monolithic and too ambitious from the get-go, especially as for me as an indie developer is probably not going to work. Right. So which is why I intentionally designed Vue to be the term is like progressive framework.
So it's like really easy to be integrated into. An existing stack instead of on like angular, which is if you want to use angler, just adopt everything that I laid out for you. It starts from different assumptions about your user base. For me, it's really like I'm in the, I'm an indie developer.
My target audience is really people who are like me or beginners or I just really want to make something that's easy for people to pick up.
[00:07:18] Evolving Vue
Justin: One thing that I've admired about the Vue ecosystem is you seem to have a keen eye on picking out like interesting patterns and figuring out a smooth way to like integrate them. So I got started in the Vue ecosystem right as you're releasing Vue 2 and started doing a lot of work on virtual Dom and like bringing that into Vue and doing a lot of interesting things there.
And it's been fascinating to watch as it continues to develop and evolve, how you take the best of what's happening in the framework ecosystem and integrate it. So now that Vue three is been recently released. What is the sort of most defining features that you feel like made it into that release?
Evan: I mean, definitely composition, API.
It's also obviously it's inspired by React hooks in some way, but it's also interesting because there are a lot of misconceptions on people seeing the example usage and instantly be like, "Oh, this is react hooks." But fundamentally the only similarity is that you can extract reusable functions to contain a bit of functionality, but the underlying mental model is actually completely different. Because React hooks is based on this repeated invocation while as a Vue competition API is based on actual mutable, state, mutable, reactive state. So a lot of people don't seem to be willing to actually look past the superficial similarity, but the underlying reactivity model is completely different.
So that kind of leads to a lot of interesting small differences in terms of when you actually use it you start to see all the differences in practice. But the thing is composition API in fact is not trying to invent a completely new thing in addition to what you already had, it's leveraging what's always been there inside of Vue.
That's the reactivity engine, right? We take an object, we can make a reactive, then we can have reactions or effects based on how it's being mutated. That's always how Vue has always worked. So composition API is in fact just taking some of the internal functions we already had in Vue 2 and polish it a little bit and then expose it so that they can be used to stand alone. And it turns out that unlocks a lot of interesting possibilities.
So we have this project called Vue use which is similar to how there are a lot of hooks collection libraries in React ecosystem. So Vue use essentially covers like browser platform APIs, like use device orientation, use start mode, and then you also have electrons, specific stuff, like use RPC calls. Then there's our RX.js integration or integration with common libraries. Vue use is the validation that this model actually works in terms of composibility. And then it also solves another problem, which is what Vues original API has always suffered from is type TypeScript integration. So the options API, when it was originally designing 2014, obviously didn't even consider type inference at all. It was really just like, if this works at runtime, it works.
So when we start to add TypeScript support in Vue 2, it was a struggle because Vue 2's code base was written originally in plain JavaScript, then we added flow on top of it. And when we decided to shift type script types, we had to maintain the type separately. And the types that we wrote to be able to infer the stuff with the options API was just if you look into the ties it's like the most ridiculous type gymnastics I've ever seen. I believe TypeScript even added as a feature called this type because we couldn't solve the Vue typing type inference problem without it.
So, even with that, it's still has edge cases where say like you need to manually annotate the return time for computed. Sometimes. It doesn't work with mixins. We actually, we managed to make it work with mixins and V3, but still there are many cases, it just silently breaks or because like TypeScript just wasn't designed to, to work with such a dynamic convention based API.
So composition API kind of flips it all around because everything is just functioned calls, passing arguments. So everything, it just works with TypeScript perfectly without too much efforts. And the good part is because the inference is straightforward. You can if, even if you're using competition API without type script, you still get a certain level of typing. By using vs code. So, so that addresses another set of problems.
Overall composition API it really raises the ceiling in terms of scalability, for Vue applications while still retaining the same reactivity model that Vue has always had.
The challenge is obviously it's quite big of a paradigm shift compared to options API, and also There are some strong attachment to existing APIs from some users because people just don't like seeing what they're familiar with being considered a deprecated or second class citizen in their framework.
It's a challenge of balancing this because it provides really a lot of objective benefits. A lot of users actually like it, they prefer it when they're using Vue three, but there are also a strong camp of users with strong opinions. They believe this looks like react so I'll never use it.
I think a lot of this comes down to just communication and I'm recently just reworking our whole documentation, trying to it's a delicate balance of trying to redesign the docs in a way that we cover all the template parts, which is state agnostic.
And then we have to give people options. Do you want to learn the options way? Or do you want to use the composition? It's like class components versus hooks all over again.
And I mean, React docs still haven't really solved that problem. It's still class by default, then only a later you're like, oh, here's hooks by the way. So, I think it's a challenge, right? I believe the react team, the original intention when they introduced hooks is this is going to be the new way of doing things. But they can't just say that because people get mad. They'll be like, how about all my class components? And I believe Wayne cooks was first out there are still a lot of people who are like, this is a mistake. Class components are better. But only time will tell.
So, sometimes as a maintainer, it's a challenge for you because sometimes your judgment gets affected by feedback, but the feedback isn't always to the whole user base, because sometimes the most vocal people isn't necessarily the most representative. You have to gauge that yourself. You need to look at multiple data sources to, to make more informed decisions and which is always very tough. So sometimes you just have to believe in yourself and trust the intuition to some extent.
Justin: Yeah. for sure. I saw some of the initial conversations on the compensation API's RFC. Yeah some people were just very heated.
Evan: I think, yeah. Our biggest mistake was in the first draft of the RFC. We indicated that we want to replace options API. And people just went crazy. Uh, So looking back, that was a very obvious mistake. We kept options API completely in Vue three. It actually works exactly the same way. And the funny thing is Vue three is written with composition API as the primitive building blocks and options API becomes an alternative interface on top of that and the whole implementation to support options. API was like several hundred lines of code. So, it shows how like, options they've got really is a higher level thing where composition API is really just exposing the lower level primitives.
Andrew: but that's pretty interesting. So that makes it going forward a lot easier to maintain it. Right. Cause you're not really maintaining two targets. You have like your base components and then it's just like
Evan: Yeah. Yeah, the good thing is they're coherent at the lower level. There are not like two completely separate things.
Justin: So you've worked on a lot of tooling. I got involved in Vue a while back and just, I don't know that learning Vue what actually taught me like what Webpack really does. It's like trying to write a plugin. a webpack plugin for Vue. You've done a lot of stuff. And it's not just like the visible tooling, but there's a lot of things like the Webpack plug-ins what do you think has been what has been the most challenging work for you, what has been the hardest thing to build in the Vue ecosystem?
Evan: Probably the Webpack loader
Justin: Yeah.
Evan: It's interesting. I think we went through three completely different implementations for Vue loader over the years. I implement the initial version of Vue loader, which had a lot of constraints also because at the beginning, I just had no idea how webpack worked.
I was just basically trying things until it worked.
And later on, I got a better understanding of how webpacks whole module resolution and how I treat all these requests kind of worked. Look at that source code of other loaders. I rewrote it. So it was better structured, but still has some limitations.
One of the challenges is because we designed the Vue single file components to support pre processors for each language block. Which is to say, you can have a Vue single file components with a template written with pug, with your script part written with TypeScript or even coffee script, then with your style written in less or sass or whatever you want to use with post CSS after it. So, essentially a single file component becomes a sort of a meta file that needs to create. If you think about it, in fact, each block needs to be treated as a virtual module that lives somewhere. So I need to figure out a way to inside the loader with just a single loader, I need to be able to parse the file, then create these virtual modules and eventually assembled them back together. And then I have to make all the integration with other loaders as well.
The first version when we supported these preprocessors is we basically just say, "Okay, if this block uses SASS, I'm just going to check if SASS is installed and then apply SASS myself, get the converted results and send it back." This worked for a while, but then later on users were like, so here's a problem, right? I have some settings that I'm using for sass. So I use SASS both in Vue files and also as standalone SASS files. Which means they're configuring sass loader by themselves and they have special options pass sass loader. Now they have to pass the options twice, once to Vue loader onces to sass loader. And when you use more preprocessors, you have to this with every type of pre-processor like, you have to pass your Babel config twice. You need to pass template config twice. So eventually I was like, can we figure out a way so that we can in fact say take this part of the thing, but type it through whatever loader the user has configured for sass files and then get the result back for a very long time.
I thought that was impossible. I actually even talked with Tobias about it, who he's the author of Webpack. So Tobias gave me some pointers and eventually I rewrote Vue loader once again, this time using a complete different strategy, which now this uses a pluggin. It's actually now even more complicated, but it works much better because now it takes a pluggin, a pitching loader, a normal loader, and the pitching loader essentially inspects the incoming requests, rejuggle the loader orders around so that when we send a request to a certain block inside a Vue file, we will essentially look at use what the loaders user have configured for that file type, inject it into the Vue block requests. So it gets the exact same treatment. So that was really challenging. I mean, I don't even know how I came up with that idea, but it worked. And the thing is funny enough, like later on when we built a plugin for rollup and in extension for Vite, everything was a lot easier because we can now we control a lot more. So we're not working with the webpacks constraints.
Andrew: Did your experience wrestling with those constraints lead you to create Vite? Or was that from a different train of thought?
Evan: A little bit, I've always liked roll ups, plugin interface better than webpacks. Not saying that Webpack is bad. Just Webpack is fundamentally a much more complex architecture. Webpack was designed to be fairly flexible in some ways, almost too flexible. And in order to cater to that flexibility it's pluggin API and loader system had to be designed with that complexity in mind. So this complexity just explodes when you have all these different pieces fitting together. Whereas in, in roll-up I think I mean, Rich Harris always has the knack of designing something that's really straight to the point. I think that sets a really good foundation for roll-up and by extension to Vite. So Vite's pluggin API is on super set of roll-ups, which has proven to be working really well for us so far.
Justin: Yeah, I thought it was a huge advocation for Vite and its success when Rich said, "Hey, you know, instead of building our own thing for svelte kit, we're just going to use Vite. It's like, this is good.
Evan: yeah. They were originally using snowpack, but but I think integration with rollup definitely.earned some point in his evaluations, because I mean, he created roll-ups so,
Justin: Sure. yeah,
Evan: yeah,
Justin: I'm sure.
This is a little bit of a side, but I am curious to get your take on something.
[00:21:05] Getting Inspired by Other Frameworkds
Justin: Have you have you been following any of the development of Astro? The thing, the snowpack team that we're working on?
Evan: yeah, yeah, yeah. I looked into a little bit, I think it's interesting. I, in fact I've always so in my backlog there's always been something that's related to the more efficient hydration. So some of the concepts that Astro kind of promotes say like partial hydration Vite press currently does that to a certain extent. , and in fact technically right, because Asheville is framework agnostic Which means it's not creating something that these frameworks cannot do. So it's more about how you can leverage frameworks with a certain type of setup or constraints so that you make this kind of thing natural. I think that's the value that Astro is providing.
So that's where it's the role of meta framewords fit in, right? It's Naturally leading you into a paradigm that yields good results for specific type of apps. Which means if you using Vite press, in fact, if you say you render a Vite press page and just remove the script tags, it's it also works, right?
So if you want it to use it as a pure static SSG, it also works. But there are definitely some interesting ideas that I see in Astro, like different hydration strategies for these components. In fact, I have in the backlog say in Vue components right now we already support cosplaying during SSR.
So, you can have an async component and if it's loaded on the current page, it'll just fetch it and then continue to hydrate. But we can add something like hydration strategy when you were defining a nice in components, say this async component should only fetch and hydrate when it's coming into the viewport. So that seems like a very low intrusive newness API to just add it's very additive, but it gives you this very fine grain control, like basically gives you lazy hydration for free. And then there's also a different kind of strategy where a more compile time based strategy where you say in Vue files, you can have an extra script block saying basically like script client only then say, okay, this part of code only executes on a client and it doesn't have the run time.
You can only use raw JavaScript basically on the client. We're not loading Vue anymore. So you're using Vue purely for server side rende ring. So you are just generating your whole template or your whole app using Vue on the server side. And then only those more explicitly client side scripts will be put, together and then bundled for the client side.
So this this is basically saying, I still want Vue's templating system, but only on the server side.
So there are a lot of interesting ideas that we can explore here now because of Vue is fundamentally also compiler powered, right? I think a lot of people are they find svelte interesting because is best known for this completely compiler driven strategy. But what they don't, a lot of people don't realize is Vue is also, Vue three specifically now, is also very, very heavily compiler driven. It's more like a runtime and compiler working together kind of thing. So we yeah. Use the compiler to generate more efficient virtual Dom at runtime.
So if you see our 3.2 benchmarking numbers, it's pretty much on par with svelte in the JS framework benchmarks and the single file component, obviously it's the new scripts that are feature is also heavily compiler based. We're doing a lot of compiler transformations to make the code just the authoring experience, more ergonomic.
So that means in terms of the server client hydration story, there are also a lot of room to explore here.
Andrew: Yeah, that's super interesting. Compile away frameworks definitely seem like the future. That feature you just mentioned where like you can have client side only JavaScript like that. That would be a godsend when I'm writing next JS applications. Cause you have to jump through hoops to like only run stuff client side. But if that was a part of the framework, that'd be cool.
Evan: Interestingly next allows you to easily do server only stuff, but but when you, so I think remix has that sort of design that allows you to basically do JavaScript free by default only. But I don't know. I think remix is either no JavaScript at all, or you opt in to have full JavaScript so there's no kind of middle ground.
I think it's possible for something like, I think Astro is the middle ground where you I guess the thing as a drawback of Astro that I think that's hard to avoid is even though it's partial or lazy hydration still, if you're using a framework you're still going to be pulling in the whole framework, the moment some hydration is needed.
Right. So, and this means. It's probably performs best when you're building largely static sites. If you're building anything that has a decent number of interactivity, then the hydration benefits wouldn't really be that obvious. So I think it, this model kind of fits a specific type of asset better.
But that also means a framework like vue has the potential to reach into the more static side and come up with something that allows you to still use the familiar paradigm, but then you can build a site with there very little JavaScript on the client.
Yeah,
[00:26:29] Creating Vite
Andrew: So we've talked about Vite a little bit, but for our listeners who may not know exactly what Vite is, could you explain a little bit,
Evan: Yeah. So, so it's pronounced Vite
Andrew: okay. Oh, sorry. Sorry.
Evan: It's a French word for fast. Vite is essentially what you could use to replace say, create react app, if you're familiar with that. It's not a strictly equivalent to Webpack because you need to configure Webpack with a lot of loaders to be able to actually just build something by state today's standards.
So Vite it gives you a whole solution to build an app with a lot of conventions built in, like it handles TypeScript out of the box. It handles post CSS out of the box. Integrates with a lot of pre processors out of the box. The most important thing is during development Vite is a native ESM based dev server.
So. All your modules over native ES modules. So this kind of implies two things. First is modules are only transformed on demand. If you have code splitting, which is kind of important, because if you have a big. You'll be loading a lot of requests. So when you code split, you're only loading a subset of your modules.
So which means when you code split, you are transforming fewer modules during development and that'll benefit your production users too. So it forces you to think about code splitting even at development time. And then Hot module replacement. When implemented over native ESM is very efficient because the model kind of forces, you forces every module to have to be able to invalidate it and transpile independently. And one of the biggest problems, why traditional bundlers often have hot module replacement performance degrading as thier app size grows is just because the amount of code it has to invalidate and rebuild grows as well. But with a ESM based model, the whole transform pipeline forces every transform to think in an isolated mental model.
So there's less chance for you to have this big invalidation graphs when one file changes. And so we We were able to make a lot of assumptions to make the whole work that we need to do when something changes a more straightforward and do less work. So, essentially even when you have a big project, hot module replacement with a Vite project typically stays constant.
It's almost always an instant. And then during production, obviously I mentioned it's built it's based on rollup which has been rock solid in fact and because roll-up was designed to be ESM first, so it's like a natural fit for ESM only dev server. Right?
Some of the challenges when we built Vite was really about handling all these existing common JS dependencies.
That's probably the biggest headache that we have to the deal with. Luckily esbuild came to the rescue because it's blazing fast and it also handles common JS to ESM conversions. So, we essentially use a strategy to say, okay, your dependencies, they don't change. So we're going to use yes, bill to just pre bundle them when you start the dev server and we catch them as long as your lock file didn't change on the next service startup, we don't need to do anything anymore.
The only thing that may change is your source code. So we'll load them over native ESM and you'll have hot module replacement. So your edits are always going to be extremely fast. So that's the premise and it's not without its drawbacks. The primary drawback is when you have a lot of requests that say like a thousand requests it can take a lot of time.
It can congest the network, even on the local host. But luckily, most apps don't really reach that kind of stuff. And also if you have an app with thousands of modules, you probably want to code split anyway to limit at the number of modules your loading for a certain route. So, in practice most people that we heard that migrated from Webpack based stack to Vite report, huge gains in terms of both service startup bell time and also hot module replacement time.
Justin: Okay. So, I guess, going back to the Vue loader and web pack and everything so I'm assuming that you had to build like, rebuild some custom integration for Vite, I guess for roll-up plugins and everything to handle like Vue single file components and
Evan: Yeah.
Justin: that.
Evan: Luckily we already had a rollup pluggin for Vue files. It's built by one of our core team members. So I essentially took that over then restructured a little bit to fit. I guess the special part we added was really handling the hot module placement because that is Vite specific. Roll up doesn't really have this concept of how much replacement but the cool thing is we built the dev server in a way it is compatible with most roll pluggins. It's not actually running roll up. It can actually use rollup plugins. So that's pretty cool. and shout out to Jason Miller because we got this idea from WMR. So he implemented this sort of rollup plugin, compatible, fake runtime. We called it plugin container. So he first did this in WMR and I was working on the zero point, something around that time. And I saw this, I was like, I want to use Rollup for bundling so why don't we support plugins during dev too?
So essentially we use the idea and then did the kind of evolved into this like isomorphic roll up based setup.
Andrew: Yeah. So I got one last question. This one's an easy one. Where does your V naming scheme come from? Everything you produce has a V at the start what's with that man
Evan: Oh, it's really random. So the original name for Vue was made because I was looking at the, trying to name the library. It was was originally just a view layer library and I was like, oh, discard view JS, but know, the English word just didn't have the kick it's it felt too ordinary. So I put it into Google translate.
I'm like, wow, French translation looks good. So that kind of stuck. And so when I pick the pick new names, I'm like, can we go along the same route? So you're just like looking through the French dictionary. You look all the V starting words.
And I was like, oh yeah and Vite was not taken on NPM I was like wow, great. Oh wait. Actually. Yeah, it wasn't right. Unfortunately the the Twitter handle was taken, so
Justin: Well,
Andrew: can't want them all.
Evan: yeah.
Andrew: Okay, cool. So time to go to tool tips,
[00:32:52] Tooltips
Andrew: So my first tool tip of the day is a issue management tool called Linear. I've used many task management tools in the past. And before Linear, I was always like GitHub issues, that's the best. I don't want to use JIRA. I don't want to use whatever the hell you want me to use. GitHub issues words the best. But in using linear, I've come to like how it works a lot.
It's super fast. It links your issues really well. The project tracking is pretty cool. I've enjoyed that. And they've been pretty quick to respond to all of our feature requests here at Descript. So big shout out to them.
Justin: I actually did a little bit of work with the linear team a while back. One of the founders came and gave a talk at artsy where I used to work, but the founding team in particular they're like super good.
Really, really good. So it was, this is just such an awesome thing. It's offline first, which is great. You can like use it on the plane. I don't know. It's quality.
Andrew: Yeah, I heard that they created this because they were tired of GitHub issues. So I kind of liked the evolution since GitHub issues itself was built because they hated using JIRA and they're like, we need something that's more streamlined. So it's just like evolution from, we hate JIRA to, we hate GitHub issues to now we have linear.
What do you guys use for your projects? Evan, all GitHub issues?
Evan: Yeah, I just use GitHub. So, because I get way too many notifications, so essentially turn off most of them, then I have quick, like bookmarks to the most. So I cycle between the projects during like focus periods. So essentially if I'm focusing on vue-next this week, I'm going to check vue-next issues every single day, but I'm going to ignore the other repositories for now, then next week, maybe I'll switch to something else.
Then I would just focus on that repo alone. Yeah. Otherwise there's no chance of getting any work done.
Andrew: Yeah. Too many fires everywhere.
Justin: Yeah. that's a good one.
So thing I have to share, or first thing, I guess, I actually saw this on hacker news. I feel like I've stumbled across this in the past. And Evan mentioned it earlier, actually there's a meta frontend language called IMBA. So I think it was originally like inspired by Ruby ish syntax, it's pretty clean. I like it a lot and evidently pretty fast. So it is a language that is specifically designed to build front end applications. It reminds me a bit of another language in this category called mint. Same sort of thing, a language designed for front-end applications. So, Yeah. I don't know.
I really love not only the language, but their site and how they present the language is really, really well done.
Evan: Yep.
Andrew: So it like combines like all parts of web app development and to just like one unified language.
Evan: Yeah, reminds me of Elm a little bit, but it seems to be I don't know less about the strict functional paradigms, but more a pragmatic in a sense. Yeah, it is really polished because I know this project from very long time ago, in fact the because they are the founders of scrimba, which is a screencast platform and we've talked in the past.
They actually have some vue screencasts on their website as well. But yeah, this is a really impressive project.
Justin: Yeah. I think it's been going on for like seven years now. So, I mean, it's been sort of put through its paces and stuff,
Andrew: oh yeah. Seven years. It's pretty well versed at that time. Has a very interesting syntax.
Justin: yeah.
Evan: Yeah. In some way, it's almost like too terse things in some cases, but but like I imagine if you get really, really familiar with it, the predictivity is probably really, really great. Yeah.
Justin: back when I first started using Vue, I was using stylus, pug, coffee script, back in those days.
Evan: Okay. Yeah, so, VitePress, so obviously I'm promoting my own stuff here, but but if you've used VuePress in the past, you should probably consider looking into VitePress. It's still early but Vite's docs is built with VitePress and it performs really well. I actually was curious cause I was checking out Astro's docs and they were comparing some of the performance of different static site generated websites using lighthouse scores.
And so I ran it on the Vite docs and turns out it performs really well. Even though we're doing a full hydration of Vue 3. It's actually a Vue 3 single page application, but on a Moto G4, which is emulated with 4x CPU throttling. It's like 98 on lighthouse in terms of performance. But yeah, some of the interesting stuff is essentially you can it's a Vue power to static site generator pretty much.
Right. But it's very lightweight. It gives you everything that Vite has essentially. So you can build your whole theme using everything that you can support. Although, I mean, the internally the theme must be a Vue app. So that's the limitation. If you use vue it is what I would definitely recommend as the static site generator. Some of the interesting, pretty unique stuff that we do is you can actually freely mix Vue components or any Vue syntax inside your markdown because the markdown is actually first converted into HTML, then compiled as a Vue component. Which means even in some markdown you can even use script tags to import other components, then use them kind of like MDX.
Right. But the benefit over MDX is that when we compile this, the Vue compiler will essentially separate all the static markdown parts and the dynamic components that you're using. So on the page, hydration, all the static parts are automatically skipped. So you get essentially gets selective hydration by default.
And if your whole markdown file doesn't contain any dynamic bits, it's just one big, there's no hydration to be done. So it's completely skipped. We also do some pretty interesting optimization. So when you first load a page, right, if you use MDX, you're loading the generated HTML and equivalent react vendor function generated from the MDX file.
You're loading the content twice, but in VitePress you're only loading the HTML because we actually ship dual bundles, a one version of the page that has all the static parts stripped out. It's only the dynamic bits. So on the initial load, you're only loading the static HTML and the JavaScript for the dynamic bits and then on subsequent navigation.
So we navigate to a new page. We will fetch a different version of that page JS chunk, which actually contains the static content as jobs as playing JavaScript strings. So, so essentially you get the ideal loading performance without duplicating the same content twice. While still being able to mix any dynamic stuff inside your markdown..
So, it's really neat for building demos. That's interweaved inside your markdown content.
Andrew: Yeah, this seems like a natural extension on top of how you already write vue. Whereas MDX is like this whole new thing requires all this other tooling. It seems like with this, you can more fall back on what you already built.
Evan: Yep. Yeah.
Andrew: This is a little tool. That's got me out of a lot of sticky situations. It's called yarn de-duplicate. One of the big problems that I've had while maintaining huge repos is that you like, especially with TypeScript, you might get two version of their react types in your repo all at once. And really the problem is just cause as you've been adding dependencies over time, you're yarn lock. We'll get multiple entries of the same dependencies that could actually be satisfied by one dependency rather than two. But because of how the lock file works, it locked to the first version in and it locked the second version in.
So this tool allows you to do is it's an easy to run terminal command where you can say, "Hey de-duplicate my yarn lock file to where there aren't multiple versions" and you'll end up fixing a lot of issues with like TypeScript and babel. This is like a, one of my main go-tos when fixing weird dependency problems.
And it has a flag where you can say just target the Babel scoped dependencies. So it's super useful and it's very quick.
Evan: Yeah, I guess this is faster than removing node modules and yarn lock, then reinstall everything from scratch.
Andrew: Yeah. Before this tool, I would hand edit my yarn lock files and be like, oh, that th th those two can are obviously the same thing and obviously the same dependency range, and then just edit their weird little syntax, but this is a lot better and a lot faster.
Evan: yeah.
Justin: So you use this at Artsy quite a bit for getting our Docker image sizes down, because you'd be surprised at how much disc space is wasted on duplicate dependencies that are. And we had some pretty significant reduction and our Docker images.
So, uh, This is both an article, but also introducing a library. So, James Long who has uh, this budgeting app and I forget the name of it, but he's been working on this uh, application for a long time and it's like pretty high quality. He had wrote an article a while back about using conflict free datatypes to synchronized client and server state. Uh, CRDTs. So yeah, it was a really interesting article and I've been falling and stuff for awhile and he just put out this article about the future of web SQL which essentially describes running a SQL Lite database in the browser.
Now there's already a, library out there called a SQL Lite JS or SQL JS or something. Which essentially does that, it runs SQL Lite in the browser. It's a compiled to WebAssembly. So it's actually running the actual SQL Lite thing, but generally it's just running in memory. So it has no way of persisting the things that you put in that database, but he essentially, in this article is describing how he built out a IndexedDB storage engine for this.
And an adapter interface so you can actually have other storage providers if you want. But doing this was actually significantly faster than you using IndexedDB on its own. So really, really interesting results came out of this. So If you ever had the need to store a lot of data in the browser and you really don't want to work with IndexedDB because it's a Royal pain in the butt then this is a really, really interesting approach. And the library that came out of it's called uh, absurd. SQL.
Andrew: Great name for a library.
Justin: Yeah, this is just, it's just so fascinating.
Andrew: WebAssembly is changing the game.
Evan: So, last thing is a thing called volta. So I guess this is similar to linear. It's also a GitHub sort of management tool. So this is built by the team behind Nuxt in fact. So, so they built this using Nuxt obviously and I believe they are using this to build Nuxt three themselves.
Yeah, essentially a, another GitHub issue management tool for open source maintainers. I think it's still in beta status. So, I haven't really used it for long enough to give like a proper assessment, but I just think it's a, it's an interesting to keep an eye on because I personally feel like this is a space that a lot of maintainers kind of have uh, we've we've all complained about how GitHub's default issue management is kind of a difficult to navigate. The navigation is really don't help that much. So, yeah, I think any attempt in the space to help us to help to make the lives of maintainers easier is always welcome. So, yeah.
Andrew: yeah, this looks nice. They definitely are some tailwind guys though. Every time I see these types of icons, I'm like, Ooh, there's some tailwind.
Evan: Yeah.
Andrew: Cool. I think that was our last tool tip for the day. Thanks Evan for coming on. This was a great conversation. We went through all the V related repositories with success.
Justin: Okay.
Evan: Yeah. Oh, I just realized this thing is also V started. Yeah.
Andrew: Yeah, that continued with your namesake. I Googled it real and quick volta means speed.
Evan: Ah, very nice.
Justin: Nice, nice. nice. I didn't know the French thing. I didn't realize that, but I guess it makes sense now.
Andrew: Yeah, I thought you just futzed the spelling of Vue, but it makes more sense that it's an actual word.
Evan: Yeah.
Justin: Are you still using uh, there for a little while you were using anime names for releases or something?
Evan: Yeah. We're still doing that. Yeah.
Justin: That's fun.
Evan: And it's all alphabetically sequenced, so
Justin: Oh, it was great. Okay.
Andrew: What was the code name for Vue three?
Evan: One piece.
Justin: Nice. Nice.
Andrew: I surprised you ever finished development.
Evan: Yeah, yeah. We finished before the original thing. That's interesting. Yeah.
There are actually some people who have a repo on GitHub betting what the code name will be. So, is kind of funny.
Andrew: That's awesome.
Justin: Some insider trader going on there. You're just like, "Here, slip me in!"
Evan: I don't tell anyone before I, until I do the release, so
Justin: Nice. Nice.
Andrew: That's it for this week's episode of DevTools.fm, be sure to follow us on YouTube and wherever you consume your podcasts. Thanks for listening.
Evan: Bye.