Vite: Rethinking Frontend Tooling

Hello, everyone. My name is Evan Yeo and I'm the author of Vue.js and Vite. Today in this talk, I'm going to be talking about Vite, a next-generation build tool that I've been working on earlier this year. Specifically, I want to discuss some of the design tradeoffs involved in creating a new build tool, why we want to do that, and what is involved.

What is Vite? Vite mainly consists of two parts, a no-bundle dev server that serves your source files over native ES modules, and a production bundler which is rollout-based, is pre-configured and produces highly optimized production builds. Why would you want to use Vite over an existing tool? First of all, it's lean and fast. Really fast. We'll see an example soon. Second, it's opinionated with very sensible defaults. It's based on the experience that I've been working on Vue CLI, which is a very widely used build tool for Vue specific projects over the years. Similar to a pre-configured Webpack and Webpack Dev Server setup. It's also quite similar in terms of scope to Parcel. Many common features like TypeScript, JSX, and PostCSS work just out of the box. Despite being opinionated, it's still very extensible. It has a Rola compatible plugin interface that makes it very easy to build on top of.

So, just to get an idea of how lean it is, here is a tweet of someone running create react app and Vite side by side on Replit, which is a service that runs your project on a remote container. The Vite project is able to get up and running before the CRA project has even finished installing. One of the reasons that Vite is so lean is because it cares about its own dependency count and payload size. We actually pre-bundle a lot of unnecessary dependencies into Vite itself so that it installs faster. So node modules disk size is often a fraction of that of Webpack-based projects. Here is another example of a user migrating a production Rollup app over to Vite. As you can see, the original start time was over two minutes long and a single reload can take up to 23 seconds. And now both numbers, after migrating to Vite, are down to almost negligible numbers. Granted, Rollup doesn't have hot module replacement. But I bet Webpack users are not unfamiliar with hot updates taking a few seconds in large projects. With Vite, the HMR is guaranteed to be always instant. Now let's dig into what contributes to Vite's performance. Vite builds upon two interesting trends that we have seen in the past year. The first is that modern JavaScript is now widely supported. Native ES modules now have over 92% global support.

And we're only going to see this number increase as legacy browsers like IE11 going out of market at an accelerated pace. The second important thing is there are new JS compilers being written in compiled to native languages. Two of the most prominent examples are ESBuild, which is written in Go, and SWC, which is written in Rust. Both of these tools are dramatically faster than tools that are written in JavaScript. Sometimes up to 100%… sometimes up to 100 times faster, depending on the work type and CPU cores utilized.

So VEED leverages CHORN1 native ESM by building the dev server around native ES modules. There are many benefits of a native ESM dev server. First of all, there's no need to do any bundling. That's a big chunk of work that is simply not needed anymore. Second, native ESM is on-demand by nature, which means if a module is not loaded for the current screen that you're working on, it doesn't even need to be processed. Third, since modules are fetched over HTTP requests, we can leverage HTTP headers and let the browser do the caching. And finally, most importantly, hot module replacement can be implemented over native ESM in a very simple yet efficient manner.

So we'll see if this gives us big performance wins soon, but I want to be honest with the technical trade-offs here. Native ESM is not perfect without any downside. The main problem that we have faced is the HTTP requests overhead. For example, a dependency like Lodash ES may contain over 700 internal modules. And because native ESM is eager, when you import even just the single method from Lodash ES, the browser will try to request all of these modules that's imported in its entry point. Now, every module request translates to an HTTP request and the overhead just adds up. It creates a network congestion and even on local machines with little to zero latency, this overhead is still noticeable.

So, Vite does implement a few tricks to work around this problem. The first is we pre-bundle dependencies with ESBuilt. There are many big dependencies like Material.UI that contains hundreds and even thousands of internal modules. But they don't change often. They mostly contain standard JavaScript that doesn't need any special processing, unlike your source files. So, this makes them the perfect candidate to be pre-bundled with ESBuilt. By pre-bundling them, we can ensure that each dependency translates to only one HTTP request at most. And since ESBuilt is so fast, the starter boost is often dramatic, especially when you're using large dependencies. In addition, dependencies don't change often, so we can easily cache the pre-bundled output on disk and skip the pre-bundling phase on subsequent server starts. This process also converts common JS dependencies into ESM so that they are consumable natively by the browser. On top of that, pre-bundled dependencies can be strongly cached with HTTP headers.

Veach rewrites the imports to dependencies to append a fingerprint query that is linked to the project's log file. So on page reloads, with a strong cache header the browser won't even make a new request unless your log file has changed. How about source files? Since source files may be edited at any time, we have to re-validate with the server on every request. But we can still leverage ETags and the if-modified-since header to make the request conditional as long as the file itself did not change. This ensures performing full page reloads once the module has been processed once.

