>Compilation using Rust is 17x faster than Babel and enabled by default using Next.js 12, replacing transforming JavaScript and TypeScript files.
I've never, ever felt constrained by Babel performance. Even in massive 100k+ LOC codebases. I have, however, been burned over and over again by introducing native binaries into the build process. We specifically moved off of node-sass to using PostCSS for this very reason.
I'm not completely sure how these Rust binaries will work, but if they are in any way less universal than Node, it's going to cause problems across dev and CI build environments.
I think one of the biggest issues with node-sass was that it only supported a narrow set of node versions and platforms, which resulted in a lot more compilation from source. I definitely remember fighting with node-gyp and such, and pretty quickly ditched it for dart sass as soon as that was a viable alternative.
Next.js looks like it's shipping binaries for swc for a wide Node range (>=10), on a pretty comprehensive combination of operating systems and architectures:
- android-arm64
- darwin-arm64
- darwin-x64
- linux-arm-gnueabihf
- linux-arm64-gnu
- linux-arm64-musl
- linux-x64-gnu
- linux-x64-musl
- win32-arm64-msvc
- win32-ia32-msvc
- win32-x64-msvc
Unfortunately I don't have access to a system that _doesn't_ have a pre-built binary, so I have no idea what would happen if you tried to install Next.js on an unsupported architecture. That being said, I'd love to see the Next.js team ship a WASM version of SWC for such systems, which should ensure that when there's not a pre-built binary, at least you won't be asked to install a Rust compiler.
I actually upgraded my team's Jest config to use https://github.com/Brooooooklyn/swc-node a few weeks ago. However, our Jenkins CI agents run RHEL7, and neither of the Linux binary targets would run. The `x64-gnu` binary needed a `GLIBC_2_23` symbol when only 2.18 was available, and the `x64-musl` binary had no `musl-libc` on the machine. I don't own the Jenkins agents, so I couldn't install other deps myself.
I ended up building `musl-libc` from source on another RHEL7 agent, committed the `.so` to our repo, and added that to the `LD_LIBRARY_PATH` in our Jenkinsfile, and actually got that working.
I did see some mentions that Rust could build to target an older GLibc ( https://kobzol.github.io/rust/ci/2021/05/07/building-rust-bi... ), so I'm curious if Next is going to use copies of SWC built that way for better compat or if it will require more workarounds on my part.
I can definitely see shipping a WASM version as a great workaround to those sorts of compat issues.
Hard disagreement here. Seen so many slow builds / hot-reloads over the years. It's draining to work on a project where changing a file takes a couple of seconds to be live in the browser. Almost so that I believe those not complaining about webpack's or babel's speed just don't know what they're missing out on.
SWC uses napi-rs to talk to N-API. NAPI-RS's convention is to ship binaries as npm packages which should avoid a lot of the pain which came from having to download pre-compiled files from a file server. Compiling other platforms shouldn't be necessary, but if it is it will be slightly more difficult than using traditional gyp or cmake. You would have to setup a Rust toolchain, but after thats its relatively easy.
I haven’t used SWC extensively, but with ESBuild (written in Go) this has been a non-issue for me. I’ve experienced the pain of native bindings in other projects though, it largely depends on how resilient the native bindings are to different Node/V8 APIs across versions.
I've never, ever felt constrained by Babel performance. Even in massive 100k+ LOC codebases. I have, however, been burned over and over again by introducing native binaries into the build process. We specifically moved off of node-sass to using PostCSS for this very reason.
I'm not completely sure how these Rust binaries will work, but if they are in any way less universal than Node, it's going to cause problems across dev and CI build environments.