Mako: Fast, production-grade web bundler

by kenfai • 1 year ago

50 35 1 year ago

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

singron• 1 year ago

I believe the developers are Chinese, so it might just be awkward English from a non native speaker.

JensRantil2• 1 year ago

I find all these "based on Rust" and "written in Rust" announcements ridiculous. Which programming language is entirely irrelevant to an end-user.

echelon2• 1 year ago

Rust signals fast, modern, and correct. It's absolutely a badge.

You should give the language a try when you've got a spare weekend.

drewda• 1 year ago

FWIW, previously discussed under https://news.ycombinator.com/item?id=40853845

giancarlostoro3• 1 year ago

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.

karmakaze• 1 year ago

The Shortfin Mako is the fastest shark. The Sailfish (and maybe Black Marlin depending on who you believe) is faster.

mubou• 1 year ago

It's also just a common Japanese girl's name.

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.

nine_k• 1 year ago

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.

dleeftink• 1 year ago

We know for a fact, that within the constraint of 12 pitches, it is unlikely you will write an original melody [0].

[0] https://archive.org/download/allthemusicllc-datasets

[1] http://allthemusic.info/

appleorchard46• 1 year ago

Also an embedded server[0] and a PHP framework [1].

[0] https://makoserver.net/

[1] https://makoframework.com/

giancarlostoro3• 1 year ago

I think projects with short names need suffixes in order to not be confused with others that most likely share the name, these make sense and tell you exactly what they are.

joshuaturner• 1 year ago

Surprised to not see esbuild in the comparison chart

inbx0• 1 year ago

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.

cmrdporcupine2• 1 year ago

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.

gavmor2• 1 year ago

I don't want to use NPM for my project.

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.

cmrdporcupine2• 1 year ago

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.

mightyham• 1 year ago

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.

MuffinFlavored• 1 year ago

It's good to have choices, but it's become difficult to keep up with such a fragmented ecosystem.

I feel this way not only about bundlers, frameworks, languages, etc. but also about Linux/BSD distributions. What about you?

giancarlostoro3• 1 year ago

We need tech empowerment benchmarks for all these bundlers.

umvi3• 1 year ago

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)

nosefurhairdo• 1 year ago

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).

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.

umvi3• 1 year ago

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.

MyOutfitIsVague2• 1 year ago

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.

umvi3• 1 year ago

Due to that caching, you still need some sort of preprocessor to digest the files and generate an import map.

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

pier25• 1 year ago

Damn for a moment I thought this was about Marko (the frontend framework by Ebay).

https://markojs.com/

They've been teasing v6 for years now.

mind-blight• 1 year ago

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

Mako: Fast, production-grade web bundler

Related Stories