There are so many solid web bundlers that all offer a similar feature set, I am pretty skeptical that another entry is all that beneficial. It's good to have choices, but it's become difficult to keep up with such a fragmented ecosystem. I also admit that I am biased. I started using vite a couple years ago and since then have never run into any serious issues with my frontend builds/developer experience. If the main benefit of another tool is marginal performance gains, I am thoroughly uninterested.
Mako is also a Python templating library. I have used Mako primarily since it was what reddit used to use back in 2016. Not sure if reddit still uses it.
As a side note, I suspect that every pronounceable 4-letter combination has been used as a product name by now at least once. Some unpronounceables must have been used up, too.
It might be fun to generate them and search for them, to test this hypothesis.
Needs a comparison to Vite/esbuild though. The docs only mention Webpack, but idk who's using Webpack on new projects in 2025. There's a benchmark that includes Vite on the homepage, but that's not gonna be enough to get me to switch to a newcomer with a smaller community unless there's some usability difference too.
The CSS support also needs a comparison to LightningCSS (which Vite also supports and has some advantages over esbuild), especially when it comes to bleeding-edge features like view transitions and nesting.
If you use vanilla JS modules you can get away with no bundlers at all which greatly simplifies web projects. import statements "just work" in browsers, and caching of shared modules means you don't need fancy things like chunking. Also no need for map files and such, just debug directly in browser.
Vanilla TS also works well if you use a server side translator like esbuild to strip out the types before serving the files in a middleware (especially if you are using a golang backend, esbuild is trivial to integrate as a middleware)
> Even though native ESM is now widely supported, shipping unbundled ESM in production is still inefficient (even with HTTP/2) due to the additional network round trips caused by nested imports. To get the optimal loading performance in production, it is still better to bundle your code with tree-shaking, lazy-loading and common chunk splitting (for better caching).
For me, Vite has largely solved my js tooling needs. It's definitely cool how far we can go with the platform alone, but for larger applications or publishing libraries, tooling like Vite is a blessing.
That hasn't been my experience. Depends on the caching mechanism used I guess, but if you bake cache busting directly into the URI like I do (i.e. there's a hash digest in the path), the browser doesn't need to make any additional network round trips for any nested imports that have already been fetched - they are all 0ms cache hits. And even if you use a cache mechanism that requires reaching out to the server every time, it's still very lightweight (you'll just get a 304 not modified for any nested imports)
Even if vanilla modules is slightly less optimal than a bundler performance wise, I would still argue the additional complexity (for learning, maintaining, deploying, debugging) introduced by said bundler is not worth the extra cost for most websites.
Due to that caching, you still need some sort of preprocessor to digest the files and generate an import map. Third party modules also add some extra friction. I found that when I ended up pruning out all the edge cases, just bundling it ends up being less work anyway.
If you import a module by its path or URL, it is cached by that path. So if you update a file, browsers that have already pulled that module will get the old version. Getting around this needs some sort of digest. To import that file, you need to either use an import map to get the proper digested file or a preprocessor step to substitute the digested name into the importing module.
I wasn't sure what "based on Rust" meant and looking at the announcement / GitHub etc I think they just mean that it's built in Rust. I couldn't find any commentary on or comparison to the rust language or tooling etc
Then they should write "focuses on fast, modern, and correct", not "written in Rust". There are plenty of strategies (such as programming languages) that lead to those outcomes.
I'm just not quite sure why "speed" is what be js bundlers are selling themselves on. We have a number of fast bundlers already, so that's not what's taking my time. DevEx is the real selling point for me, and that didn't talk about any of their differentiators there
They seem to be measuring things like how long it takes for the dev server to spin up, and how long HMR updates take. I don't think ESBuild offers these features out of the box. I guess it could be in the "Cold build" chart. AFAIK Vite uses ESBuild at least for some of its building, though. node_modules, dev builds maybe. Not sure if it was used in this benchmark or not.
What I want is one of these bundlers and typescript compilers that are written in Rust to be runnable programmatically from e.g. a Cargo build.rs or within a web server in Rust.
I don't want to install your binary separately, and I don't want to use NPM for my project. I want to use my existing build system, and if you wrote it in Rust, it should be made to fit nicely into the Rust ecosystem.
I used to feel that way coming from the Ruby / Rails ecosystem, but ultimately I settled leaned heavily into the "convention over configuration" maxim and try my best to adhere to front-end conventions, thereby following the principal of "least surprise" when it comes to wiring up any oddball bits, bobs, or libraries.
Lots of Javascript libraries come as Rubygems, and they are definitely production ready, but while they're arguably "on the rails" in terms of Ruby devex, they're quite a ways off from—and alienating to those versed in—serious frontend development.
So, even if it's written in Rust, if it's bundling a complex front-end—and if not, do you need a bundler?—doesn't that front-end deserve its own toolchain, in which its source code is respected as first-class? Otherwise, I would stay away from JS entirely, frankly. A brackish estuary is an unfortunate model for software architecture.
We have come to the juncture where hosting a small bit of JS functionality requires a giant swamp^Wecosystem of bundlers, transpilers, packaging systems, and specialized servers.
All in the end to serve pieces of static content. It's mind boggling.
Yes, you could just go it alone and do your own NPM-less JS, but you really will be mostly on your own. Once you wander into front-end development, the assumption is you live in their nodejs city, and their city is a dirty dirty ass place.
reply