If it works as advertised this is going to be great for a ton of JS/TS projects. Particularly having a 20x typescript compiler boost when running large test suites would be great. Maintaining 5-8 different babel related projects in packages.json is also annoying and often buggy.
Looking forward to see where else this gets adopted and it's stability.
We use this for TypeScript development at my company. Using swc for transpilation reduces build time from ~10s (small-ish codebase) to near instant. We can then wrap it in entr [1] to get live API reloading for free.
For type checking, you can run the TypeScript compiler in another window in watch mode, or just rely on editor warnings until the code hits CI.
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.
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…
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).
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.
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.
If it works as advertised this is going to be great for a ton of JS/TS projects. Particularly having a 20x typescript compiler boost when running large test suites would be great. Maintaining 5-8 different babel related projects in packages.json is also annoying and often buggy.
Looking forward to see where else this gets adopted and it's stability.