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

Mako: Fast, production-grade web bundler

makojs.dev

Post reply on HN
Print view View original

21–30 of 38 posts

Re: Mako: Fast, production-grade web bundler

#21

Post by tacker2000 »

echelon wrote: post #14
JensRantil wrote: post #13

Earlier quoted context omitted.

I find all these "based on Rust" and "written in Rust" announcements ridiculous. Which programming language is entirely irrelevant to an end-user.

Rust signals fast, modern, and correct. It's absolutely a badge. You should give the language a try when you've got a spare weekend.

I think this blind evangelisation is absolutely an anti-badge and quite cringey.

The quality of a program depends entirely on the people writing it, no language will automagically make it “correct”, whatever that means.

“Fast” can be achieved in pretty much any language and “modern” also doesnt really mean anything in terms of code or application quality.

Re: Mako: Fast, production-grade web bundler

#22

Post by mind-blight »

I'm just not quite sure why "speed" is what be js bundlers are selling themselves on. We have a number of fast bundlers already, so that's not what's taking my time. DevEx is the real selling point for me, and that didn't talk about any of their differentiators there

Re: Mako: Fast, production-grade web bundler

#23

Post by nosefurhairdo »

umvi wrote: post #18

If you use vanilla JS modules you can get away with no bundlers at all which greatly simplifies web projects. import statements "just work" in browsers, and caching of shared modules means you don't need fancy things like chunking. Also no need for map files and such, just debug directly in browser. Vanilla TS also works well if you use a server side translator like esbuild to strip out the types before serving the f…

> Even though native ESM is now widely supported, shipping unbundled ESM in production is still inefficient (even with HTTP/2) due to the additional network round trips caused by nested imports. To get the optimal loading performance in production, it is still better to bundle your code with tree-shaking, lazy-loading and common chunk splitting (for better caching).

Source is Vite docs: https://vite.dev/guide/why.html#why-bundle-for-production

For me, Vite has largely solved my js tooling needs. It's definitely cool how far we can go with the platform alone, but for larger applications or publishing libraries, tooling like Vite is a blessing.

Re: Mako: Fast, production-grade web bundler

#24

Post by MyOutfitIsVague »

umvi wrote: post #18

If you use vanilla JS modules you can get away with no bundlers at all which greatly simplifies web projects. import statements "just work" in browsers, and caching of shared modules means you don't need fancy things like chunking. Also no need for map files and such, just debug directly in browser. Vanilla TS also works well if you use a server side translator like esbuild to strip out the types before serving the f…

Due to that caching, you still need some sort of preprocessor to digest the files and generate an import map. Third party modules also add some extra friction. I found that when I ended up pruning out all the edge cases, just bundling it ends up being less work anyway.

Re: Mako: Fast, production-grade web bundler

#25

Post by appleorchard46 »

giancarlostoro wrote: post #5

Mako is also a Python templating library. I have used Mako primarily since it was what reddit used to use back in 2016. Not sure if reddit still uses it.

Also an embedded server[0] and a PHP framework [1].

[0] https://makoserver.net/

[1] https://makoframework.com/

Re: Mako: Fast, production-grade web bundler

#26

Post by umvi »

MyOutfitIsVague wrote: post #24
umvi wrote: post #18

If you use vanilla JS modules you can get away with no bundlers at all which greatly simplifies web projects. import statements "just work" in browsers, and caching of shared modules means you don't need fancy things like chunking. Also no need for map files and such, just debug directly in browser. Vanilla TS also works well if you use a server side translator like esbuild to strip out the types before serving the f…

Due to that caching, you still need some sort of preprocessor to digest the files and generate an import map. Third party modules also add some extra friction. I found that when I ended up pruning out all the edge cases, just bundling it ends up being less work anyway.

> Due to that caching, you still need some sort of preprocessor to digest the files and generate an import map.

Why? I haven't needed import maps at all.

> Third party modules also add some extra friction

This is true, sometimes 3rd party JS requires you write a small ESM wrapper, etc, but I haven't found it to be too onerous

Re: Mako: Fast, production-grade web bundler

#27

Post by umvi »

nosefurhairdo wrote: post #23
umvi wrote: post #18