So here are some important performance trade-offs in VEED's native ESM dev server strategy. First of all, the server start is dramatically faster because there is no bundling needed to be done ahead of server starts. And while there are bundling that's done for dependency files, but they're done with ES build, and they're typically so much faster than JavaScript-based bundlers, you'll still see a huge boost. The very first page load will in fact be slower because the modules, your source file modules are only processed on demand when they are requested over HTTP. Now the request overhead also affects the first page load the most. But overall, if you combine the server start time plus the first page load time, we're still seeing very significant gains in almost all cases. Once the initial load is done, full page reloads are largely unaffected compared to a bundled method. But finally, another really big gain is that hot module replacement in this model is dramatically faster, especially in large projects, because in the native VSM model, HMR performance is decoupled from the size of your project. So even as your project grows bigger over time, HMR performance will remain the same.

We do have some ideas on how to make the first page load also fast by, for example, by introducing a persistent on this cache for source files. Another idea that might be worth exploring is replacing part of the internal module processing pipeline with compiled to native modules. As an example, Parsel 2 recently ported its data processing pipeline to Rust and has seen a big performance boost. So there are potential for us to do the same. But both of these ideas are still in the exploration phase. But we are sure that there are a lot of areas that we can still improve in this model.

So now let's talk about the production build. Some may be asking why even bundle for production if we are using native ES modules? Why not just ship these modules unbundled to production? Well, I don't have time to dig too much into the details here. But the short answer is the performance is not good enough by default. And caching, which is the supposed advantage of unbundled deployment, is very hard to get right. Bundling still seems to be the better trade-off that covers more cases. Another common question is if ES build is so fast, why is V still using Rollup? Why don't we just bundle with ES build? Well, the main reason is that bundling user-facing applications has some really different set of challenges compared to bundling a library, which in most cases is just a single file. Code splitting is very important in delivering performance user-facing applications. As of now, in this regard, Rollup is still more mature and also gives you more flexibility, more control over the chunking process when it comes to code splitting. So this is important both for us, to give you automatic optimizations, and also important for users to be able to manually control the final code splitting behavior. So yes, Rollup is slower than ESBuild, but in practice we found that the actual bundling is only part of the total cost of the real-world projects.

The whole thing itself, the act of concatenating the modules together, is actually not the whole thing. For example, many projects rely on JavaScript-based transforms of individual modules. For example, view or spell single file components, Babel-based custom plugins for CSS and JS, a lot of meta-frameworks need to perform static analysis on source files. All of these tasks are typically still done with JavaScript-based tools, so even when using ESBuild for bundling, you still have to jump back to JavaScript to perform these tasks, and ESBuild won't really help much in these areas.

Another major build time sink is minification. We at Vite in fact support using ESBuild for minification, so you can get slightly faster builds at the cost of slightly bigger bundles, but we still default to Terser because Terser, while being slower, still provides better compression in most cases.

What we get in return by using Rollup in Vite is that we get to do a few things that are currently still hard to do with ESBuild. For example, automatic CSS code splitting. The CSS imported in your async chunks are automatically built into a separate file and are loaded in parallel with the async chunk when they are requested. We also do automatic async chunk loading optimization. When you have waterfalls in your async chunks, we will automatically flatten them for you. You can also do manual chunk split control by using Rollup options. Most of these are not really possible at this moment with ESBuild. That said, Vite is still open to switching its production bungler to ESBuild or something faster in the future if these become possible, which makes the tradeoff worthwhile. Currently we are essentially opting for a slower production build but better performance for end users, which I believe is the right thing to do.

Now, I want to talk a bit about another aspect of Vite's design, the fact that it provides an opinionated and sensible default that gets you pretty far out of the box. If we think about it, Vite is essentially functionally comparable to a preconfigured Webpack setup with Webpack, DevServer, CLI, CSS Loader, Style Loader, PostCSS Loader, you get where this is going. This is not saying Webpack is bad. Webpack started as a JS-focused bungler and it had to be barebones by default and be extremely flexible because we had no conventions back then on how these common tasks should be tackled by a build tool when building a user-facing application. So we had to invent these things over time. It is remarkable that Webpack is so configurable that we're able to actually do all of this with it, right? But over time, we've also come to realize that 90% of the higher level tools built on top of Webpack contain a large amount of configuration addressing the exact same problems over and over again. The way we import CSS, the way we expect TypeScript and JSX to just work, the fact that almost everyone has to use post-CSS, right? These have become conventions shared across tools and frameworks, across ecosystem. So Vita acknowledges this. So it tries to absorb the complexity of getting these conventions working out of the box so the end user can focus on the things that actually matter. We also realize that conventions don't always fit every single use case. So V's philosophy here is that we optimize for the 90% happy path. While advanced use cases are still made possible via plugins, it should not be a requirement for the majority of use cases. So it's also okay that V doesn't cover everything. It's not V's goal to completely replace Webpack. There are cases where Webpack is still the right choice. For example, if you need module federation. It makes sense for different tools to coexist and fit different roles in the ecosystem.

