16 ms·

How does it compare to esbuild? Seems they both want to achieve exactly the same thing, but somehow it's two different efforts.

jacobmischka 5y ago
They are two different efforts, started a little while ago, one in Go and one in Rust. I believe esbuild was started first, but they both seem to be maturing rather well lately.
- capableweb 5y ago
  > I believe esbuild was started first That seems incorrect. - "put on github" - evanw committed on Jan 15, 2020 - https://github.com/evanw/esbuild/commit/23c40b1b6a76a8626f1d160f89677ed2c73b6090 https://github.com/evanw/esbuild/commit/23c40b1b6a76a8626f1d... - "initial commit" - kdy1 committed on Dec 22, 2017 - https://github.com/swc-project/swc/commit/0f9532dd5d379292cc2d67777a108d88803bad91 https://github.com/swc-project/swc/commit/0f9532dd5d379292cc...
  - hardwaregeek 5y ago
    Judging by the commit messages the first esbuild commit seems like Evan moved an existing project onto GitHub while the SWC commit seems like a genuine start. But also pretty unlikely that esbuild was being worked on for 3 years before being put on GitHub so your point still stands.
dstaley 5y ago
One thing to keep in mind is that SWC is a compiler, whereas esbuild is a bundler. SWC has limited bundling capabilities last time I checked, so if you're looking for something to traverse your code and generate a single file (or multiple files at dynamic import boundaries, etc.) esbuild is what you want. Next.js bundles with webpack, so it uses SWC in lieu of Babel (or the TypeScript Compiler).
- Rauchg 5y ago
  We are going all in on swcpack (spack) as well. One of the benefits of swc-as-platform is the rich ecosystem of tooling we will see develop from it. Transforming, bundling, prettifying, optimizing… all at peak performance.
  - SOLAR_FIELDS 5y ago
    Am I being cynical in that you could have simply replaced swcpack with “webpack” 6 years ago and it would have made perfect sense? Feels like we have been here before…
- devongovett 5y ago
  If you want a bundler built using SWC as a base today, check out Parcel: https://parceljs.org https://parceljs.org
theobeers 5y ago
I’ve tried both; found that both definitely solve the performance issues that they’re intended to address; and decided that I just prefer using esbuild. As much as I appreciate Rust, the idea that Rust (swc) vs. Go (esbuild) would matter in this context doesn’t make sense to me. The switch to a compiled language is what’s night-and-day.
- hajile 5y ago
  I wonder if it's the compiled code entirely or also the architecture. Babel has a notoriously flexible design with tons of extensions reaching in and messing with things. I'd bet that you could probably get close to 2x the performance if you stripped it down to the same feature set (it would still be 2-3x slower, but a dramatic improvement).
  - acemarke 5y ago
    That's basically what Sucrase.js is: https://github.com/alangpierce/sucrase https://github.com/alangpierce/sucrase
Rauchg 5y ago
I think esbuild is a fantastic project as well as a huge inspiration. I'll share two quick thoughts[1] I have on SWC that made it a fantastic choice for Next.js: 1. SWC is designed for extensibility We were able to use `swc` as a crate[2], without the need to fork the project This allowed us to effectively (no divergence) and efficiently (no loss in performance) extend it, especially to add syntax and plugin compatibility that is more common in the Next.js ecosystem. We added support for `<style jsx>`, with more React optimizations and Babel plugins coming. 2. We love the Rust ecosystem It has a stellar, growing community. It has the best long-term performance prospects for us (e.g: absolute control over memory management) and safety. We don't want to be in a position where there's another enticing migration in just a couple years, and we think Rust is a durable non-regrettable choice. [1] https://twitter.com/rauchg/status/1425520232202792962 https://twitter.com/rauchg/status/1425520232202792962 [2] https://github.com/padmaia/next.js/blob/cf1d081c5b2f55085cebc9509b13c67c4bf34bd1/packages/next/build/swc/src/lib.rs#L40-L46 https://github.com/padmaia/next.js/blob/cf1d081c5b2f55085ceb...
- The_rationalist 5y ago
  But you could use vite/rollup/esbuild for bundling instead of Webpack and SWC for TS and other transforms.
0x142857 5y ago
esbuild is a bundler like webpack, it also does Typescript transform but the API is limited, e.g. you can't access the ast. Meanwhile swc is a Rust alternative to Babel.
pistoriusp 5y ago
Esbuild doesn't polyfill, it's a bundler that also transpiles.
nicoburns 5y ago
It's pretty similar, but esbuild is still a bit more mature.

