The Performance Revolution in JavaScript Tooling

I guess since this at the top of HN, I'll just plug that we (the TypeScript team) are looking for broader feedback of the native previews before our stable release, whether that's:

- through builds (https://www.npmjs.com/package/@typescript/native-preview), or

- through the editor extension (https://marketplace.visualstudio.com/items?itemName=TypeScri...)

Yes performance is a big issue, and so is security (or the lack of it). I'm attacking this from another angle: https://github.com/tsoniclang/tsonic

Write TypeScript, compile to native code via CLR's NativeAOT. We're almost there, you can see some examples here: https://github.com/tsoniclang/proof-is-in-the-pudding

You get everything; real multithreading, stack allocated types, single binary output (x64, ARM64 for Linux/MacOS) etc.

Some nitpicking.

> Modern JavaScript applications aren't just a few scripts anymore — they're sprawling codebases with thousands of dependencies, complex module graphs, and extensive build pipelines.

This has been true for at least a decade.

The very next paragraph:

> JavaScript-based tools that were once "good enough" now struggle to keep up, leading to sluggish build times, laggy editor experiences, and frustratingly slow feedback loops.

The tools really weren't "good enough", even back then, by these metrics. JavaScript tooling has been slow and bloated on large codebases for just as long.

On a related note (but with Python), I recently tried uv instead of pip and was impressed by both its speed and dependency resolution. I was attempting to upgrade an internal project from Python 3.9, and pip was frustratingly slow, sometimes it would just get stuck with no output and no errors...

I have a "forever project" written in TS and Svelte that uses vite, eslint, prettier, and Node.js. I love playing with new things.

What would be the fastest new combo? TS+Svelte+deno? Is there something that replaces vite?

I have noticed a trend with newer JS tooling beyond performance. Indeed, builds are quicker. The cold starts decrease. That’s great. ~

However, the feedback duration is the actual behavior modifier.

My perception map.

Speed test, compilation time benchmarks.

Loop tightness refers to how fast you notice a mistake.

Cognitive load refers to the amount of context you maintain in memory while waiting.

Most developers don't make use of max throughput. They strive to avoid distractions. Tools that are written in faster languages matter mainly because they shrink the gap between action and signal.

Some "quick" weapons stick, that is why. Problems of today often relate to mystery, not slowness.

The rule I abide by now is that if a tool feels calming while debugging, it wins.

Inquisitive.

What tools have made an impact on your daily workflow?

When has hype about performance not translated into adoption?

What is the next bottleneck after speed?

I consider JavaScript in this regard extremely similar to Python.

Python is a beautiful beast and its main language is C if you want.

JavaScript has a coming of age. It is not a language anymore but a universal tool to build mainly web apps.

I rarely see any JavaScript die hard fans anymore, we are talking about JAVA like variations like the predominant TypeScript.

And production critical apps need professional treatment and so it goes.

Mentioning SWC and ESBuild but missing Rolldown (https://rolldown.rs/) here seems like a miss.

The upside is huge. The only downside that I can see is that the tools become less hackable. You cannot simply patch ts or eslint via pnpm if you want to. Now you need to build your own version.

So yah, no free lunch.

I was wondering why stuff was written in JS in the past - it seems obvious to use a faster language for these tools, but I then realised that these massive sprawling Typescript codebases are a modern phenomena. I sort of wonder if the tooling is just step one, and step two is not just the tooling but the other codebases going from TS to a faster lang (like Go).

Speaking of Go, Esbuild is amazing. You can write entire dev servers and build pipelines in a couple hundred lines of Go, with hot reloading etc. Full control over your build process, plugins are compiled with the builder so you don't pay the JS -> Go cost, it's really great stuff. I love Esbuild, thank you Evan :)

I'm still waiting for JavaScript tooling revolution where node_modules dependencies become smaller or disappear at all.

Reality bites. JS devs have tried to use JS for everything and found limits. It isn't a one language to rule the all. Welcome back to the world of needing the right tools for the job.

Is it just me or this article has been written or at least heavily processed with LLM? My AI slop radar triggered immediately (overly verbose, fluff, bland). Don’t get me wrong, it has valuable information but that style smells LLM from a distance.

OT doesn't this really feel AI authored?

I was expecting to read about Bun and Zed...

>>That's where languages like Rust and Go come in. They offer native performance,

I'm not sure Go can offer native performance.

For tools devs use, performance is important, so we will do anything and everything we can to squeeze out those few extra seconds of delay, they all add up.

For tools users use, developer experience is important, so they get whatever React and Electron slop we hurl over the fence.

Tale as old as the web.

NVM sluggish ?

WTF! it's instantaneous on my system. I think that could be called "slow" if you are continuously installing different versions of node.