9 ms·

Rolldown: Rollup compatible bundler written in Rust

186 points by bpierre 3y ago

the_mitsuhiko 3y ago
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.
- timschmidt 3y ago
  Cargo and crates.io make it a cinch to include libraries which implement discrete chunks of the solution. The effect of opinionated defaults and an easy path to publishing coupled with the Rust community's passion for correctness and efficiency really play off each other to result in rapid expansion of library capabilities. Crates seem to be well modularized, there seems to be widespread agreement about which crates provide good solutions, and that results in widespread compatibility in the Rust ecosystem between complex codebases doing similar things. Working in such an environment is a dream. Need to add a feature? Chances are that someone out there has already built every piece of it and all you need to do is track them down and stitch them together.
catlifeonmars 3y ago
The “Why Rolldown” section cites two reasons: 1) esbuild isn’t good at splitting 2) rollup is too slow 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?
- truckerbill 3y ago
  A lot of the time the politics gets in the way. ‘It’s broken on purpose’ etc
- danielheath 3y ago
  > Why wasn’t it an option to improve esbuild’s splitting functionality or to improve rollup performance? Rollup is written in javascript; not only is the runtime slow, the multicore story is terrible. Improving esbuilds splitting functionality is hard because splitting is full of hard tradeoffs; the spec allows module imports to have side-effects and requires that they be evaluated in order. It's therefore impossible to do optimal code-splitting without violating the esmodule spec (potentially introducing subtle errors), and the `esbuild` project values correctness even more highly than performance. Personally, I'd be very happy with "If you enable the 'make it fast' option and have modules with top level side-effects, you will get weird bugs", but I respect where they're coming from in not wanting to do that.
  - VincentEvans 3y ago
    Speaking of things “written in javascript” for the longest time all I kept hearing is how incredibly fast things written js are… Is it fair to say that it was a bit of a sales pitch? When key components of the ecosystem that were written in the language of the ecosystem itself are being rewritten in other languages - I think it’s hard to find a more compelling evidence that all is not as great as it was advertised.
    - steveklabnik 3y ago
      Everything is relative! Moreover, just because something is fast doesn’t mean it’s the fastest.
      - 9question1 3y ago
        I don't know what OP is referring to here, but from discussions like this: https://stackoverflow.com/a/4417485 https://stackoverflow.com/a/4417485 It seems like circa 2010 folks were referring to JavaScript as "fast" because it was more performant in some ways than other interpreted languages like Ruby and Python and those were the only major popular options at the time that people would consider for some use cases. The event loop model of JavaScript led to some creative use cases for having a single-threaded application handle many highly parallel requests that require very little CPU usage or computation but a large amount of blocking I/O, which I think was also pitched as "fast". But I think it's always been uncontroversial that interpreted languages like JS, Ruby, and Python are all "slow" compared to compiled ones for CPU heavy use cases.
- pjmlp 3y ago
  Both of those options imply not using Rust, hence why. I tend to think Rust isn't suitable to rewrite JavaScript tooling, any compiled language would do, or even native addons, but apparently dealing with borrow checker for userspace software that doesn't require 1us performance within 512 KB is appealing. Currently watching https://www.infoq.com/presentations/rust-javascript/ https://www.infoq.com/presentations/rust-javascript/
  - michaelmior 3y ago
    > I tend to think Rust isn't suitable to rewrite JavaScript tooling > any compiled language would do So why not Rust?
    - RamblingCTO 3y ago
      Wrong question. Why rust?
      - seanhunter 3y ago
        Because the people who actually want to do the work want to do it in rust.
        todotask 3y ago
        With both Vite and TailwindCSS v4 written in Tailwind, web development is going to be faster for Astro and other frameworks.
        no_wizard 3y ago
        >TailwindCSS v4 written in Tailwind Didn't realize it was a self bootstrapping language now. Thats awesome
        RamblingCTO 3y ago
        That's a fair answer. Although I still don't agree with rust being particularly fitting for that problem.
