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.
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.
There was a collective gasp, chairs were thrown, fights broke out and after the dust settled, everybody agreed to try it out.
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++.
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)
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?
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.