Just as the modern Javascript applications. What if - and hear me out on this one - Javascript just is a poor choice for huge complex codebases?

> […] it's instantaneous on my system […]

So? Are we all supposed to be using your machine? Performance can vary a lot depending on system, filesystem, and workflow. Something feeling “instantaneous” for you doesn’t mean it isn’t sluggish for others, especially when tasks like compiling TypeScript are done frequently, where even small delays add up over time.

I'm going to guess that you haven't played with any of these newer tools.

There’s growing consensus that with uv python tooling finally became good enough in terms of both speed and functionality, no need to choose one or the other (like, poetry had functionality but was extra slow).

I cannot understand the idea of using JavaScript that compiles into "native code".

At what point do JavaScript developers need to realise that this is all convoluted, and begin to use languages better suited for the job.

You want something that can compile into a binary with multiple architectures, multithreading, types, etc? Please use a different language that's built from the ground up to achieve that.

You want something that was designed to add some sugar onto a website? Then yes JavaScript is probably best there.

Not everything needs to be written in this one language that's not designed for it. Just because you can, doesn't mean you should.

Triggered mine too, especially “Modern JavaScript applications aren't just a few scripts anymore — they're sprawling codebases”

Especially because they mention unmaintained software (volta) in the same breadth as maintained software (fnm/mise)

I think it's mainly that JS has a terrible developer experience when it comes to parallelism and shared data, which these other languages don't need to worry about. Most build tools are pretty amenable to being parallelized but with JS you end up either being constrained to process-level parallelism (e.g split the filesystem into chunks and just run the program multiple times) or you have a bunch of inefficient message passing between processes. Even worker threads are unable to share memory except through the weird and awkward-to-use SharedArrayBuffer and Atomics APIs.

On top of this, a lot of JS tools have crazy plugin systems that let you hook into performance-sensitive places and run arbitrary code. This is slow and also makes parallelism tricky. For example, babel plugins can make arbitrary changes to the AST. Ordering them is already kinda tricky; many plugins just give up and run their entire logic as a callback against the root AST node. The fact that swc, esbuild, etc. come batteries-included with transforms for module syntax, Typescript, etc. actually helps with performance; you can leverage assumptions about these fixed sets of transforms to run them all at once and avoid multiple passes over the entire AST.

So rewriting in a language with better ergonomics and being able to ditch some excessive flexibility is what gets you the massive speedup, it's not just magical Rust dust

> What is the next bottleneck after speed?

Movable parts / dependencies

LLMs can get you just the functions you need in place of a whole package with 200 dependencies

> JS devs have tried to use JS for everything and found limits

Yeah, seems NodeJS kind of made some people into JS-zealots, while us web developers have thought of separation of concerns from the beginning, hence the holy trinity of HTML, JS and CSS. Glad others are catching up with web developers for once :)

Don't underestimate prototyping nature of js that allowed for exporing design space at higher speed throughout the years.

Reminds me when I was working on distributed filesystem at LiveDrive more than 10 years ago, wrote working prototype and few iterations in Ruby before rewriting it in C - somebody said "(you did it) because Ruby was slow/crap?", I said "no, because Ruby was essential (to do it quick)".

Also interop with those tools (though wasm) is relatively new.

Js/ts ecosystem is actually quite nice now with this option to use wasm for performance - while still keeping "works on the server and in the browser" intact.

Can you post links to where exactly one should provide feedback for each release?

We have several extremely heavy projects (mostly in the functional programming/effect space where you easily get union explosion) that make working even on an M3 max with 8gb per process limit impossible and we get OOM fast (besides compilation times).

Been using experimental tsgo in VSCode for several weeks and it's night and day, can't wait enough for TS7 to ship everywhere. Awesome job, guys!

We've been using tsgo for a few months in our team and it just works (10x faster). We bumped into some small differences in behavior with tsc but it was always because we were doing something weird in our code, and it was easy to fix.

Mad props to the team, it's an amazing achievement

We're using tsgo only on the command line btw, we're not using the vscode plugin yet

We're using it pretty extensively at my team in the huge front-end monorepo the company we work for has via the extension, just purely for better IDE perf. It's been excellent so far, though it does still choke on the sheer scale of said monorepo sometimes

“Native performance” in this context means compared to scripting languages, not low-level languages like C. Of course, Go offers native performance relative to JavaScript. Your comment seems to assume the author was comparing Go to more systems-level languages like Rust or C. In those cases, Go may lag behind, but it still qualifies as native performance.

A fair notice. In terms of performance, Go is similar to Java. Sth between scripting and native.

You can replace eslint and prettier with Biome or Oxlint + Oxfmt. Vite and Node.js are still the modern safe choices, though if you actually want to play with new things you can replace Node.js with bun.

Bun is great with Sveltekit

Vite is currently working on a rollup rewrite in Rust, called rolldown[1], that will provide dramatic speed improvements. It’s a drop-in replacement for the most part, and slashed our built times down to 12%.

[1] https://vite.dev/guide/rolldown

Or Rspack (https://rspack.rs/) which is intended to be a drop-in Webpack replacement