- sondr3 3y ago
  I can't speak for the authors of Rolldown, but esbuild is essentially a one-man show and everything is bespoke and written for esbuild. Not saying this as a bad thing, Evan single-handedly improved bundling performance for Node and started us down this path of tools in Rust. The libraries and ecosystem for writing tooling for other languages is really taking off with projects like oxc, SWC, LightningCSS, Biome, rslint, Deno, rspack, napi-rs/Neon for JS/TS/Node etc plus ruff, uv, rattler, pixi for Python and so on, so you get a proliferation of libraries and authors that can share and help each other. Plus, on a personal level, using a language with pattern matching and algebraic data types makes writing tooling for parsers and such much more ergonomic than in languages without.
  - cAtte_ 3y ago
    note that esbuild is written in go, not rust
    - sondr3 3y ago
      Yep, forgot to mention that in my post, thanks.
    - dunham 3y ago
      Also, it was originally written in both Go and Rust, and the author decided to continue in Go. Both are fine languages, but it makes an interesting case study: https://news.ycombinator.com/item?id=22336284 https://news.ycombinator.com/item?id=22336284
      - pcthrowaway 3y ago
        Wow, thank you for sharing this. The author echoes a lot of thoughts I've had working with rust. However, doesn't the explanation given for why the Go version was 10% faster mean that esbuild was built to take advantage of a fixed number of cores rather than all of them? Sorry if this is a dumb question, I'm not really that experienced with parallel computation
        3y ago
- swsieber 3y ago
  I mean... if it was me: 1) I know Rust, not Go (esbuild is written in go-lang) 2) I don't have to worry as much about breaking Rollup, and I'm not nearly as confident in my ability to write performant JS as I am in writing performant Rust.
  - Tade0 3y ago
    My experience is that the main reason why Rust is faster than JS in some applications is that the latter tends to do a lot of copying and other memory-intensive tasks - especially those related to running the JS virtual machine. If you can reduce the problem to a series of operations on pre-allocated typed arrays, JS is fast enough. Unfortunately in the case of Rollup that would be hard to do.
- no_wizard 3y ago
  esbuild is and has always been governed strongly by Evan Wallace. I can't vouch for whether or not the Evans (both Wallace and You) talked to each other about it, but I'm almost 100% certain Wallaces' vision for the esbuild project is different than what rolldown is ultimately trying to achieve. In some respects, rolldown is also the next generation of Rollup[0] and is a direct answer to rspack[1], which is a webpack compatible rust based toolchain from ByteDance [0]: Which switched to SWC as its underlying parser from acorn, which makes me wonder if that influenced the decision to use OXC, perhaps they found SWC to be troublesome. I know the Rollup and Vite teams are extremely close, and wouldn't be shocked if any troubles they had with SWC weren't shared with the Vite team when considering underlying technologies [1]: https://www.rspack.dev/ https://www.rspack.dev/
- Thaxll 3y ago
  The real reason is that author wanted to use Rust ( as he previously done ) and does not really care about improving existing solution. From the start you want to use x.y.z tech then the justification is meaningless.
- WorldMaker 3y ago
  > 1) esbuild isn’t good at splitting I've found esbuild is pretty good at splitting when source formats and outputs are ESM. (Given the name esbuild a focus on/priority for ESM input/output makes sense to me.) Is this maybe Vite team saying that they still have too many brownfield CJS dependencies and still don't believe in ESM output for production bundles in 2024?
  - rk06 3y ago
    Even if their dependencies were esm only, Vote may be used in projects which have cjs dependencies. Hence need to support it
    - WorldMaker 3y ago
      esbuild handles CJS dependencies just fine and had been what Vite was using in development for a long time anyway. It doesn't split CJS dependencies or tree-shake them as automatically/smartly as it could, but it still supports splitting them and there are manual workarounds. I think the bigger problem, from my experience here, is still the question of not moving to ESM as the default production output. That seems out of date.
- nox101 3y ago
  agreed... Personally I feel like moving a JS tool to rust means 99% of JS/TS programmers are unlikely to be able to supply a patch to fix a bug or participate in most ways. I suspect some people will consider that a good thing though.
