Mako – fast, production-grade web bundler based on Rust

How does it compare to esbuild or swc? Its good we have alternatives, and im still mentally scarred from the javascript ecosystem, where almost everything is slow and buggy. But when you compare to an already native tool (like esbuild) you start getting diminishing returns.

This supports all kinds of non-platform-standard features that may tie your project to this specific bundler, but will tie them to bundlers in general.

It would be much better to have projects that work without bundlers, that can use them as an optimization step.

Rspack (ByteDance) just shipped 1.0. There's Farm too. This is from Ant Group. Major influx of build tools all built in Rust, made in China.

Turbopack is supposed to be coming, as a total rebuild of bundling. Rolldown seems solid, as a Rust roll-up redo.

> NOTICE: Plugin system is still under development, and the API may change in the future.

Killer feature of vite is to leverage existing plugins system of roll up.

Do you have plans to build a compat layer for existing ecosystem?

Other build tools are doing it. Eg: rspack can use webpack plugins, farm can use vite plugin

I was confused by the "Rust" denotion in the title and presumed it was an alternative builder to compile rust for web (wasm?). It's "yet another" bundler for javascript. Built in rust.

I don't work in web, and possibly live under a rock. I'm a little confused around what bundlers actually do?

I'd sort of assumed it was a typescript build thing before, but Mako's page gives me enough info to make me realise I'm wrong, but seems to assume people are working with some base knowledge I don't have.

Any pointers to information of exactly what bundlers do? The emphasis on speed makes it sound like it's doing a whole bunch of stuff, what are the bottlenecks? Package version resolution?

I'm not a web developer, though I still develop web apps regularly.

What exactly is the point of a bundler in the rapid development cycle? If you want your web app to load up fast, it's better if you only need to redownload the parts that actually changed, so you're better off not bundling them.

Can I kick it off programmatically inside a Cargo build via build.rs? I tried to go down this road with SWC and ... failed.

To be clear: I have JS/HTML artifacts in my repo alongside Rust source. I want to bundle them then ship them inside a produced Rust binary, or at least with it. With one build step using Cargo.

Another interesting Rust-based Javascript bundler is Oxid / OXC.

- https://github.com/oxc-project/oxc

- https://oxc.rs

It's also what Rolldown (https://rolldown.rs/about) is basing their in-development bundler on.

What happens when we reach the tip of bundling? Once you're in ms territory (like esbuild is), then what are the really creative things you can do if say every browser had a little WASM mako or some bundler in it?

It's very cool though and seems like a lot of effort went into this.

Is it kind of related to https://www.makotemplates.org/ ? Hence the name?

Time to reset the clock. 0 days since a new web bundler was released (in Rust!!).

So tired of this ecosystem and its ceaseless tide of churn and rewrites and hypechasing.

Why not use a fast language like C, Odin, Hare or Zig?

Another one?

The old joke is that there's a new JavaScript framework every month. That's not really true — we've had the same big three for a decade — but there has been an explosion of new bundlers: vite, esbuild, turbopack, farm, swc, rome/biome, rspack, rolldown, mako. And of course plenty of projects are still using rollup and webpack.

Some competition is a good thing, and it seems to have led to a drive for performance in all these projects which I'm not complaining about, but I wonder if more could be gained by working together. Does every major company or framework need their own bundler?

Feel the need to push back against the predictable nay-saying in here.

Announcing with Rust in the title is not because of a hype train, it's a way to communicate that this bundler is in the new wave of transpilers/bundlers which is much faster than the old one (Webpack, Rollup) which were traditionally written in Javascript and painfully slow on large codebases.

While the JS ecosystem continues to be a huge mess, the solution to the problem is not LESS software development ("Just stop making more bundlers & stop trying to solve the problem - give up!"). Or even worse - solve the problem internally, but don't make me hear about it by open sourcing your code.

The huge amount of churn and development in this space has a good reason... it's a desperate attempt to solve the problems that browsers have created for web developers. Fact is that most business has moved to the web, a huge amount of web development is needed, but vanilla javascript can compounds and compound in complexity in the absence of a UI framework and strict typing. So now you've added transpilation and dependency management into the mix - and the user needs to download it in less than a second when they open a web page. And your code needs to work on at least 3 independent browser engines with varying versions.

SwiftUI devs are not a more advanced breed of developer than web developers. So why don't you see a huge amount SwiftUI churn and framework/compilation hell with native iOS development? The answer should be obvious. These problems are handed down from on high

The browser/internet/javascript ecosystem despite its glaring warts is actually one of the most amazing things humanity has created... a shareable document engine grew into a global distributed computing platform where you can script an application that can run on any device in less than a second with no installation. Not bad.

Every bundler these days boasts "Rust" and "fast". What people really want is webpack feature parity. For a large enough organization with complex use cases and resource management, I yet need to see a real webpack equivalent.

(Meanwhile, swc parser can't yet pass all tests in test262 according to their website: https://docs.rs/swc_ecma_parser/latest/swc_ecma_parser/ )

Argh name choice ... https://www.makotemplates.org/

Unfortunate name collision: https://www.makotemplates.org

I've recently taken a legacy Typescript clientside codebase that was using webpack to generate tens of js packages from minutes to seconds by using bun [0] for both dev and build:

For dev I replaced webpack with "bun vite": it loads scripts ad hoc and is thus super fast at startup, and it still supports hot reloading.

For build I use "bun build". I've created a small script where I don't specify the output folder, but just intercept it, and do some simple search & replace things. It works perfectly, although it's a bit of a hack (simplified code):

   const result = await Bun.build({
     entrypoints: [srcName],
     root: "./",
     minify: true,
     naming: `${configuratorName}.[hash].[ext]`,
   });
   for (const r of result.outputs) {
     let jsSource = await r.text()
     jsSource = jsSource.replaceAll("import.meta.hot","false")
     Bun.write(outdir + r.path.substring(1), jsSource);
   }

It might not be pretty, but it works super fast, and it only took me a couple of hours to convert the whole thing...

Update:

For the record, the real script also uses the HtmlRewriter from cloudflare (included by default in bun) to alter some basic things in HTML templates as well...

[0] https://bun.sh

> H5 mobile

https://medium.com/chia-ux/what-do-chinese-clients-mean-h5-i...

> HMR

Hot Module Replacement allows all kinds of modules to be updated at runtime without the need for a full refresh. (Abridged from a webpack doc)

As someone who highly values minimalism and simplicity in software, seeing another web bundler paraded around as if it's something to celebrate does not spark joy.

This would be super interesting if I were a state actor.

Everyone is making the point that using JavaScript on the server was a BIG mistake, with this ongoing rewrites.

We already had our bundlers in Java and .NET land, before nodejs came to be, and life was good.

Can't people figure out some other tooling besides bundlers? I mean, how many do we really need?

It's probably fine, but so are all the others as well. The authors have probably spent a fair amount on time on this project so I don't want to be negative but it's just hard to be excited when it brings nothing new to the table.

Why should I use this over Vite or esbuild? Because it's written in Rust? I don't understand why that even matters. Even if it was 10 times faster I wouldn't use it because Vite is fast enough and have all the plugins I would ever need.