Swc-loader

0 views

Skip to first unread message

Cloris Sopha

unread,

Aug 3, 2024, 12:39:31 PM8/3/24

to visomina

The biggest improvement was reached with WSL operating on files in the Windows file system. A whopping 74% reduction in build time is reason enough to switch! This is a WSL 1 distro, so if that is your setup, it could be worth checking out whether you could receive the same benefit. A WSL 2 distro operating on a Linux file system got quite a speed boost as well with a 47% reduction in build time.

On macOS, the improvement was more modest. 20% is still a lot! But in absolute numbers, we only save about 20 seconds, compared with the minutes saved on the WSL builds. This is, however, still a point in SWCs favour.

Windows/powershell placed in the middle, with 33% build time decrease, saving almost a minute. What is interesting is that while babel/tsc had wildly varying build times on the different platforms, SWC has reduced the build times to be almost identical on all the platforms - they are obviously doing something right!

So, in case you want to test it out yourself, here is how we have configured SWC. Our frontend application uses a micro frontend architecture, which you can read more about in our blog post about it, and our motivation for choosing it.

As a summary: We have several standalone frontend apps that load components from each other. Each app is (currently) typescript/react based. They all have their own webpack config, which is the bundler we use. That means that we can, as of now, use the same SWC and webpack config for making all the apps use SWC.

You can read the full docs here to get an explanation of what the different options mean, but I will point out why we have two config objects. The test property on each object is used to determine if that config should be used on a given file that is sent to the swc-loader by, in our instance, webpack. The only two differences here is that if a ts/tsx file is supplied, we want to use typescript syntax and allow tsx, and if a js/jsx file is supplied, we want to use ecmascript syntax, and allow jsx.

For those of us using a windows/wsl combination, the change has been magical! If you are on other platforms, you could still get a nice speed boost, at least if your setup looks like ours. And as mentioned, SWC seems to give a more similar performance across platforms thant Babel/TSC did. Did you try out swc, and get different results? Have we configured it all wrong? Yell at us on Twitter!

There are a lot of details yet to figure out, as well as some concerns that are important but tangentially related. There are a few big ones that stand out in my mind. Forgive me if this is a bit speculative or has any glaring holes; these are complicated decisions, which is why I wanted to shed some light on them!

To say something that may sound a bit audacious - I believe that the default installation of the platform should be a single repository, frontend-platform, with all the default MFEs linked in as direct plugins through env.config.js. The MFEs are pre-built, pre-tested artifacts, released as packages on npm/Github. By default, you run one build command and have the entire platform ready to go.

Anyone who has need of more granular, decoupled deployment of MFEs can instead turn their direct plugin MFEs into module plugins loaded via module federation. The MFE is then independently deployed and is no longer built as part of the shell. This is just a configuration change (plus taking on the extra operational overhead we already have today). Additional MFEs and plugins are added via the same configuration.

Further, dependencies like the logging service, analytics service, Google analytics, tag manager, hot jar, Zendesk, and anything else loaded as a script tag in the header, can all be loaded via plugins and plugin slots; just non-visual ones.

I tried replacing babel-loader with swc-loader, and got it working with the Course Authoring MFE. The build time dropped only from 65s to 60s, which makes it hardly worth the effort. I then went to great pains to strip out all the SCSS from the MFE and disabled PostCSS, and the build time was reduced further from 60s to 48s, which is of course not realistic because we do need to actually compile the SCSS.

We can see a trend of replacing the current javascript tooling with faster tools written in go / rust. In this post, I decided to try esbuild and swc to see what performance improvement we can get in any application using create-react-app.

As your app is growing, the development environment and compilation are getting slower and slower, it can easily reach 10+ mins for the build time ?. To improve build time and ship code faster to production you might be interested in using these tools and get:

swc is a super-fast javascript/typescript compiler written in Rust. In the future you will be able to use swc to check your typescript files. swc is also creating its own webpack alternative called spack.

Internally create-react-app uses webpack to create a javascript bundle for our application. In your code, you use some ECMAScript features that are not yet available in all browsers (eg: async / await). Babel is used to compile the javascript / typescript files of your application in a backwards compatible version of javascript, meaning it can be used in older browser versions. We can speed up this process by internally replacing babel with esbuild / swc, the babel-loader is replaced by esbuild-loader / swc-loader and the code that needs to be processed is sent to the native (go or rust) binary instead of babel.

For a pretty small project, we can see that the build time is faster. For esbuild we can see that our build is more than 2x faster. esbuild is currently faster than swc as it also includes a minifier, so we can replace the default terser minifier with it.

In order to have the same results, these tools are not using webpack but rather their own implementation. In the future, I think we will see projects like create-react-app either drops webpack for another faster solution or see them moving the webpack loaders to these new tools written in go / rust.

But as these tools are quite new it will take some time to see them widely used. As of now replacing the webpack loaders seems like the best approach to get a nice performance improvement while still being able to use all the plugins that the webpack ecosystem provides.