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

Original Article ↗ Hacker News Discussion ↗

A new Rust-based JavaScript bundler called Mako is being weighed against existing tools like esbuild, SWC, Vite, Webpack, and emerging Rust alternatives such as Rspack and Rolldown. Commenters highlight performance gains, advanced code-splitting, and potential ecosystem reuse via Rust crates, but note that many Rust tools still lack full Webpack-style feature parity and mature plugin systems for complex, large-scale projects. The conversation also reflects broader fatigue with constant tooling churn in the JavaScript ecosystem, alongside explanations of what bundlers actually do and calls either to standardize on a few stable options or move toward architectures that rely less on bundling altogether.

Comparisons and performance

  • Mako is built on SWC and positioned against Vite (esbuild + Rollup). Its benchmark claims ~2× speedup over Vite-based bundlers.
  • Some argue the benchmark mostly measures Vite’s own overhead, not esbuild itself; older comparisons showed esbuild faster.
  • Esbuild is praised for speed but critiqued for: weak code-splitting, limited plugin API, and rougher handling of CommonJS edge cases compared to Webpack.
  • For large projects where Vite builds take ~20 seconds, a 2× speedup is seen as significant; for smaller apps already in low seconds, further gains feel marginal.

Features and plugin ecosystem

  • Mako advertises advanced code-splitting and strong tree-shaking. A linked (Chinese) article describes tree-shaking mostly at ES module top level, mixing dead-code elimination and link-time optimization.
  • Plugin system is explicitly marked as unstable; there’s an intent to support the unplugin ecosystem for compatibility with existing plugins.
  • Some users want a stable Rust library interface to call bundling from build.rs in Cargo; current tooling (Mako, SWC) doesn’t clearly offer that.

Rust tooling wave and related projects

  • Mako is part of a broader Rust-based tooling surge: Rspack, Rsbuild, Farm, Rolldown, OXC, etc., including several from major Chinese companies.
  • Motivations cited: performance, safer systems language, easy single-binary distribution, reuse of shared Rust crates (Deno, OXC, Biome).
  • Others see “rewritten in Rust” as partly hype and KPI-driven, or as parallel efforts that fragment effort instead of consolidating on a few mature tools.

Bundler fatigue vs. perceived necessity

  • Many express exhaustion with “yet another bundler,” arguing what’s really missing is full Webpack feature parity in a fast tool.
  • Others counter that painful realities—slow builds, complex module formats (CJS/ESM), legacy browser quirks, TS and asset pipelines—justify ongoing experimentation.
  • Some wish bundlers were unnecessary or built into the JS runtime; point to import maps, native modules, HTTP/2, and no-bundle dev setups, but note npm/ESM/package.json complexity still pushes most real-world projects toward bundlers.

What bundlers actually do (clarifications)

  • Several comments explain bundlers as the web equivalent of a compiler/linker:
    • Combine many JS/CSS files into fewer bundles.
    • Perform minification, tree-shaking, and dead-code elimination.
    • Transpile TS and newer JS features, normalize module systems, and often power dev servers and HMR.