The Performance Revolution in JavaScript Tooling (blog.appsignal.com)

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.

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.

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 was expecting to read about Bun and Zed...

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.

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.

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 :)

[dead]

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.

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

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

I'm not sure Go can offer native performance.

OT doesn't this really feel AI authored?

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'm still waiting for JavaScript tooling revolution where node_modules dependencies become smaller or disappear at all.

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.

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