Vite and the Future of JavaScript Tooling

So, hello, everyone. My name is Evan Yeo, and I'm here to talk about Vite and the future of JavaScript tooling. Okay. So, many of you have probably heard of Vite. In the past few years, it's been growing really fast. We're now seeing 29 million weekly NPM downloads and more than 1.1 thousand GitHub contributors. We have a vast ecosystem of tools and frameworks building on top of Vite, including some of the most familiar tools. Companies are using Vite or Vite-based frameworks in production, including some of the biggest names. Today, Vite has become the shared infrastructure layer for the next generation of web applications.

We've been thinking about what we can do to make Vite serve its role better. Vite is far from perfect in its current state. The biggest problem we saw was that Vite relied on different dependencies with overlapping duties. Vite wrapped third-party dependencies, including ES Build, Rollup, and sometimes S3C for transformation. Many of these tools have overlapping duties, are in different languages, and have efficiency problems passing data between them. So, we decided to build a bundler called Rolldown specifically for Vite's goals. As we worked on Rolldown, we delved deeper into the stack and realized the challenge Vite faces reflects the fragmentation in the JavaScript ecosystem.

When looking at the lower-level dependencies a bundler needs, we see fragmentation at every layer in the JavaScript ecosystem. For parsers, transformers, test runners, linkers, formatters, there are numerous solutions leading to decision fatigue. The lack of central guidance in the JavaScript ecosystem allows freedom to explore. The ecosystem is vibrant and active, but the abundance of options can overwhelm newcomers to JavaScript development. This diversity, while challenging, also provides space for innovation and exploration.

But as we are looking into the work on Rolldown, we started digging deeper into the stack. We realized that in order to build a bundler, we need to also pick and choose what parser we use, what AST we use, what transformer we use, what minifier we use. And when you go down the rabbit hole, you realize the challenge that Vite is facing is really a reflection of the JavaScript ecosystem at large. So, if we look into the bundler and look at all the lower-level dependencies that a bundler needs, we realize that the JS ecosystem actually suffers from fragmentation at every layer. So, for parsers, transformers, test runners, linkers, formatters, all the things that we use at every layer for every task, there are so many different solutions. And it just leads to a lot of decision fatigue. And for the average user who are just getting into JavaScript development, it's probably not the easiest task to decide which one to use.

This is not all bad, right? The JavaScript ecosystem was probably one of the most vibrant ones, the most active ones. And this sort of lack of central guidance results in a freedom to explore. And the abundance of choice was critical for the ecosystem in the early days. These solutions are what helped us to get where we are. We're building more ambitious JavaScript apps than ever before, and these are the tools that helped us get here. But as the language matures, as we arrive on a lot more consensus and conventions on some of these problems, this has led to a complexity tax for everyone. So, I believe it is now a time where JavaScript deserves a unified toolchain.

So, we've been hard at work on this goal at VoiZero, which is a company I have founded. And the mission of the company is really to build a unified JavaScript toolchain to give users a more coherent stack, a coherent experience when we want to just get into it and stop thinking about picking and choosing a bunch of different solutions. There are four major open-source pieces that the company works on, including Vite, Vitest, Rodan, and RxC. At the very top are the framework tools that build on top of the Vite ecosystem. Vite itself is obviously the integration point. Many of these frameworks also use Vitest. Vitest can be used alone in any JavaScript project. You can use it to test backend code. Many projects that are not even using Vite would also use Vitest. So, Vite and Vitest inter-ops more directly with frameworks and end users. And Rodan is the bundler that supports Vite internally. It handles some of the more low-level tasks of bundling your code, optimizing your code, and giving you advanced chunk splitting, etc. At the bottom layer, RxC is the language toolchain that supports all of the higher-level pieces. RxC itself includes the parser, which is at the core. The parser also defines the AST that we use for all these other tasks, such as transformation, linking, formatting, minification, semantic analysis, etc.

