Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

makojs.dev

Post reply on HN
Print view View original

131–140 of 215 posts

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

#131

Post by iamleppert »

ollybee wrote: post #48
spankalee wrote: post #4

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.

Bundlers also tie clients to developers without them realizing. I work for a webhost and Many people still assume that if they have access to their hosting then they have their "source code". We see often that people migrate a sites after breaking ties with a developer only to find what they have may function, but is unmaintainable.

Source code costs extra, everyone knows that! Get the bag!

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

#132

Post by dsff3f3f3f »

rty32 wrote: post #91
norman784 wrote: post #35

Earlier quoted context omitted.

Why matters that is written in Rust? Because there are already a few JS tools written in Rust, so you can now use the crates from projects like Deno[0], OXC[1], BiomeJS[2], etc to write your own tool with minimal effort. Also note that the Vite team is writing Rolldown[3], and guest what? They are writing it in Rust. [0] https://crates.io/search?q=deno [1] https://crates.io/search?q=oxc [2] https://crates.io/search?q…

None of those tools you quoted are production ready based on my investigation, in the sense that if you manage the JS infrastructure of a company of 2000 developers, you would stick with webpack. Lots of Rust based tooling is still half baked and missing things here and there, so much that you wish these people work together to create one (or at most two) tool that is comparable to webpack.

> None of those tools you quoted are production ready based on my investigation

This is very true and almost all of them are taking far longer to develop than they initially thought. swc/turbopack is being pushed by Vercel and it has been a huge ongoing disaster.

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

#133

Post by megaman821 »

phplovesong wrote: post #2

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.

...or Turbopack or RSpack or Rolldown? Too many choices. I will be sitting this round out until a winner emerges.

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

#134

Post by chuckadams »

BaculumMeumEst wrote: post #126

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.

We have bundlers because for a long time we didn't have a module standard due to browsers hanging on to their minimal and simple model of `script src=`. Even now modules are pretty minimal fare. Plus there's all the transpiling and asset transformation, but hey we should all be using document.write and not those "bloated" frameworks on top of JS, right? Maybe jQuery if we want to get really bougie?

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

#135

Post by evilduck »

ollybee wrote: post #48
spankalee wrote: post #4

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.

Bundlers also tie clients to developers without them realizing. I work for a webhost and Many people still assume that if they have access to their hosting then they have their "source code". We see often that people migrate a sites after breaking ties with a developer only to find what they have may function, but is unmaintainable.

You'd struggle to extract a maintainable codebase from a C# or Golang web server after the fact too. As an industry we've been making simple websites on shared hosting for over a generation, clients who ignore the entire world of information about the dangers and pitfalls on this topic are squarely to blame as negligent. It ranks up there with not paying taxes and then acting shocked when the government comes knocking.

While Javascript could potentially be contractually mandated to be written in a way to facilitate production codebase recovery, if you knew enough to ask for that you wouldn't, you'd require them to use your source control and to provide build/deployment scripts instead.

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

#136

Post by pshu »

rk06 wrote: post #115

> 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

the issue shows that Mako plans to support the unplugin system, it's a compat solution for existing ecosystem.

https://github.com/umijs/mako/issues/1238

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

#137

Post by chuckadams »

inbx0 wrote: post #114
jampekka wrote: post #106

Earlier quoted context omitted.

Intrestingly esbuild isn't included in their benchmarks. Esbuild is the only current build-tool that keeps one sane. The serve-mode is excellent and elegant with no brittle constantly breaking hacks like HMR or file watching. Sadly configuring especially the serve-mode is a bit badly documented, and not usable via CLI flags if one needs plugins.

To each their own. I can't imagine doing UI development without HMR anymore. Makes it so much faster to iterate.

That's what Vite is for: all the zip of esbuild plus HMR that works. Usually works anyway... looking at one project where I never have to reload, and another that I'm doing that every ten saves or so. Much sloppier legacy sources in the second tho, Vite really pays off when you write more modern code from the start.

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

#138

Post by pshu »

megaman821 wrote: post #133
phplovesong wrote: post #2

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.

...or Turbopack or RSpack or Rolldown? Too many choices. I will be sitting this round out until a winner emerges.

according the current situation in bundlers written in JS，there is no "really" winner in my opinion。 webpack or rullup，which one is winner is a very personal thought。 So i think there maybe some similar situation in bundlers written in Rust.

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

#139

Post by pshu »

flohofwoe wrote: post #96
throwAGIway wrote: post #83

Earlier quoted context omitted.

Dead code elimination is related to but distinct from tree shaking - it also means that unused code branches get removed, for example constants like NODE_ENV get replaced with a static value, and if you have a static condition that always results to true, the else branch is removed.

In my book that's all covered by the term 'dead code elimination', e.g. removing (or not including in the first place) any code that can be statically proven to be unreachable at runtime. Some JS minifiers (like Google's Closure) can do the same thing in Javascript on the AST level (AFAIK Closure essentially breaks the input code down into an AST, then does static control flow analysis on the AST, removes any unreach…

https://makojs.dev/blog/mako-tree-shaking explains how mako do the tree shaking stuff, but in Chinese.

In my two cents, the tree shaking is more focus on removing unused exports in ES module at top level. it's a mixing with Dead code elimination and link time optimization.

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

#140

Post by throwAGIway »

ahzhou wrote: post #130
benrutter wrote: post #118

Earlier quoted context omitted.

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.

Basically the only forbidden thing is dynamically calculating import paths, or dynamically generating the module.exports object.
Post reply on HN