Mako: Fast, production-grade web bundler
makojs.dev
makojs.dev
I feel this way not only about bundlers, frameworks, languages, etc. but also about Linux/BSD distributions. What about you?
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.
It might be fun to generate them and search for them, to test this hypothesis.
You should give the language a try when you've got a spare weekend.
The quality of a program depends entirely on the people writing it, no language will automagically make it “correct”, whatever that means.
“Fast” can be achieved in pretty much any language and “modern” also doesnt really mean anything in terms of code or application quality.
Rust also has a decent open-source community, so adding this to the subtext will maybe encourage people to help development
This anti-Rust hate is incredibly bizarre. It feels like the anti-Linux folks in the 00's who would decry any non-Microsoft tech choice, as if Linux was an affront to their career choices.
There are a multitude of reasons people are happy to use and evangelize Rust. It's a fucking incredible language, for one. Labeling your software as written in Rust looks a whole lot better to most people than software written in Perl or LOGO or C++.
Get over your hate. The only person it's hurting is you.
And no, I don't hate Rust, and I don't really care about Rust, or if a project/library is written in Rust or whatever, if it fits the bill, I will use it.
If you tell me a real argument why using Rust here is beneficial instead of the vague reasons described here, then I'm happy to listen.
If there are no reasons then that is also fine, then it seems like it was used because of a personal choice, experience or other constraints that we don't know.
If you are deeply in love with Rust or any other language then thats also fine. And I also get that Rust is great in many situations, like replacing low-level C code, etc.. But stop putting it on a pedestal if there are no real reasons to back that up (in this case).
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)
Source is Vite docs: https://vite.dev/guide/why.html#why-bundle-for-production
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.
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.
Why? I haven't needed import maps at all.
> Third party modules also add some extra friction
This is true, sometimes 3rd party JS requires you write a small ESM wrapper, etc, but I haven't found it to be too onerous
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.
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.
> All in the end to serve pieces of static content. It's mind boggling.
This is doesn't sound like an adequate justification for the investment of complexity tokens. I'm guessing it wasn't your idea!
They've been teasing v6 for years now.