If you use vanilla JS modules you can get away with no bundlers at all which greatly simplifies web projects. import statements "just work" in browsers, and caching of shared modules means you don't need fancy things like chunking. Also no need for map files and such, just debug directly in browser. Vanilla TS also works well if you use a server side translator like esbuild to strip out the types before serving the f…

> Even though native ESM is now widely supported, shipping unbundled ESM in production is still inefficient (even with HTTP/2) due to the additional network round trips caused by nested imports. To get the optimal loading performance in production, it is still better to bundle your code with tree-shaking, lazy-loading and common chunk splitting (for better caching). Source is Vite docs: https://vite.dev/guide/why.htm…

That hasn't been my experience. Depends on the caching mechanism used I guess, but if you bake cache busting directly into the URI like I do (i.e. there's a hash digest in the path), the browser doesn't need to make any additional network round trips for any nested imports that have already been fetched - they are all 0ms cache hits. And even if you use a cache mechanism that requires reaching out to the server every time, it's still very lightweight (you'll just get a 304 not modified for any nested imports)

Even if vanilla modules is slightly less optimal than a bundler performance wise, I would still argue the additional complexity (for learning, maintaining, deploying, debugging) introduced by said bundler is not worth the extra cost for most websites.

Re: Mako: Fast, production-grade web bundler

#28

Post by JensRantil »

echelon wrote: post #14
JensRantil wrote: post #13

Earlier quoted context omitted.

I find all these "based on Rust" and "written in Rust" announcements ridiculous. Which programming language is entirely irrelevant to an end-user.

Rust signals fast, modern, and correct. It's absolutely a badge. You should give the language a try when you've got a spare weekend.

Then they should write "focuses on fast, modern, and correct", not "written in Rust". There are plenty of strategies (such as programming languages) that lead to those outcomes.

Re: Mako: Fast, production-grade web bundler

#29

Post by gavmor »

cmrdporcupine wrote: post #15

What I want is one of these bundlers and typescript compilers that are written in Rust to be runnable programmatically from e.g. a Cargo build.rs or within a web server in Rust. I don't want to install your binary separately, and I don't want to use NPM for my project. I want to use my existing build system, and if you wrote it in Rust, it should be made to fit nicely into the Rust ecosystem.

> I don't want to use NPM for my project.

I used to feel that way coming from the Ruby / Rails ecosystem, but ultimately I settled leaned heavily into the "convention over configuration" maxim and try my best to adhere to front-end conventions, thereby following the principal of "least surprise" when it comes to wiring up any oddball bits, bobs, or libraries.

Lots of Javascript libraries come as Rubygems, and they are definitely production ready, but while they're arguably "on the rails" in terms of Ruby devex, they're quite a ways off from—and alienating to those versed in—serious frontend development.

So, even if it's written in Rust, if it's bundling a complex front-end—and if not, do you need a bundler?—doesn't that front-end deserve its own toolchain, in which its source code is respected as first-class? Otherwise, I would stay away from JS entirely, frankly. A brackish estuary is an unfortunate model for software architecture.

Re: Mako: Fast, production-grade web bundler

#30

Post by cmrdporcupine »

gavmor wrote: post #29
cmrdporcupine wrote: post #15

What I want is one of these bundlers and typescript compilers that are written in Rust to be runnable programmatically from e.g. a Cargo build.rs or within a web server in Rust. I don't want to install your binary separately, and I don't want to use NPM for my project. I want to use my existing build system, and if you wrote it in Rust, it should be made to fit nicely into the Rust ecosystem.

> I don't want to use NPM for my project. I used to feel that way coming from the Ruby / Rails ecosystem, but ultimately I settled leaned heavily into the "convention over configuration" maxim and try my best to adhere to front-end conventions, thereby following the principal of "least surprise" when it comes to wiring up any oddball bits, bobs, or libraries. Lots of Javascript libraries come as Rubygems, and they ar…

We have come to the juncture where hosting a small bit of JS functionality requires a giant swamp^Wecosystem of bundlers, transpilers, packaging systems, and specialized servers.

All in the end to serve pieces of static content. It's mind boggling.

Yes, you could just go it alone and do your own NPM-less JS, but you really will be mostly on your own. Once you wander into front-end development, the assumption is you live in their nodejs city, and their city is a dirty dirty ass place.

Post reply on HN