- EvanYou 3y ago
  For esbuild: We know other teams that have attempted to improve code splitting based on esbuild and found it very difficult. A big part of it is that in order to be fast, esbuild applies multiple features (bundle, treeshaking, transforms) in as few AST visits possible, but that comes at the cost of the logic of different features not being layered / decoupled nicely. It is difficult for anyone other than Evan Wallace himself to add non-trivial new mechanisms to esbuild, and although we didn't directly talk to Evan about this, we felt it would be too much to ask for a substantial refactor of esbuild in order to get what we need. In addition, the people interested in making Rolldown happen has much more experience in Rust than in Go - and there is a lot more to leverage (e.g. napi-rs & Oxc) in the Rust-for-JS ecosystem. For Rollup: the Rollup team itself has been trying to incrementally improve Rollup's performance, e.g. by swapping acorn with a Rust-based parser. But there's only so much you can gain starting from a pure JavaScript base, especially considering multicore utilization. Another aspect of the performance is in the back-and-forth between Rollup (on the JS side) and native transforms (swc, esbuild) - there is a lot of overhead repeatedly parsing / serializing ASTs and then passing strings across JS/native. By building on top of Oxc (which will ship transforms in the future) we hope to be able to stay on the native-side as much as possible to avoid such overhead.
  - catlifeonmars 3y ago
    Thanks for the detailed explanation. It’s really interesting how much of an impact language choice has on outcomes. Given your description of esbuild, it almost feels like there is space for a bundler compiler that can generate an optimized bundler from a pipeline.