Now, that said, V still gives power users a lot via its powerful plugin system. So V's plugin system, what we call its universal plugin system, is shared between the dev server and the production build. It extends upon Rollup's very straightforward plugin interface. It's a superset of Rollup's plugin API. With additional capability to control the dev server behavior, you can add middlewares. You can add custom routes. You can also tap into the HMR pipeline. And finally, when a file changes, you can modify how HMR works. So this gives you very fine-grained control over the whole dev experience.

In addition, Vite also provides an API to load ESM source files and instantiate them in Node.js. With module replacement like pre-system validation. Typically when we do server-side rendering with a bundler, we are essentially running two bundles side-by-side, one for the client and one for the server. So when you edit a file, we actually rerun both bundles. But in Vite, on the client-side, we do HotModule replacement over native ES modules, and on the Node.js side, we actually keep the instantiated copies of these modules in memory, and only invalidate the ones that are affected by your code changes. This is almost like server-side HotModule replacement, which is very efficient. And this also makes it very easy to create a performance server-side rendering dev setup with Vite. Now, it can be completely decoupled in production, so you don't have to use Vite in production for server-side rendering. And the result is, we are seeing a plethora of SSR metaframeworks built on top of Vite. There are SvelteKit, Ream, which is a server-side rendering framework for Vue 3. There's ViteSSR and VitePluginSSR, both are framework-agnostic SSR extensions on top of Vite. And we're seeing frameworks like Markel, essentially using Vite, which is actually able to encapsulate a metaframework-like functionalities encapsulated inside a single plugin. So this kind of speaks about how powerful the plugin system is.

OK. So Vite is growing really fast, and we're really proud of what we've achieved. But I also really want to give a shout out to the projects, these great projects Vite is built on top of, mainly rollup and ESBuild, both are great gifts to the community. And also shout outs to projects that have inspired features in Vite, Snowpack, WMR, and Web Dev Servers, and Parcel. There are a lot of interesting ideas in each of these projects, especially for Snowpack, WMR, and Web Dev Server. We are kind of exploring in the same space and we share a lot of these ideas. So shout out to them for inspiring some of the features in Vite. And yeah, so I'm very excited to see this new wave of dev tools. We are excited to make the web ecosystem move forward and improve dev experience together. Thank you. That's all. Bye.

Evan has been asking us, do you currently use Webpack or any Webpack based tool, like Next or Nuxt? And well, 52% of you, so that's just over half, has been saying Webpack based tool, so like Next or Nuxt. Evan, what do you think about this? Does this surprise you? Yeah. I guess the poll is a bit confusing because Webpack based plus Webpack adds over 100%. I don't know, I guess this just really shows how prevailing Webpack is in the ecosystem. Obviously it's a great project, but you know, one of the reasons I personally now use Vite for almost everything is because I really miss that really snappy development experience when I first started doing web projects, you know, you just write JavaScript, load it in the browser and just refresh.

Everything is kind of fast, I really miss that. So you'd actually like to go back to that 10% of nothing? Not nothing, right? We kind of want to have a cake and eat it, too. But it should feel like that nothing. That would be great.

So we're going to go to our audience questions now. So if you have any questions, you can still do so in the Community Track Q&A channel.

First question, is there any data already out there for Feats Performance in a large real-world application in production? Yeah. So I just saw this article on dev.to a while ago. Someone migrated a project with 150,000 lines of code. So that's a pretty big code base from I think it was previously Webpack. So they moved to Vite and I'm trying to look at the numbers. So originally, a code start using Webpack was 150 seconds and the app loads in six seconds. So after migrating to Vite, a code start is six seconds and the app loads in 10 seconds. So hot reload went from 13 seconds to one second. And if you put Vite in build mode, the build watch mode is still from 17 seconds Webpack to 13 seconds Vite, so that is actually running a full build on every save. So yeah, I would say you get probably 10 times better performance during dev in this very case. Obviously, it will kind of vary and I think this has a lot to do with how their old Webpack configuration was using probably using full Babel or TypeScript. So they also did compare this by switching from Babel loader to ESBuilt loader for transpilation which did increase the performance by quite a bit. So let's see. So that shaves their speed from 185 down to 56, which is decent, but still not as fast as Vite I would say. So yeah, that's just some anecdotal data, but I think it's a good reference. So I guess the takeaway is Vite does work in large projects and is indeed able to handle that kind of scale.

So if people want to read up on these numbers, can you share this article in the Discord channel? Yeah, definitely. Great.

