It's Time to Upgrade Your JavaScript Developer Tools

JavaScript is everywhere. As the most popular language in the world right now, it's almost unavoidable. Especially if you're building things for the web. I personally hate JavaScript and tolerate TypeScript, but it's currently the best option for building websites, so I use it every day at work.

While WASM is promising and will eventually bring all major programming languages to the web, we're stuck with JavaScript when writing code for web browsers. But thankfully, all of the developer tooling we use can be written in languages other than JavaScript. Over the last few years this truth has slowly been realized as new developer tools have been written, released, and adopted by large portions of the JavaScript community. esbuild, parcel, rome, and more are taking market share from other tools written in JavaScript because of the pure speed gains that you can get from using fast, modern languages like Go and Rust.

The speed gains are substantial. For example, at work we replaced the following tools with newer ones written in Rust and saw the following performance gains:

• Webpack (55 second average) to Parcel (23 second average) = 32 seconds saved

• ts-jest (30 second average) to @swc/jest (15 second average) = 15 seconds saved

While we didn't ultimately choose Rome due to it being a very new library that we want to see develop a bit further before committing to, code formatting tools written in Rust could improve our build times even further:

• Prettier (14 second average) to Rome (8 second average) = 6 seconds saved

That's a total of 53 seconds saved between the build, running tests, and verifying code formatting consistency. Not bad! This saves workers time waiting for a local development server to spin up (which usually happens multiple times a day, especially if you're working on multiple code bases), plus you get those time savings on every one of your CI builds.

If you adopt these speed gains across your entire organization, that's a lot of time and money saved if you're paying for something like GitHub Actions, where usage is charged by the minute.

Plus, there's the added benefit of (theoretically) saving energy, which in turn reduces your application's overall CO2 footprint. Building and using efficient systems is one of the biggest things the software engineering profession can do to play our role addressing the impending climate change catastrophe.

So why not make the switch?

Obviously there are a few concerns:

• Familiarity with tools. It can be difficult to learn new systems. Thankfully, many of these projects are written with existing workflows in mind (@swc/jest was literally up and running with a single line of code being changed), but adopting any new tool comes with a new burden of learning its intricacies.

• Time needed to make the switch. Even though some tools are easy to swap in, not every one will be. I think I spent around a full day of work over three months hacking together the Webpack to Parcel.js migration. It wasn't particularly difficult to do, but if you don't get the time or budget for upgrading tools approved, it's hard to make any changes.

• Old tech is proven tech. These new tools are untested. What's to say there won't be a major breaking bug that appears later? Do you really want to commit your team to an unproven technology? Again, the ease of changing tools mitigates much of this risk, but it's a risk nonetheless.

If you can get over those concerns, there are likely some newer tools that have come out in the last few years that might be worth a look. They were definitely worth it for us.

If you have any success stories related to upgrading tools in order to save time, feel free to share by reaching out to me on social media.