chucky 3y ago
Their about page (https://rolldown.rs/about https://rolldown.rs/about) 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?
- bastawhiz 3y ago
  One of the interesting things about rollup is how it compiles code. Instead of building each module as a closure, separating the scopes, it compiles everything as one big closure. This is actually faster to parse and run, and allows you to do much better tree shaking and other optimizations. If you're doing all that, you could probably support rollup plugins as well, which it sounds like they want to do.
- no_wizard 3y ago
  esbuild is and has always been governed strongly by Evan Wallace. I can't vouch for whether or not the Evans (both Wallace and You) talked to each other about it, but I'm almost 100% certain Wallaces' vision for the esbuild project is different than what rolldown is ultimately trying to achieve. In some respects, rolldown is also the next generation of Rollup (potentially) and is a direct answer to rspack[0], which is a webpack compatible rust based toolchain from ByteDance [0]: https://www.rspack.dev/ https://www.rspack.dev/
bhouston 3y ago
When can I use this in vite? Vite build is fast but this should make it way faster. Is there a way to enable this in Vite the near term to test?
- jasonjmcghee 3y ago
  They talked about it as a long term plan at a ViteConf and mentioned experimenting with it in the 5.1 release post https://vitejs.dev/blog/announcing-vite5-1.html https://vitejs.dev/blog/announcing-vite5-1.html
depr 3y ago
One of the authors has contributed to SWC. I wonder what caused them to build an alternative.
- the_mitsuhiko 3y ago
  I'm not sure how the projects ended up where they are, but Oxc which this relates to has a very specific vision of how to improve the experience for the JavaScript tooling ecosystem which I'm not sure SWC shares. https://oxc-project.github.io/docs/guide/introduction.html https://oxc-project.github.io/docs/guide/introduction.html I have used SWC internals recently for a toy project of mine and was generally let down a bit by some of the rather unwieldy internals, insufficient documentation and pretty hefty footprint.
- deleted 3y ago
  [deleted]
- no_wizard 3y ago
  In many ways its not an alternative, in particular, SWC does not handle resolving and other bundler specific concerns, and dropped the concept of JS interop with plugins (its all rust built WASM now). I also blame Vercel, they have put zero investment in documenting SWC. The person behind the project used to be more prolific in documenting things, and that all stopped once Vercel scooped them and the project up for use in turbopack (which has not materialized as a standalone solution like they promised, funnily enough)
  - ametrau 3y ago
    I would avoid anything by the company behind meteor.
lakpan 3y ago
The question is: is the output as good as Rollup? I haven’t seen a bundler that outputs code that isn’t junk that must be minified to be any good. With rollup, I can just ship it as a web extension and it’s still 100% readable.
- vlakreeh 3y ago
  Mostly curious, why do you care about the readability of the generated JS? Surely if you need to debug something for a production bundle you can use source maps.
  - lakpan 3y ago
    It’s not generated JS, it’s concatenated JS (plus some glue). Rollup make this clear. In web extensions you can’t quite use sourcemaps unless you include the sourcemap in the .js file or upload it to your own server
demi56 3y ago
[dead]
tekkk 3y ago
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.
brap 3y ago
The landing pages of Rolldown, Rollup and Vite all look the same. Is it the same people behind it? What other projects are there?
- rk06 3y ago
  They are using vitepress. Vue projects also use vitepress
  - gherkinnn 3y ago
    I didn't know about VitePress. This might just be the quickest way to render code-heavy markdown to HTML. Astro, Jekyll, Hugo and others always were just a bit too cumbersome for my taste.
polished-shoe 3y ago
Yet another bundler. Why should I adopt this one? 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.
- no_wizard 3y ago
  Its a Vite project and very much the same core team. This is another Evan You lead project, which gives me alot more hope than I normally do for these kinds of things, he has a knack for generating long term sponsorship of projects
brigadier132 3y ago
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. 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.
- tubthumper8 3y ago
  Bundling (including dead code elimination) is more used for frontend code to reduce the amount of JavaScript sent over the wire to browser. You don't need to bundle server-side code unless you're using a cloud provider that limits how much source code you can upload or some other limitation like that.
unroller 3y ago
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.
- steelbrain 3y ago
  Based on my experience in writing JS tooling (https://github.com/steelbrain/pundle https://github.com/steelbrain/pundle / https://aneesiqbal.ai/2020-05-17-what-i-dont-like-about-node-js/ https://aneesiqbal.ai/2020-05-17-what-i-dont-like-about-node... ), even if rollup stayed in js and continued to use magic string, but somehow gained multi-core capabilities and cheaper memory operations, it may be able to somewhat compete with the rust tooling. JS tooling is mostly single threaded. It is expensive to stringify a large AST and then parse it again over IPC vs just transferring an object (which is not allowed by runtime). This cost incentives more things happening in the same process, so there’s a limit to how fast you can be with JS
  - bsimpson 3y ago
    There was a moment a few years ago when steelbrain's pundle was the only tool I knew of with proper instant hot module replacement. It went the way that many one-man projects with no community backing so, which made me sad. I moved to Rollup, and then recently moved to Vite to get back on the instant HMR train. Thanks for your work in this space, steelbrain! pundle was awesome!
briantakita 3y ago
Why do you need chunking? Are there any use cases other than. Your js payload is huge and you are using a Single Page App?
- radus 3y ago
  Example: you use a large plotting library, but it's only needed on some pages. Chunking allows you to selectively load that code only where it's needed.
plz-remove-card 3y ago
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. [0] https://github.com/rollup/rollup/tree/master/rust https://github.com/rollup/rollup/tree/master/rust
- MrJohz 3y ago
  What platform was that that wasn't supported by Rollup (and Rust), but was supported by Esbuild (and Go)?
  - plz-remove-card 3y ago
    An illumos distribution which is supported by rust, and the rust stuff would successfully build but `npm install` wouldn't because they didn't provide binaries for that platform and it was much faster to just switch to esbuild than figure out all that was needed to get it supported. I only tried rollup from the beginning because the ES6 project I was trying to bundle suggested it.
cod1r 3y ago
I would like to shill rsbuild/rspack. Haven't used it extensively but the experience has been ok so far. :)
gsuuon 3y ago
Excited for this, Vite running on a single bundler means you can finally trust what you're seeing with the dev server.
- eyelidlessness 3y ago
  I’d love to get to a point where “dev mode” is just “build mode plus”, as in the build is identical except for additive things like automatically launching a local dev server, some notion of live updates/HMR that doesn’t require different dependency sources, dev specific affordances as environment flags rather than separate modules… For my own (edit: as in personal) projects I tend to just “dev in build mode” with some subset of that bolted on, because I’ve been burned so many times by “works in dev” issues.

186 points by bpierre 3y ago

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.

timschmidt 3y ago
Cargo and crates.io make it a cinch to include libraries which implement discrete chunks of the solution. The effect of opinionated defaults and an easy path to publishing coupled with the Rust community's passion for correctness and efficiency really play off each other to result in rapid expansion of library capabilities. Crates seem to be well modularized, there seems to be widespread agreement about which crates provide good solutions, and that results in widespread compatibility in the Rust ecosystem between complex codebases doing similar things. Working in such an environment is a dream. Need to add a feature? Chances are that someone out there has already built every piece of it and all you need to do is track them down and stitch them together.

catlifeonmars 3y ago

The “Why Rolldown” section cites two reasons: 1) esbuild isn’t good at splitting 2) rollup is too slow 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?

