[HN Gopher] Mako: Fast, production-grade web bundler
___________________________________________________________________
Mako: Fast, production-grade web bundler
Author : kenfai
Score : 44 points
Date : 2025-03-09 15:39 UTC (6 hours ago)
(HTM) web link (makojs.dev)
(TXT) w3m dump (makojs.dev)
| jasonjmcghee wrote:
| I wasn't sure what "based on Rust" meant and looking at the
| announcement / GitHub etc I think they just mean that it's built
| in Rust. I couldn't find any commentary on or comparison to the
| rust language or tooling etc
| singron wrote:
| I believe the developers are Chinese, so it might just be
| awkward English from a non native speaker.
| JensRantil wrote:
| I find all these "based on Rust" and "written in Rust"
| announcements ridiculous. Which programming language is
| entirely irrelevant to an end-user.
| echelon wrote:
| 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.
| tacker2000 wrote:
| 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.
| JensRantil wrote:
| 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.
| drewda wrote:
| FWIW, previously discussed under
| https://news.ycombinator.com/item?id=40853845
| giancarlostoro wrote:
| 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.
| karmakaze wrote:
| The Shortfin Mako is the fastest shark. The Sailfish _(and
| maybe Black Marlin depending on who you believe)_ is faster.
| mubou wrote:
| It's also just a common Japanese girl's name.
|
| Needs a comparison to Vite/esbuild though. The docs only
| mention Webpack, but idk who's using Webpack on new projects
| in 2025. There's a benchmark that includes Vite on the
| homepage, but that's not gonna be enough to get me to switch
| to a newcomer with a smaller community unless there's some
| usability difference too.
|
| The CSS support also needs a comparison to LightningCSS
| (which Vite also supports and has some advantages over
| esbuild), especially when it comes to bleeding-edge features
| like view transitions and nesting.
| nine_k wrote:
| As a side note, I suspect that every pronounceable 4-letter
| combination has been used as a product name by now at least
| once. Some unpronounceables must have been used up, too.
|
| It might be fun to generate them and search for them, to test
| this hypothesis.
| dleeftink wrote:
| We know for a fact, that within the constraint of 12 pitches,
| it is unlikely you will write an original melody [0].
|
| [0]: https://archive.org/download/allthemusicllc-datasets
|
| [1]: http://allthemusic.info/
| appleorchard46 wrote:
| Also an embedded server[0] and a PHP framework [1].
|
| [0] https://makoserver.net/
|
| [1] https://makoframework.com/
| joshuaturner wrote:
| Surprised to not see esbuild in the comparison chart
| inbx0 wrote:
| They seem to be measuring things like how long it takes for the
| dev server to spin up, and how long HMR updates take. I don't
| think ESBuild offers these features out of the box. I guess it
| could be in the "Cold build" chart. AFAIK Vite uses ESBuild at
| least for some of its building, though. node_modules, dev
| builds maybe. Not sure if it was used in this benchmark or not.
| cmrdporcupine wrote:
| 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.
| mightyham wrote:
| There are so many solid web bundlers that all offer a similar
| feature set, I am pretty skeptical that another entry is all that
| beneficial. It's good to have choices, but it's become difficult
| to keep up with such a fragmented ecosystem. I also admit that I
| am biased. I started using vite a couple years ago and since then
| have never run into any serious issues with my frontend
| builds/developer experience. If the main benefit of another tool
| is marginal performance gains, I am thoroughly uninterested.
| MuffinFlavored wrote:
| > It's good to have choices, but it's become difficult to keep
| up with such a fragmented ecosystem.
|
| I feel this way not only about bundlers, frameworks, languages,
| etc. but also about Linux/BSD distributions. What about you?
| umvi wrote:
| 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 files in a
| middleware (especially if you are using a golang backend, esbuild
| is trivial to integrate as a middleware)
| nosefurhairdo wrote:
| > 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.
| umvi wrote:
| 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.
| MyOutfitIsVague wrote:
| 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.
| umvi wrote:
| > 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
| pier25 wrote:
| Damn for a moment I thought this was about Marko (the frontend
| framework by Ebay).
|
| https://markojs.com/
|
| They've been teasing v6 for years now.
| mind-blight wrote:
| 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
___________________________________________________________________
(page generated 2025-03-09 22:01 UTC)