Hacker News Reader

Comment by capableweb | Hacker News Reader

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

View on HN

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

[2] https://github.com/padmaia/next.js/blob/cf1d081c5b2f55085ceb...

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

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.

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…

If you want a bundler built using SWC as a base today, check out Parcel: https://parceljs.org

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.

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

That's basically what Sucrase.js is:

https://github.com/alangpierce/sucrase

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.

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.

> I believe esbuild was started first

That seems incorrect.

- "put on github" - evanw committed on Jan 15, 2020 - https://github.com/evanw/esbuild/commit/23c40b1b6a76a8626f1d...

- "initial commit" - kdy1 committed on Dec 22, 2017 - https://github.com/swc-project/swc/commit/0f9532dd5d379292cc...

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.

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

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

Reply on news.ycombinator.com