truckerbill 3y ago
A lot of the time the politics gets in the way. ‘It’s broken on purpose’ etc
danielheath 3y ago
> Why wasn’t it an option to improve esbuild’s splitting functionality or to improve rollup performance? Rollup is written in javascript; not only is the runtime slow, the multicore story is terrible. Improving esbuilds splitting functionality is hard because splitting is full of hard tradeoffs; the spec allows module imports to have side-effects and requires that they be evaluated in order. It's therefore impossible to do optimal code-splitting without violating the esmodule spec (potentially introducing subtle errors), and the `esbuild` project values correctness even more highly than performance. Personally, I'd be very happy with "If you enable the 'make it fast' option and have modules with top level side-effects, you will get weird bugs", but I respect where they're coming from in not wanting to do that.
- VincentEvans 3y ago
  Speaking of things “written in javascript” for the longest time all I kept hearing is how incredibly fast things written js are… Is it fair to say that it was a bit of a sales pitch? When key components of the ecosystem that were written in the language of the ecosystem itself are being rewritten in other languages - I think it’s hard to find a more compelling evidence that all is not as great as it was advertised.
  - steveklabnik 3y ago
    Everything is relative! Moreover, just because something is fast doesn’t mean it’s the fastest.
    - 9question1 3y ago
      I don't know what OP is referring to here, but from discussions like this: https://stackoverflow.com/a/4417485 https://stackoverflow.com/a/4417485 It seems like circa 2010 folks were referring to JavaScript as "fast" because it was more performant in some ways than other interpreted languages like Ruby and Python and those were the only major popular options at the time that people would consider for some use cases. The event loop model of JavaScript led to some creative use cases for having a single-threaded application handle many highly parallel requests that require very little CPU usage or computation but a large amount of blocking I/O, which I think was also pitched as "fast". But I think it's always been uncontroversial that interpreted languages like JS, Ruby, and Python are all "slow" compared to compiled ones for CPU heavy use cases.
pjmlp 3y ago
Both of those options imply not using Rust, hence why. I tend to think Rust isn't suitable to rewrite JavaScript tooling, any compiled language would do, or even native addons, but apparently dealing with borrow checker for userspace software that doesn't require 1us performance within 512 KB is appealing. Currently watching https://www.infoq.com/presentations/rust-javascript/ https://www.infoq.com/presentations/rust-javascript/
- michaelmior 3y ago
  > I tend to think Rust isn't suitable to rewrite JavaScript tooling > any compiled language would do So why not Rust?
  - RamblingCTO 3y ago
    Wrong question. Why rust?
    - seanhunter 3y ago
      Because the people who actually want to do the work want to do it in rust.
      - todotask 3y ago
        With both Vite and TailwindCSS v4 written in Tailwind, web development is going to be faster for Astro and other frameworks.
        no_wizard 3y ago
        >TailwindCSS v4 written in Tailwind Didn't realize it was a self bootstrapping language now. Thats awesome
      - RamblingCTO 3y ago
        That's a fair answer. Although I still don't agree with rust being particularly fitting for that problem.
