JavaScript Developers Are Using Shiny Rusty Tools. Here’s Why. | by djangsters | Nov, 2022

The benchmark results of Next.js 12 are convincing. But is it worth the switch?

At our recent team building event, I talked about why JavaScript developers are moving their tools to Rust. It was a great response and we decided it would be cool to share it with the world. So here it is. This is an edited version of the conversation, written to be read and will be a screencast on our podcast channel. So let’s dive straight into it.

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.

Javascript is no exception. From Gulp and Bower to Babel and Webpack, we’ve written it all in JavaScript. It worked well for us but there were some problems.

We need to look at the properties of JavaScript to see the problem. JavaScript is a lightweight, scripting language for web pages. Sure we use it everywhere now, from the backend to the database, but it was originally created to make pages look shiny first and everything else afterwards, which shows.

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.

While Javascript is terrible on a page, it kinda sucks on a console.

So a group 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 our JavaScript builder tools in JavaScript?”

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

Ok I may have made it up but the result is still the same, now we are creating Javascript build tools in languages ​​other than Javascript.

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++.

promising claims

There are many projects now that want to replace JavaScript tools with Rust-based ones. Some examples are ParcelJS, Deno, ESBuild, and Speedy Web Compiler (SWC). They all claim to perform faster than whatever they are trying to replace and if you want a chuckle take a look esbuild comparison,

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)

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

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?

Because it was not working properly. As I said earlier Javascript is great on a page but sucks on a console. Developer machines are powerful beasts and not harnessing this power is a terrible waste. It is also an expensive waste.

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.

JavaScript is an amazing language and without it the internet would not be where it is. But we don’t need to use it to build our tools because there are harder, better, faster, stronger languages ​​out there, like Rust, and that’s fine. It doesn’t take away from JavaScript and it isn’t a betrayal to abandon JavaScript-based built tools for increasingly rusty ones. And let’s face it, I’m not going to suffer through multiple JavaScript examples just to get voodoo multi-threading.

Leave a Reply