The parser also defines the AST that we use for all these other tasks, such as transformation, linking, formatting, minification, semantic analysis, etc. OXC also ships a resolver that is Node.js compliant. The minifier currently is in alpha status. It is already usable. And the formatter is still a work in progress. So, by combining all of these pieces together, we also are working on a solution called V+. So, V is meant to be the end-to-end toolchain that integrates all of these things together in a more coherent package.

Why Rust? If I haven't mentioned it before, everything in the lower-level pieces, both OXC and Rodan, are written in Rust. We picked Rust because it provides a good balance between performance ceiling and memory safety. And more importantly, it already has a very active ecosystem around JS tooling, so it is easier to find libraries and contributors. It has very mature JavaScript interop through the excellent NotPIS project. And it also has very mature WebAssembly support, which allows us to, for example, compile Rodan into WebAssembly and run directly in the browser with great performance.

We're not trying to Rustify everything. We believe that there is a good abstraction layer where Rust is really good at for the more well-defined and perf-sensitive tasks, for example, transformation, parsing, bundling. But for the CLIs, for the high-level APIs that interface with the user, we believe it requires constant iteration and flexibility, so JavaScript slash TypeScript is still the tool of choice for those layers. In OXC, we have completed the parser, the linker, resolver, transformer. The minifier is currently out of status, but already usable. It actually has pretty decent performance characteristics. Most of these things that we have built are the fastest in its own category, even compared to other solutions also written in native languages. The parser, the linker, the resolver, transformer are all fastest in category. The minifier is second fastest, but it also has better compression ratio than the fastest solution. So it is still a very decent choice. Also, because the minifier is still in alpha, we actually have plans to further improve the compression ratio in the future. Some additional transformer metrics. We focus a lot on optimizing the memory usage and binary size, too. So it also shows great performance in these areas compared to other solutions.

So stay tuned. Some additional transformer metrics. We focus a lot on optimizing the memory usage and binary size, too. So it also shows great performance in these areas compared to other solutions.

And now onto Roldown. So we have been working on Roldown for almost a year and a half now. Roldown is now in 1.0 beta status, which means you can already use it almost as a drop-in replacement of Roldown, and you'll see great performance improvements. We have completed not just basic bundling, but also integrating OXE, which means Roldown comes with built-in transforms for TypeScript, JSX, common JS transformations, comes with built-in node-compatible resolution, which means you don't need plug-ins for that.

This is much bigger in scope compared to Rollup, where a lot of these features require external plug-in support. We also complete a lot of advanced features in the bundler, including tree-shaking, define-inject, these are features presenting ES build but not Rollup, and then advanced chunk-splitting, which is something a lot of people like in Webpack, but it's not present in ESbuild or Rollup. This is indeed implemented in Roldown. We also implement a multi-federation support as well. We have also invested a lot of effort into behavior alignment with ESbuild and Rollup.

We actually run Roldown against ESbuild and Rollup's test cases to get as much coverage as where applicable. We also support Rollup plug-ins out of the box, with a 90% interface compatibility. The majority of Rollup plug-ins will work inside Roldown, making it a Rust bundler that supports JavaScript plug-ins. Roldown, now in 1.0 beta, outperforms ESbuild and other Rust-based bundlers in terms of speed. The integration of Roldown into Vite is currently a primary focus, enhancing Vite's performance and functionality.

Comparing Roldown's performance to ESbuild and other Rust-based bundlers showcases Roldown as one of the fastest bundlers available, especially with multiple cores. The ongoing integration of Roldown into Vite involves replacing ESbuild, Rollup, and SFSC with Roldown. This tailored integration allows for dedicated optimizations to meet Vite's specific requirements. A future release will offer an opt-in for Bundle mode, addressing performance bottlenecks in large applications during server startup.

Early adopters of Roldown Vite have experienced significant performance boosts without any code changes. Projects like ExcalaJAR have achieved a 16 times faster build by transitioning to Roldown Vite. The transition to Roldown Vite is seamless, offering substantial speed improvements without conflicts. The impending official release of Roldown Vite is expected to provide enhanced performance and efficiency for various projects and users.