sondr3 3y ago
I can't speak for the authors of Rolldown, but esbuild is essentially a one-man show and everything is bespoke and written for esbuild. Not saying this as a bad thing, Evan single-handedly improved bundling performance for Node and started us down this path of tools in Rust. The libraries and ecosystem for writing tooling for other languages is really taking off with projects like oxc, SWC, LightningCSS, Biome, rslint, Deno, rspack, napi-rs/Neon for JS/TS/Node etc plus ruff, uv, rattler, pixi for Python and so on, so you get a proliferation of libraries and authors that can share and help each other. Plus, on a personal level, using a language with pattern matching and algebraic data types makes writing tooling for parsers and such much more ergonomic than in languages without.
- cAtte_ 3y ago
  note that esbuild is written in go, not rust
  - sondr3 3y ago
    Yep, forgot to mention that in my post, thanks.
  - dunham 3y ago
    Also, it was originally written in both Go and Rust, and the author decided to continue in Go. Both are fine languages, but it makes an interesting case study: https://news.ycombinator.com/item?id=22336284 https://news.ycombinator.com/item?id=22336284
    - pcthrowaway 3y ago
      Wow, thank you for sharing this. The author echoes a lot of thoughts I've had working with rust. However, doesn't the explanation given for why the Go version was 10% faster mean that esbuild was built to take advantage of a fixed number of cores rather than all of them? Sorry if this is a dumb question, I'm not really that experienced with parallel computation
      - 3y ago
swsieber 3y ago
I mean... if it was me: 1) I know Rust, not Go (esbuild is written in go-lang) 2) I don't have to worry as much about breaking Rollup, and I'm not nearly as confident in my ability to write performant JS as I am in writing performant Rust.
- Tade0 3y ago
  My experience is that the main reason why Rust is faster than JS in some applications is that the latter tends to do a lot of copying and other memory-intensive tasks - especially those related to running the JS virtual machine. If you can reduce the problem to a series of operations on pre-allocated typed arrays, JS is fast enough. Unfortunately in the case of Rollup that would be hard to do.
no_wizard 3y ago
esbuild is and has always been governed strongly by Evan Wallace. I can't vouch for whether or not the Evans (both Wallace and You) talked to each other about it, but I'm almost 100% certain Wallaces' vision for the esbuild project is different than what rolldown is ultimately trying to achieve. In some respects, rolldown is also the next generation of Rollup[0] and is a direct answer to rspack[1], which is a webpack compatible rust based toolchain from ByteDance [0]: Which switched to SWC as its underlying parser from acorn, which makes me wonder if that influenced the decision to use OXC, perhaps they found SWC to be troublesome. I know the Rollup and Vite teams are extremely close, and wouldn't be shocked if any troubles they had with SWC weren't shared with the Vite team when considering underlying technologies [1]: https://www.rspack.dev/ https://www.rspack.dev/
Thaxll 3y ago
The real reason is that author wanted to use Rust ( as he previously done ) and does not really care about improving existing solution. From the start you want to use x.y.z tech then the justification is meaningless.
WorldMaker 3y ago
> 1) esbuild isn’t good at splitting I've found esbuild is pretty good at splitting when source formats and outputs are ESM. (Given the name esbuild a focus on/priority for ESM input/output makes sense to me.) Is this maybe Vite team saying that they still have too many brownfield CJS dependencies and still don't believe in ESM output for production bundles in 2024?
- rk06 3y ago
  Even if their dependencies were esm only, Vote may be used in projects which have cjs dependencies. Hence need to support it
  - WorldMaker 3y ago
    esbuild handles CJS dependencies just fine and had been what Vite was using in development for a long time anyway. It doesn't split CJS dependencies or tree-shake them as automatically/smartly as it could, but it still supports splitting them and there are manual workarounds. I think the bigger problem, from my experience here, is still the question of not moving to ESM as the default production output. That seems out of date.
