The benchmark results of Next.js 12 are convincing. But is it worth the switch?
A general trend in software is to write the tools we developers use to build our applications in the same language we use to build our applications. For example, pip is written in Python, composer is written in PHP, Maven in Java, etc. This is understandable because most of the times the people who make the tools are also the ones who use them. So it is easy to work in the language of their choice.
It is an interpreted language that can be compiled just in time and is single-threaded. Yes, yes, I know about spinning up multiple instances and communicating with web workers… but in my opinion, it’s not multi-threading, it’s a weird voodoo workaround to distract us from the fact that trying to we don’t have native multi-threading,
One big problem is that it’s pretty slow on consoles compared to other languages.
There was a collective gasp, chairs were thrown, fights broke out, and after the dust had settled, everyone agreed to give it a try.
In a word… speed and buffer-overflow 😉.
Rust is a multi-paradigm, general-purpose programming language designed for performance and security. It’s like C++ but for Millennials and Zoomers. It is a system language that implements memory protection and has “safe” concurrency. It is syntactically similar to C++ and more importantly, it is almost as fast as C++.
For the sake of this post, I won’t look at all of them, but I will take a closer look at SWC via Next.JS.
Speedy Web Compiler (SWC)
Latest Next.js Rusty Tools
Next.js introduced the Rust compiler in version 12, based on SWC. On the Next.js site they claim ~3 times faster refresh locally and ~5 times faster production builds.
This sounds like a testable claim to me. That’s why I tested it.
I created the exact same project in version 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 the same.
The results were quite reassuring. Here it is for Next.js 11:
And for Next.js 12, here it is:
Next.js 12 took 12 seconds to do what Next.js 11 did in 1 minute 40 seconds. It’s about 8 times faster. So they clearly weren’t exaggerating.
I didn’t expect Next.js 12 to take 12 seconds. Let’s just say it was a happy coincidence.
Now the obvious question is: is it worth the hustle?
At the end of the day that’s the application we’re building, right? It doesn’t change the end-user experience to just a developer experience, so why bother? Why fix what was already working fine?
Imagine you are in a team of 20 developers working on a large project that is deployed and tested on cloud-based CI. Every day each member of your team pushes a number of improvements and features, here’s what’s likely to happen.
If your CI offers unlimited concurrent builds but charges by the build minute or second of processor time then Next.JS will actually cost you 8x more than Next.JS 12.
On the other hand, if it returns a fixed price and a fixed number of concurrent builds then you are going to wait a while if your build queue grows or you will have to pay to increase the number of concurrent builds that you can run. Huh.
Either way, slow manufacturing costs you more in time or money, or both.