Next question is from Jean Cartier and he's a bit confused. He says, I don't understand. So we can use Vite for building react applications? Yes, absolutely. So Vite is completely framework agnostic. I originally created because I just wanted to get a faster dev server for myself to use Vue. But as we got closer to feature completeness, I just realized, okay, most of these actually apply.

They're framework agnostic. They would apply equally well for react app or other apps. So, I managed to just, basically, I did a refactor trying to think, in V2, the biggest thing was we extract all the Vue-specific logic out. And that was also a good process for us to think about the plugin API. Because if the plugin API can help, can allow us to cleanly extract all Vue-specific logic into a plugin, then it should work equally well for any other framework. Because Vue, in terms of the compilation setup, is actually pretty demanding. So once we did that, it proved to be quite successful. We're now seeing Spelt, like a lot of people are switching from Create React App to Vite as well. So, yeah. So, I'm pretty happy about that. Because I feel like we put in all the work building a fast app server. Which makes sense for it to be able to help not just Vue users.

And a follow up for me then, do you feel, do you think that because you are so affiliated in your name and so attached to Vue, that might fight against the adaptation of Vite? Because people think this is a Vue thing, because Evan built it. I don't know. I guess, you know, some people are kind of tribal, but I just think if you're a web developer or an engineer, your end goal is to use the tools to build great products for your end users. So why does it matter who created the tool you are using as long as it helps you to be more productive.

Yeah. Yeah. Yeah. Yeah. That's a great, great view. And I hope people will do that. Look at the best tools and, yeah, just use the best tools.

Next question is from Peru, is VITE gonna have some more integrated production build process out of the box, like pre-rendering? If you look at our repo, we have a server-side rendering example. So that example actually already includes a pre-render script as well. It's pretty simple. We're probably not going to do that out of the box. It's kind of a scope thing, right? So you can easily do that yourself using VITE, but it's not something, because it kind of ties into what framework you're using, how you want to actually deploy it, right? So VITE isn't as opinionated as that. We essentially give you the APIs for you to do it in the way you want. I consider that to be a job of the meta frameworks built on top of VITE. I guess filekit kind of does that, REAM also does that. VitePress is a static site generator that we built on top of VITE. So if you're building a doc site, you can use VitePress, which basically works out of the box.

Nice. Next question is from Jack Burke. When is Vite being adopted by Next.js and Create React happen? Make it happen yesterday please. Thanks. I guess if you're using Create React app, you can just switch to Vite directly. I guess there are some parts of the Create React app stuff that's still kind of missing, like Jest support, out of the box. Jest integration has been a somewhat interesting challenge because Jest does not support async transform and async module resolvers. These are the kind of blockers that I think the Jest team is working on. If they are soft, then it makes it pretty straightforward to integrate.

But at the same time, we have other solutions like Sypress, which can run your component directly in the browser. But other than that, I would say Vite is a pretty competent CRA replacer. Like Repl.it actually just switched over from CRA to Vite for all their React REPLs. And as for Next, that's kind of a different story because Next is pretty deeply integrated with Webpack. They do pretty advanced pre-compiling. So I would imagine it would be difficult for them to actually consider a switch. They also just hired Tobias, who is the author of Webpack. So I think they're pretty committed on that path, but I know they're doing a lot of interesting work to make Next fast as well. I mean, Webpack isn't necessarily a dead end. I think a lot of it has to do with the historical burden where people just over-configure it. But if you can, say, use ESBuild for transfilation, have very, very first-party optimizations out of the box like Next does, you can still get pretty decent performance. So I'm interested to see how this unfolds. I mean, in Vue land, Nuxt 3 is able to be bundler agnostic, so they have a mode that can actually run on Vite. I think Nuxt 2 also offers a way to actually run on Vite already. I've heard people who switched over their current Nuxt project to run on Vite, and it just got 10 times faster in development. So, I think it kind of depends on how these higher-level frameworks work. Yeah. Yeah.

All right. Last question we have time for today in the live Q&A is from Yatchna. Beginners can go to Vite instead of React. Is that going to help us to improve our resume? I don't know. Vite is just a tool that helps you build stuff. I think it's more important to actually show what you've built instead of showing what tools you know how to use. Right? Yeah. Yeah. I hope so, too, that employers look at that.

All right. That's the end of our Q&A. But if you have more questions for Evan, Evan is going to be on his speaker room. So there you can continue the conversation about anything you want to talk about with Evan. Oh, you don't have a speaker room. Oh, okay. Sorry. Sorry. Yeah. That was my mistake. My mistake. Sorry. But Evan is available online. You can find him everywhere.

So Evan, thanks a lot for joining us. Thank you. It's been an honor having this Q&A session and announcing you. Hope to see you again soon. Thank you. Bye.