nox101 3y ago
agreed... Personally I feel like moving a JS tool to rust means 99% of JS/TS programmers are unlikely to be able to supply a patch to fix a bug or participate in most ways. I suspect some people will consider that a good thing though.
EvanYou 3y ago
For esbuild: We know other teams that have attempted to improve code splitting based on esbuild and found it very difficult. A big part of it is that in order to be fast, esbuild applies multiple features (bundle, treeshaking, transforms) in as few AST visits possible, but that comes at the cost of the logic of different features not being layered / decoupled nicely. It is difficult for anyone other than Evan Wallace himself to add non-trivial new mechanisms to esbuild, and although we didn't directly talk to Evan about this, we felt it would be too much to ask for a substantial refactor of esbuild in order to get what we need. In addition, the people interested in making Rolldown happen has much more experience in Rust than in Go - and there is a lot more to leverage (e.g. napi-rs & Oxc) in the Rust-for-JS ecosystem. For Rollup: the Rollup team itself has been trying to incrementally improve Rollup's performance, e.g. by swapping acorn with a Rust-based parser. But there's only so much you can gain starting from a pure JavaScript base, especially considering multicore utilization. Another aspect of the performance is in the back-and-forth between Rollup (on the JS side) and native transforms (swc, esbuild) - there is a lot of overhead repeatedly parsing / serializing ASTs and then passing strings across JS/native. By building on top of Oxc (which will ship transforms in the future) we hope to be able to stay on the native-side as much as possible to avoid such overhead.
- catlifeonmars 3y ago
  Thanks for the detailed explanation. It’s really interesting how much of an impact language choice has on outcomes. Given your description of esbuild, it almost feels like there is space for a bundler compiler that can generate an optimized bundler from a pipeline.

chucky 3y ago

