Live data from Hacker News

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

makojs.dev

121–130 of 215 posts

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

#121

Earlier quoted context omitted.

Bundlers take many - usually at least hundreds, often tens of thousands - individual source files (modules) and combine them into one or few files. During that, they also perform minification, dead code elimination and tree shaking (removal of unused module exports). It's orthogonal to TypeScript - bundler will invoke a TS compiler during the process and also functions as a dev server, but that's just for nicer DX. P…

When you say dead code elimination, do you mean if I import some huge library just to use a single function, the bindler will shimmy things about so only the single function is being included in package and not the big library? If so, that's amazingly helpful, I'm mostly over in python data land and I wish that existed for applications, although admittedly there's less need.

Yes, exactly. Pulling a huge npm dependency is usually not a problem if they didn't go out of their way to make it super hard to analyze at build time.

This is tree shaking though, dead code elimination means it will find code that isn't used at all and remove it - for example you might have if (DEV) {...}, and DEV is static false at build time, the whole if is removed.

So first it performs dead code elimination, then it removes unused imports, and then it calculates what is actually needed for your imports and removes everything else.

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

#122
post #88

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

[deleted]

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

#125

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.

Imagine if you could just scp your source code tree onto a CDN and it would automatically bundle it based on how clients import it.

Isn't this the idea behind CI/CD wotkflows?

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

#127
post #70

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 is built on swc, and they compare themselves to vite, which is built on esbuild. So the answer to your question is that they claim to be roughly twice as fast as esbuild (-based bundlers) in the benchmark in this article.

I'm not entirely sure if we can really tell anything about esbuild from that comparison, as vite's production build time is 1300ms (which uses rollup), but dev startup time 1100 (uses esbuild to prebundle). It seems like vite itself has overhead.

The only bench I'm aware of was presented in November 2023: https://x.com/boshen_c/status/1719596594985681275?t=x8FaB9Aw..., where esbuild was faster.

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

#128
post #77

Earlier quoted context omitted.

SWC doesn't bundle at all. Esbuild is a pretty good bundler but works well only if your code and dependencies use ESM, it's not as good as other options with CommonJS.

That’s not the biggest problem of esbuild. Esbuild has poor support for code splitting (it’s the first priority on their roadmap[1]) and limited plugin interface which makes it a poor choice for complex projects. These are the reasons that Vite for instance can’t use esbuild for production builds. While I haven’t tried Mako, it seems to have support for advanced code splitting[2]. No idea how powerful its plugin syst…

Also, the vite team in collab with a few others is building https://rolldown.rs/, to replace esbuild and rollup in vite. It's goal is to be faster than esbuild, with extended chunking options and so on.

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

#129
post #22
post #17

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.

The fact that people keep releasing new bundlers, minifiers, transpilers, package managers and so on, for JavaScript is a loud and clear warning that something is amiss. People (re)write such tools either for fun or to solve a problem (or best: both). Apparently after so much re-writes the problems haven't been solved. To me, this indicates fundamental problems. I'm not familiar enough with the ecosystem to know what…

I believe we see such diversity because of the unique environment in which JS has come to exist. Folks who are writing all these tools are trying too solve problems from the outside in for their small corner of an incredibly large ecosystem.

It's a snow ball rolling down an infinitely long mountain. I believe this may never settle.

Mainstream browsers have already coalesced on a no build solution but it's profitable, by fame or fortune, to continue building solutions that require bundle and compile steps. Then others use those because off the shelf libs require them and save time and money.

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

#130

Earlier quoted context omitted.

Bundlers take many - usually at least hundreds, often tens of thousands - individual source files (modules) and combine them into one or few files. During that, they also perform minification, dead code elimination and tree shaking (removal of unused module exports). It's orthogonal to TypeScript - bundler will invoke a TS compiler during the process and also functions as a dev server, but that's just for nicer DX. P…

When you say dead code elimination, do you mean if I import some huge library just to use a single function, the bindler will shimmy things about so only the single function is being included in package and not the big library? If so, that's amazingly helpful, I'm mostly over in python data land and I wish that existed for applications, although admittedly there's less need.

Conditionally yes. There are many libraries that cannot be tree shaken for various reasons. Libraries typically need to stick to a subset of full JS to ensure that the code can be statically analyzed.
Post reply on HN