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

71–80 of 215 posts

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

#71

Post by brabel »

benrutter wrote: post #60

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 do…

Are you familiar with Java?

If so, a web bundler is like a build tool which creates a single fat jar from all your source code and dependencies, so all you have to "deploy" is a single file... except the fat jar is just a (usually minified) js file (and sometimes other resources like a css output file that is the "bundled" version of multiple input CSS files, and other formats that "compile" to CSS, like SCSS [1] which used to be common because CSS lacked lots of features, like variables for example, but today is not as much needed).

Without a bundler, when you write your application in multiple JS files that use npm dependencies (99.9% of web developers), how do you get the HTML to include links to everything? It's a bit tricky to do by hand, so you get a bundler to take one or more "entry points" and then anything that it refers to gets "bundled" together in a single output file that gets minified and "tree-shaken" (dead code elimination, i.e if you don't use some functions of a lib you imported, those functions are removed from the output).

Bundlers also process the JS code to replace stuff like CommonJS module imports/exports with ESM (the now standard module system that browsers support) and may even translate usages of newer features to code that uses old, less convenient APIs (so that your code runs in older browsers). And of course, if you're writing code in Typescript (or another language that compiles down to JS) your bundler may automatically "compile" that to JS as well.

I've been learning a lot about this because I am writing a project that is built on top of esbuild[2], a web bundler written in Go (I believe Vite uses it, and Vite is included in the benchmarks in this post). It's extremely fast, so fast I don't know why bother writing something in Rust to go even faster, I get all my code compiled in a few milliseconds with esbuild!

Hope that helps.

[1] https://sass-lang.com/documentation/syntax/

[2] https://esbuild.github.io/

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

#72

Post by iJohnDoe »

brabel wrote: post #71
benrutter wrote: post #60

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 do…

Are you familiar with Java? If so, a web bundler is like a build tool which creates a single fat jar from all your source code and dependencies, so all you have to "deploy" is a single file... except the fat jar is just a (usually minified) js file (and sometimes other resources like a css output file that is the "bundled" version of multiple input CSS files, and other formats that "compile" to CSS, like SCSS [1] whi…

Thank you. Extremely helpful.

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

#73

Post by meiraleal »

cornedor wrote: post #12
interstice wrote: post #7

Earlier quoted context omitted.

As soon as the browser specs catch up to what the bundlers are doing I’d drop them in a heartbeat. Not holding my breath though

You can get pretty far by using importmaps, you would not have treeshaking or a single bundled file, but it works pretty well. JSDoc can be used to add types to your project (that can be typechecked using typescript). I'm currently building a hobby project using preact, htm and jspm for packages. It's pretty nice to just start building without starting a build tool, having to wait for it to finish, make sure it's not…

For offline esm.sh you can use service workers cache, no?

Also why not use this config in production? Http2 should give the same performance for multiple small files than a big bundle and it's much better to cache

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

#74

Post by 7bit »

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.

Sounds like a contractual thing, not like a bundler thing. The client should always include a clause into the contract that the client must hand all work over after closing the partnership.

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

#75

Post by flohofwoe »

benrutter wrote: post #60

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 do…

Bundling is the equivalent of static linking, typically combined with dead code elimination (which is called "tree shaking" in the web world) plus optionally other optimizations and code transformations.

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

#76

Post by meiraleal »

samaltmanfried wrote: post #26
berkes wrote: post #22

Earlier quoted context omitted.

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…

The situation with the tooling constantly changing isn't nearly as bad as the front-end frameworks themselves. I've been updating my knowledge of front-end, and it's an absolute shambles. The official React documentation( https://react.dev/learn/start-a-new-react-project ) is telling me that in order to use their framework, I need to use another framework to solve (quote)"common problems such as code-splitting, routi…

Nextjs is the trojan horse sent to destroy React and it worked

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

#77

Post by oefrha »

throwAGIway wrote: post #66
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.

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 system is.

[1] https://esbuild.github.io/faq/#upcoming-roadmap

[2] https://makojs.dev/docs/features#code-splitting

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

#78

Post by michaelmior »

padjo wrote: post #46
berkes wrote: post #20

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.

If they didn’t tell us it was built in Rust how would we ever know how smart the developers are?

Personally, I appreciate knowing when something is written in Rust. I know it is very likely I can easily install it and try it out immediately and that it is likely faster than any non-native tool I'm currently using. However, I do find "based on Rust" instead of "written in Rust" to be an odd choice of terms.

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

#79

Post by dluan »

tinco wrote: post #68
dluan wrote: post #29

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.

It's in the ms for a small projects. These improvements are not to shave a couple ms off some small codebase, but would shave seconds off of really large projects. The codebase I'm working on right now isn't really large, about 5 years of development with on average 2-3 developers working on it and in vite (esbuild) the build time is 20.78 seconds on my M1 MBP. This project claims to be twice as fast as vite, so it w…

I ripped out webpacker and replaced it with esbuild in a big legacy rails app for the front end, probably 2-3 years ago, and its been fantastic and I haven't looked back. It's more or less made front end bundling an afterthought. Going from 3s to 1.5s on my M2 (esbuild to mako) isn't a gamechanger, so for me it feels like it's already getting close to the peak, whatever that might mean.

But I was more just asking what's the theoretical limit for this kind of optimization, and at the very least with rust. O(n)?

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

#80

Post by timrichard »

ecmascript wrote: post #69
timrichard wrote: post #65

Earlier quoted context omitted.

I didn't enjoy the Rust hype on here in years past, but I'm always glad of any better tooling. Just an example from the other week... I swapped out NVM for FNM (Rust) and now I don't have to put up with performance issues, especially slow shell startup times.

Just me being curious since I have used nvm for years without any issues. What do you mean by slow shell startup times? In what way do you use nvm in order to experience any slowness?

I followed the standard nvm install process, to get it loaded from my .zshrc

I noticed a second or two in lag between launching the terminal and getting a shell prompt. Commenting out the nvm load as a test removed the delay. I installed fnm, aliased it to be nvm, and everything is snappy. Also nicer if you use tooling to 'nvm use' when changing into a project directory.

There are a few issue threads such as this one : https://github.com/nvm-sh/nvm/issues/2724

BTW, this blog post was great for finding the culprit if there is zsh startup latency : https://stevenvanbael.com/profiling-zsh-startup

Post reply on HN