JavaScript Developers Are Using Shiny Rusty Tools. Here’s Why.

At our recent team building event, I gave a talk on why JavaScript developers are moving their tools to Rust. It was a pretty well-received talk and we decided that it would be cool to share it with the world. So here it is. This is the edited version of the talk, written for reading and there is also a screencast on our Youtube channel. So let’s dive straight into it.

Background

A common trend in software is to write the tools we as developers use to build our applications in the same language we use to build applications. For example, pip is written in Python, Composer is written in PHP, Maven in Java, etc. This makes sense because most times the people creating the tools are also the ones using them. So it’s easier to just work in their language of choice.

JavaScript is no exception. From Gulp and Bower to babel and Webpack we wrote it all in JavaScript. This worked well for us but there were a few problems.

The Problem with JavaScript

To see the problem we have to look at the properties of JavaScript. JavaScript is a lightweight, scripting language for Web pages. Sure we now use it everywhere, from backends to databases, but it was originally made for making pages shiny first and everything else second, which shows.

It is an interpreted language that can be just-in-time compiled and is single-threaded. Yes, yes, I know about spinning up multiple instances and communicating with web workers… but in my opinion, that’s not multi-threading, that’s a weird voodoo workaround that’s trying to distract us from the fact we do not have native multi-threading.

A bigger issue is that it’s pretty slow on the console, as compared to other languages.

While JavaScript is awesome on a page it kinda sucks on a console.

So a bunch of JavaScript developers got together in a dark room one day and after one too many drinks someone said:

“Hey guys, what if… hear me out… what if we don’t write the tools that build our JavaScript, in JavaScript?”

There was a collective gasp, chairs were thrown, fights broke out and after the dust settled, everybody agreed to try it out.

Ok, I might have made that up but the result is still the same, we are now making JavaScript build tools in languages other than JavaScript.

But Why Rust?

In one word… speed and buffer-overflows 😉.

Rust is a multi-paradigm, general-purpose programming language designed for performance and safety. It’s like C++ but for millennials and zoomers. It’s a system language that enforces memory safety and has “safe” concurrency. It is syntactically similar to C++ and more importantly, it’s almost as fast as C++.

Promising Claims

There are a number of projects out now that seek to replace JavaScript tools with Rust-based ones. A few examples are ParcelJS, Deno, ESBuild, and the Speedy Web Compiler (SWC). They all claim to perform faster than whatever they are trying to replace and if you want a chuckle check out the esbuild comparison.

For this post, I won’t be checking out all of them but I will be taking a closer look at SWC via Next.js.

Speedy Web Compiler (SWC)

SWC is an extensible Rust-based platform for the next generation of fast developer tools. That means, it is a framework to build builders. You can use SWC for both compilation and bundling. It will take JavaScript / TypeScript files using modern JavaScript features and spit out valid code that is supported by all major browsers.

The Latest Next.js Rusty tools

Next.js introduced a Rust compiler in version 12 based on SWC. On the Next.js site they claimed ~3x faster refresh locally and ~5x faster production builds.

That sounds like a testable claim to me. So I tested it.

I created the exact same project in versions 11 and 12 and added the same 400 generated components. I used React Benchmark Generator for this. The only difference between the projects was the version of Next.js, everything else was identical.

The results were pretty convincing. Here’s for Next.js 11:

And for Next.js 12, here you go:

Next.js 12, took 12 seconds to do what Next.js 11 did in 1 minute 40 seconds. That’s roughly 8 times faster. So they clearly weren’t exaggerating.

I also didn’t expect Next.js 12 to take 12 seconds. Guess that was a happy coincidence.

Is It Worth the Hype?

Now the obvious question is: is it worth the hustle?

The application we are building at the end of the day is the same right? This doesn’t change the end-user experience only the developer experience so why bother? Why fix something that was already working fine?

Because it wasn’t working fine. As I said before JavaScript is great on a page but sucks on a console. Developer machines are powerful beasts and not utilizing this power is a terrible waste. It’s also an expensive waste.

Imagine you are in a team of 20 developers working on a large project that is deployed and tested on a cloud-based CI. Every day each member of your team pushes out multiple fixes and features, here’s what’s likely to happen.

If your CI gives unlimited concurrent builds but charges by the build minute or by seconds of processor time then Next.js will literally cost you 8x more than Next.js 12 would.

On the other hand, if it gives a fixed price and a fixed number of concurrent builds then you are going to be waiting for a while if your build queue grows or you will have to pay to increase the number of concurrent builds you can run.

Either way, slow builds cost you more in time or money, or both.

Conclusion

JavaScript is an amazing language and the internet wouldn’t be where it is without it. But we don’t have to use it to build our tools because there are harder, better, faster, stronger languages for that, like Rust, and that’s ok. It doesn’t take away from JavaScript and it’s not a betrayal to drop JavaScript-based built tools for faster Rust-based ones. And let’s face it, I am not going to suffer through multiple JavaScript instances just to get voodoo multi-threading.