So this means now it's a vertical stack that Roldown is specifically designed for Vite, which means we can ship more dedicated optimizations to cater to Vite's needs. In a future release, which is also currently a work in progress, we will also ship a version of Vite that provides an opt-in for Bundle mode. Vite's dev server uses unbundled ESM, making things super easy and flexible, enabling hot module replacement implementation. However, this approach can introduce performance bottlenecks for large apps that need to load thousands of modules upfront, creating a network bottleneck and slowing down server startup.

Full bundle mode is designed to address the network bottleneck issue during server startup, particularly for large single-page applications experiencing page load problems. The initial design of full bundle mode targets improving dev server startup performance. Phase one of this mode is already available, providing a solution to the performance challenges faced by large applications. Early adopters of Roldown Vite have effortlessly experienced a significant performance boost without any code changes, with projects like ExcalaJAR achieving a 16 times faster build by transitioning to Roldown Vite.

Transitioning to Roldown Vite offers substantial speed improvements without conflicts, with varying levels of performance gains depending on project configurations and custom plugins used. Projects with complex setups may observe 2 to 3 times faster builds, while pure React applications could experience more than a 10x speed improvement. The ongoing development of Vite+ aims to create a comprehensive toolkit akin to cargo in Rust, enhancing and expanding Vite's capabilities. Upgrading to Vite+ from Vite will be seamless, allowing for a more powerful command-line interface while maintaining backward compatibility with the existing Vite functionality.

So notably, adopting Roldown Vite is extremely easy because it requires no code changes. It is a dropping replacement. So we have seen projects like ExcalaJAR switching to Roldown Vite and get a 16 times faster build by simply swapping out the NPM package. So no code changes, no conflict changes, really. It just gets 16 times faster. And depending on how your project is configured and depending on the number of custom plugins you use, you will see varying levels of performance gains. But at the minimum, you should see like 2 to 3x faster builds. These are probably the most complicated applications with tons of custom plugins. But if you are building, for example, a pure React app, you'll likely see more than 10x faster builds.

Now let's dig a bit into Vite+. We mentioned this a bit earlier, and we're still actively working on this. This is in very, very early stages, so I'm mostly talking about something that's going to come out in the future, but I want to give everyone a sort of sneak peek at understanding what we're building towards. The idea of Vite is what we want to build conceptually cargo for JavaScript. If you have worked with Rust, you probably know that cargo is the all-in-one toolkit toolchain that can serve most of the development workflow needs during a Rust development. There's nothing like that in JavaScript, and Vite is exactly what we're trying to build to fulfill that role. Interestingly, we want to design Vite as a dropping upgrade of the existing Vite.

Which means, if you are using Vite directly today, upgrading to Vite means you also just point use your packed manager to alias Vite to Vite+, and you're good to go. Everything that works in today's Vite will continue to work exactly the same way, but the Vite command line just becomes more powerful. Now it comes equipped with additional commands like Vite's lib that is dedicated for library bundling, Vite test and bench, Vite linked and format, Vite new for project scaffolding, Vite task for monorepo task orchestration, and Vite build caching. It comes with the GUI dev tools, it comes with workspace audits and policy enforcements for enterprise users, and will also likely ship AI integration with the built-in MCP server. So, I want to dig a bit deeper into some of these commands that I talked about, for example, Vite lib.

Library bundling is an interesting topic because Vite currently ships with a Vite library mode, which not many people actually use it because we have sort of held back in investing into the command due to library bundling actually being quite a complicated topic in itself. The behavior is quite different from bundling applications. That's why it needs a dedicated command or a mode to handle it. So we recently started, we recently moved TS-down, a project by Kevin Den, into the scope of Voice Zero and the Rodown organization. So TS-down is now the official library bundler based on Rodown and it is also the successor to TS-up, which is a wildly popular library bundler, which is now no longer active maintained.

