This is an interesting case of critical mass. A few years ago Rust was a pretty suboptimal language to start JavaScript tooling in (or Python for that matter). Some crazy folks however did not care, and just went for it. As time went on, that base level of investment into tooling all the sudden meant that there was so much to leverage, that it went from an obscure language choice to a pretty reasonable one.
The “Why Rolldown” section cites two reasons:<p>1) esbuild isn’t good at splitting
2) rollup is too slow<p>Why wasn’t it an option to improve esbuild’s splitting functionality or to improve rollup performance? Why is it the best option to introduce yet another tool?
Doesn't Rollup already use quite a bit of rust[0]? It's actually why I had to abandon it for a project, where they didn't offer binaries for our build platform and I needed to bundle, like 2 ES6 javascript libraries so I just grabbed esbuild instead.<p>[0] <a href="https://github.com/rollup/rollup/tree/master/rust">https://github.com/rollup/rollup/tree/master/rust</a>
The question is: is the output as good as Rollup? I haven’t seen a bundler that outputs code that isn’t junk that <i>must</i> be minified to be any good.<p>With rollup, I can just ship it as a web extension and it’s still 100% readable.
Rollup produces an AST (with acorn) then it manipulates the original source code as a string with MagicString which is a less than ideal hack for code transformations. Will Rolldown eschew the MagicString approach altogether and transform the AST directly? The advantage would be that the emitted code would not have to be reparsed again for downstream use.
Their about page (<a href="https://rolldown.rs/about" rel="nofollow">https://rolldown.rs/about</a>) describes why they want to do this, but after reading it I'm still unsure why they can't accomplish their goals by adding features to esbuild? Maybe the project goals are too different?
Great! Hopefully this makes using dynamic import easier when you say want to chunk your language dependencies and only import them as needed during runtime. As I just tried this with Vite it was quite a hassle and I decided it was easier to just import all async after initial render.
I actually can't understand javascript bundling, am I just dumb? I try to build a monorepo and every single time I get errors building my nodejs apis because of esm / cjs module bundling.<p>Why do I even need to bundle a nodejs api? My current project's backend is completely in Rust because I actually found that easier to deal with. Kubernetes was easier to figure out for me.
Yet another bundler. Why should I adopt this one?<p>More importantly, how is this being funded? I find it hard to believe that core team is running off sponsor dollars. Is this project going to be around next year? Maybe it's coming from Vite sponsorship backers.