jacobmischka 5y ago

They are two different efforts, started a little while ago, one in Go and one in Rust. I believe esbuild was started first, but they both seem to be maturing rather well lately.

capableweb 5y ago
> I believe esbuild was started first That seems incorrect. - "put on github" - evanw committed on Jan 15, 2020 - https://github.com/evanw/esbuild/commit/23c40b1b6a76a8626f1d160f89677ed2c73b6090 https://github.com/evanw/esbuild/commit/23c40b1b6a76a8626f1d... - "initial commit" - kdy1 committed on Dec 22, 2017 - https://github.com/swc-project/swc/commit/0f9532dd5d379292cc2d67777a108d88803bad91 https://github.com/swc-project/swc/commit/0f9532dd5d379292cc...
- hardwaregeek 5y ago
  Judging by the commit messages the first esbuild commit seems like Evan moved an existing project onto GitHub while the SWC commit seems like a genuine start. But also pretty unlikely that esbuild was being worked on for 3 years before being put on GitHub so your point still stands.

dstaley 5y ago

One thing to keep in mind is that SWC is a compiler, whereas esbuild is a bundler. SWC has limited bundling capabilities last time I checked, so if you're looking for something to traverse your code and generate a single file (or multiple files at dynamic import boundaries, etc.) esbuild is what you want. Next.js bundles with webpack, so it uses SWC in lieu of Babel (or the TypeScript Compiler).

Rauchg 5y ago
We are going all in on swcpack (spack) as well. One of the benefits of swc-as-platform is the rich ecosystem of tooling we will see develop from it. Transforming, bundling, prettifying, optimizing… all at peak performance.
- SOLAR_FIELDS 5y ago
  Am I being cynical in that you could have simply replaced swcpack with “webpack” 6 years ago and it would have made perfect sense? Feels like we have been here before…
devongovett 5y ago
If you want a bundler built using SWC as a base today, check out Parcel: https://parceljs.org https://parceljs.org

theobeers 5y ago

I’ve tried both; found that both definitely solve the performance issues that they’re intended to address; and decided that I just prefer using esbuild. As much as I appreciate Rust, the idea that Rust (swc) vs. Go (esbuild) would matter in this context doesn’t make sense to me. The switch to a compiled language is what’s night-and-day.

hajile 5y ago
I wonder if it's the compiled code entirely or also the architecture. Babel has a notoriously flexible design with tons of extensions reaching in and messing with things. I'd bet that you could probably get close to 2x the performance if you stripped it down to the same feature set (it would still be 2-3x slower, but a dramatic improvement).
- acemarke 5y ago
  That's basically what Sucrase.js is: https://github.com/alangpierce/sucrase https://github.com/alangpierce/sucrase

Rauchg 5y ago

I think esbuild is a fantastic project as well as a huge inspiration. I'll share two quick thoughts[1] I have on SWC that made it a fantastic choice for Next.js: 1. SWC is designed for extensibility We were able to use `swc` as a crate[2], without the need to fork the project This allowed us to effectively (no divergence) and efficiently (no loss in performance) extend it, especially to add syntax and plugin compatibility that is more common in the Next.js ecosystem. We added support for `<style jsx>`, with more React optimizations and Babel plugins coming. 2. We love the Rust ecosystem It has a stellar, growing community. It has the best long-term performance prospects for us (e.g: absolute control over memory management) and safety. We don't want to be in a position where there's another enticing migration in just a couple years, and we think Rust is a durable non-regrettable choice. [1] https://twitter.com/rauchg/status/1425520232202792962 https://twitter.com/rauchg/status/1425520232202792962 [2] https://github.com/padmaia/next.js/blob/cf1d081c5b2f55085cebc9509b13c67c4bf34bd1/packages/next/build/swc/src/lib.rs#L40-L46 https://github.com/padmaia/next.js/blob/cf1d081c5b2f55085ceb...

The_rationalist 5y ago
But you could use vite/rollup/esbuild for bundling instead of Webpack and SWC for TS and other transforms.

0x142857 5y ago

esbuild is a bundler like webpack, it also does Typescript transform but the API is limited, e.g. you can't access the ast. Meanwhile swc is a Rust alternative to Babel.

pistoriusp 5y ago

Esbuild doesn't polyfill, it's a bundler that also transpiles.

nicoburns 5y ago

It's pretty similar, but esbuild is still a bit more mature.