The interesting thing that TS-down does is it comes with built-in TypeScript DTS generation and bundling. So there are two important things here. One is you can enable isolated declarations in your TS config to let OXC generate your individual DTS files without going through TSC. This makes the DTS generation process a pure syntactical transform, which is orders of magnitude faster than generating it through TSC. Second is we also implemented and shipped a plugin called Rodown Plugin DTS that uses some custom techniques to be able to bundle your DTS into a single file, so that it not only reduces your package distribution size but also makes the consumer of your package be able to type check your library faster because TypeScript works better when it has fewer files to work with. So it also handles a lot of conventions like multiple output formats, export conditions, patch manifest correctness, linting, etc. And this will be integrated into VitePlus as its library mode.

A bit about testing, right? So ViteTest is going to essentially be the Vite test command in VitePlus. ViteTest now is probably the most feature complete JavaScript test runner. Initially, ViteTest was born as a sort of replica of Jest with the same API, but designed for Vite. But now it comes with a lot more, so it comes with browser mode, component testing, and even benchmarking features. One important thing I want to mention here is when we are evaluating test runner speed. There are some test runners, for example, BounceTestRunner by default runs the commands, runs each test without isolation, so a lot of these tests actually share global state, which means it's not technically safe. So if a test mutates global state, it can actually impact the results of other tests. ViteTest opts to be safe by default, so all the test cases are isolated, forced to be isolated by default, which makes things, you know, there is a performance overhead for this, but we opt for correctness over performance in this case. You can disable it if you want, but we recommend turning isolation off. Linting and formatting. So OX-Lint handles the syntactic linting, and it's 100 times faster than ES-Lint. The rules are not as complete, and we're currently working on a JavaScript plugin system for OX-Lint, so you can write custom plugins for OX-Lint and potentially be compatible with some popular ES-Lint plugins. But in OX-Lint itself, we have already ported a majority of the rules in some most of some of the most popular plugins. Another important topic that we're researching right now is type-aware linting. There are multiple ways to do this. There are different projects, for example, Biome, exploring different directions, but our current short-term approach is likely going to integrate TSS-Lint together with OX-Lint to serve as the lint command in B-plus. So TSS-Lint actually integrates TSC type check paths to implement linting rules during the type check, so you only pay the TSC cost once instead of running it again in your linter. We are also actively looking at the TS-Go implementation and checking out how we can implement an efficient Go-Rust interop, probably using SyncRPC, so that we can hook into TS-Go diagnostics in our linting to perform the type-aware linting with the best performance.

And then there's stylistic rules and formatting, which is currently in the works. That's going to go into the format. And B-plus is going to be monorepo aware, which means we will have pipelines, build orchestration, caching, similar to that of TurboRepo, and we'll have first-class constant workspaces and policy enforcements.

There's also going to be a very good GUI dev tools. If you've used Nuxt, you've probably seen Nuxt dev tools, which is made by the prolific Anthony Vu, who is now working on the dev tools for B-plus. And then there's the single source of truth config that is shared across the entire repo for all your commands. So, module resolution, transforms, respecting TS config, they should all work consistently and the same across all these commands.

Finally, you want to position B-plus as a framework for frameworks. So if you're active in the meta-framework space, you'll see that there are many frameworks now going with the framework as a V-plugging route. Remix router, a Remix React router, Ten-Stack Start, Redwood SDK, are all going towards this direction. And it's a very smart way of leveraging V-plus and, you know, the future features in V-plus as well. Because in the future, when you ship your framework as a V-plus plugin, you'll be also able to hook into these additional commands. So you can do things like inject linked rules, inject custom test masters and environments, inject dev tools panels. The possibility is limitless when you have the full tool chain accessible through the plugin interface. That said, V-plus is still a work in progress. We're in the very early stages of it. So if you're interested in having feedback, please holla at void0.dev, hello, and we're eager to hear your feedback. Thank you.