Their about page (https://rolldown.rs/about https://rolldown.rs/about) 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?

bastawhiz 3y ago
One of the interesting things about rollup is how it compiles code. Instead of building each module as a closure, separating the scopes, it compiles everything as one big closure. This is actually faster to parse and run, and allows you to do much better tree shaking and other optimizations. If you're doing all that, you could probably support rollup plugins as well, which it sounds like they want to do.
no_wizard 3y ago
esbuild is and has always been governed strongly by Evan Wallace. I can't vouch for whether or not the Evans (both Wallace and You) talked to each other about it, but I'm almost 100% certain Wallaces' vision for the esbuild project is different than what rolldown is ultimately trying to achieve. In some respects, rolldown is also the next generation of Rollup (potentially) and is a direct answer to rspack[0], which is a webpack compatible rust based toolchain from ByteDance [0]: https://www.rspack.dev/ https://www.rspack.dev/

bhouston 3y ago

When can I use this in vite? Vite build is fast but this should make it way faster. Is there a way to enable this in Vite the near term to test?

jasonjmcghee 3y ago
They talked about it as a long term plan at a ViteConf and mentioned experimenting with it in the 5.1 release post https://vitejs.dev/blog/announcing-vite5-1.html https://vitejs.dev/blog/announcing-vite5-1.html

depr 3y ago

One of the authors has contributed to SWC. I wonder what caused them to build an alternative.

the_mitsuhiko 3y ago
I'm not sure how the projects ended up where they are, but Oxc which this relates to has a very specific vision of how to improve the experience for the JavaScript tooling ecosystem which I'm not sure SWC shares. https://oxc-project.github.io/docs/guide/introduction.html https://oxc-project.github.io/docs/guide/introduction.html I have used SWC internals recently for a toy project of mine and was generally let down a bit by some of the rather unwieldy internals, insufficient documentation and pretty hefty footprint.
deleted 3y ago
[deleted]
no_wizard 3y ago
In many ways its not an alternative, in particular, SWC does not handle resolving and other bundler specific concerns, and dropped the concept of JS interop with plugins (its all rust built WASM now). I also blame Vercel, they have put zero investment in documenting SWC. The person behind the project used to be more prolific in documenting things, and that all stopped once Vercel scooped them and the project up for use in turbopack (which has not materialized as a standalone solution like they promised, funnily enough)
- ametrau 3y ago
  I would avoid anything by the company behind meteor.

lakpan 3y ago

The question is: is the output as good as Rollup? I haven’t seen a bundler that outputs code that isn’t junk that must be minified to be any good. With rollup, I can just ship it as a web extension and it’s still 100% readable.

vlakreeh 3y ago
Mostly curious, why do you care about the readability of the generated JS? Surely if you need to debug something for a production bundle you can use source maps.
- lakpan 3y ago
  It’s not generated JS, it’s concatenated JS (plus some glue). Rollup make this clear. In web extensions you can’t quite use sourcemaps unless you include the sourcemap in the .js file or upload it to your own server

demi56 3y ago

[dead]

tekkk 3y ago

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.

brap 3y ago

The landing pages of Rolldown, Rollup and Vite all look the same. Is it the same people behind it? What other projects are there?

rk06 3y ago
They are using vitepress. Vue projects also use vitepress
- gherkinnn 3y ago
  I didn't know about VitePress. This might just be the quickest way to render code-heavy markdown to HTML. Astro, Jekyll, Hugo and others always were just a bit too cumbersome for my taste.

polished-shoe 3y ago

Yet another bundler. Why should I adopt this one? 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.

no_wizard 3y ago
Its a Vite project and very much the same core team. This is another Evan You lead project, which gives me alot more hope than I normally do for these kinds of things, he has a knack for generating long term sponsorship of projects

brigadier132 3y ago

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

tubthumper8 3y ago
Bundling (including dead code elimination) is more used for frontend code to reduce the amount of JavaScript sent over the wire to browser. You don't need to bundle server-side code unless you're using a cloud provider that limits how much source code you can upload or some other limitation like that.

unroller 3y ago

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.

steelbrain 3y ago
Based on my experience in writing JS tooling (https://github.com/steelbrain/pundle https://github.com/steelbrain/pundle / https://aneesiqbal.ai/2020-05-17-what-i-dont-like-about-node-js/ https://aneesiqbal.ai/2020-05-17-what-i-dont-like-about-node... ), even if rollup stayed in js and continued to use magic string, but somehow gained multi-core capabilities and cheaper memory operations, it may be able to somewhat compete with the rust tooling. JS tooling is mostly single threaded. It is expensive to stringify a large AST and then parse it again over IPC vs just transferring an object (which is not allowed by runtime). This cost incentives more things happening in the same process, so there’s a limit to how fast you can be with JS
- bsimpson 3y ago
  There was a moment a few years ago when steelbrain's pundle was the only tool I knew of with proper instant hot module replacement. It went the way that many one-man projects with no community backing so, which made me sad. I moved to Rollup, and then recently moved to Vite to get back on the instant HMR train. Thanks for your work in this space, steelbrain! pundle was awesome!

briantakita 3y ago

Why do you need chunking? Are there any use cases other than. Your js payload is huge and you are using a Single Page App?

radus 3y ago
Example: you use a large plotting library, but it's only needed on some pages. Chunking allows you to selectively load that code only where it's needed.

plz-remove-card 3y ago

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. [0] https://github.com/rollup/rollup/tree/master/rust https://github.com/rollup/rollup/tree/master/rust

MrJohz 3y ago
What platform was that that wasn't supported by Rollup (and Rust), but was supported by Esbuild (and Go)?
- plz-remove-card 3y ago
  An illumos distribution which is supported by rust, and the rust stuff would successfully build but `npm install` wouldn't because they didn't provide binaries for that platform and it was much faster to just switch to esbuild than figure out all that was needed to get it supported. I only tried rollup from the beginning because the ES6 project I was trying to bundle suggested it.

cod1r 3y ago

I would like to shill rsbuild/rspack. Haven't used it extensively but the experience has been ok so far. :)

gsuuon 3y ago

Excited for this, Vite running on a single bundler means you can finally trust what you're seeing with the dev server.

eyelidlessness 3y ago
I’d love to get to a point where “dev mode” is just “build mode plus”, as in the build is identical except for additive things like automatically launching a local dev server, some notion of live updates/HMR that doesn’t require different dependency sources, dev specific affordances as environment flags rather than separate modules… For my own (edit: as in personal) projects I tend to just “dev in build mode” with some subset of that bolted on, because I’ve been burned so many times by “works in dev” issues.