Live data from Hacker News

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

makojs.dev

161–170 of 215 posts

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

#161

I'm not a web developer, though I still develop web apps regularly. What exactly is the point of a bundler in the rapid development cycle? If you want your web app to load up fast, it's better if you only need to redownload the parts that actually changed, so you're better off not bundling them.

You need to use some kind of automation to fingerprint your files for optimal caching.

Where applicable there simply does not exist a better caching strategy than fingerprint plus Cache-Control: immutable

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

#163

I'm not a web developer, though I still develop web apps regularly. What exactly is the point of a bundler in the rapid development cycle? If you want your web app to load up fast, it's better if you only need to redownload the parts that actually changed, so you're better off not bundling them.

If you have a lot of files, the initial (dev server) page load times increases linearly with the number of files you have.

With a slow bundler, that tradeoff made sense, but with a fast bundler, it is suboptimal.

Also, typically the application is split into multiple smaller bundles, so only a slice of the application is rebundled on change.

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

#164
post #42

Earlier quoted context omitted.

> The old joke is that there's a new JavaScript framework every month. That's not really true — we've had the same big three for a decade Yup. I know a few people who were using React 10 years ago and still use it today. What has changed frequently is the tooling. e.g. Bower going away in favor of NPM; Gulp/Grunt going away in favor of Webpack, which is slowly going away in favor of Vite; CoffeeScript going away in f…

> ClojureScript has a great deal of stability in both the language itself and tooling Does it still use Google's Closure (they've chosen it just for the name, right?) compiler? Is that still supported by Google?

Major parts of the compiler have been unchanged since its original public release. It still uses Google Closure Compiler (GCC), but the community understands that was the wrong choice of technology in retrospect. The compiler is still actively developed and used internally by Google. What is going away is the Google Closure Library (GCL), since modern JavaScript now has most of what GCL offered, and it's become easier to consume third party libraries that offer the rest of GCL's functionality.

The reason ClojureScript has not moved away from GCC has to do with the fact it performs optimizations -- like inlining, peephole ops, object pruning, etc. -- that ensure ClojureScript's compiler output becomes relatively fast JavaScript code. The closest alternative to GCC's full-program optimization would be Uglify-JS, but it doesn't perform nearly as much optimizations as GCC does.

For a concrete example, consider the following code. I am intentionally using raw JS values so that the JS output is minimal and can be pasted easily.

  (ns cljs.user)

  (defn f [x]
    (let [foo 42
          bar (- foo x)
          baz (+ foo bar)]
      #js {:bar bar
           :baz baz}))

  (defn g [x]
    (let [result (f x)]
      (when (pos? (.-bar result))
        (js/console.log "It works"))))

  (g 0)
The ClojureScript compiler will compile this code to something like this

  var cljs = cljs || {};
  cljs.user = cljs.user || {};
  cljs.user.f = (function cljs$user$f(x){
    var foo = (42);
    var bar = (foo - x);
    var baz = (foo + bar);
    return ({"bar": bar, "baz": baz});
  });
  cljs.user.g = (function cljs$user$g(x){
    var result = cljs.user.f.call(null,x);
    if((result.bar > (0))){
      return console.log("It works");
    } else {
      return null;
    }
  });
  cljs.user.g.call(null,(0));
Paste this into `npx google-closure-compiler -O ADVANCED` and the output is simply

  console.log("It works");
On the other hand, `npx uglify-js --compress unsafe` gives us

  var cljs=cljs||{};cljs.user=cljs.user||{},cljs.user.f=function(x){x=42-x;return{bar:x,baz:42+x}},cljs.user.g=function(x){return 0
This is quite larger, and possibly slower, than the output of GCC.

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

#165

Earlier quoted context omitted.

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…

You do have tree shaking: the browser only loads the modules that are imported. Only import what you use (and don't use barrel files) and you're golden.

If you don't have any external library (e.g. npm) dependency you're golden. Unfortunately, this means that you now have to write all your code from scratch, which is ok if you're writing a very light website, but it's unsustainable if you do anything non-trivial.

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

#166

Earlier quoted context omitted.

You do have tree shaking: the browser only loads the modules that are imported. Only import what you use (and don't use barrel files) and you're golden.

If you don't have any external library (e.g. npm) dependency you're golden. Unfortunately, this means that you now have to write all your code from scratch, which is ok if you're writing a very light website, but it's unsustainable if you do anything non-trivial.

Plenty of npm dependencies are published as browser-compatible standard JS modules.

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

#167

Earlier quoted context omitted.

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.

Just looking at their benchmarks, it's not particularly fast. es-build looks much better in benchmarks, but it's not written in Rust. It seems they wanted a tool in Rust just-because (experience on the team, preference foe the language...), and then only compared against those. As for the language "based on Rust", it's likely bad wording due to them not being native English speakers.

esbuild is written in Go, which has similar "probably quite fast and easy to install" properties to Rust.

Compare that to the expected experience if it was written in C++ or JavaScript or Python or Java or ... All of those are either likely to be slow or painful to use.

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

#168

Earlier quoted context omitted.

Just looking at their benchmarks, it's not particularly fast. es-build looks much better in benchmarks, but it's not written in Rust. It seems they wanted a tool in Rust just-because (experience on the team, preference foe the language...), and then only compared against those. As for the language "based on Rust", it's likely bad wording due to them not being native English speakers.

esbuild is written in Go, which has similar "probably quite fast and easy to install" properties to Rust. Compare that to the expected experience if it was written in C++ or JavaScript or Python or Java or ... All of those are either likely to be slow or painful to use.

To be fair, you can package a modern Java app into a single executable [1], without the entire JRE shipped inside.

Few people do that though.

[1]: https://www.graalvm.org/latest/reference-manual/native-image...

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

#170

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?

Import maps and type="module" are pretty good.

I prefer to spend my time building against that instead of another bundler.

Post reply on HN