Presumably because, apart from Python (see Ruff, uv, etc) most languages aren’t running into such major issues with their own “self hosted” tooling that it’s worthwhile to rewrite several of them in a completely different language.

Yes I agree! And JavaScript also isn't really at that point yet. Python is really in a class of its own here... sadly enough.

Though I don't see an issue with tools for JS built without JS. It's just that I don't think that it's a bad thing for a JavaScript dev to want the ecosystem around JavaScript to be written in JS. JS is orders of magnitudes faster than python in any case.

God what I’d do if someone wrote build system in Rust for JVM and freed us from Maven and Gradle.

> It's usually the opposite. And the post is specifically about making JavaScript tools, why would you not expect them to be written in JS?

Take a look at rollup, vite, etc. These tools are essentially replacing webpack, which is written in JS. Modern Rollup (^4) uses SWC (Rust-based bundler), and vite is currently using a mix of esbuild (Go) and Rollup. I think they're switching to SWC in v6 though.

The point here is that for certain operations JS is not nearly as fast as lower-level languages like the aforementioned. Bundling is one of those performance-critical areas where every second counts.

That said, as a TypeScript developer I agree with the sentiment that JS tools should be written in JS, but this isn't a hard and fast rule. Sometimes performance matters more. I think the reasonable approach is to prefer JS – or TS, same difference – for writing JS tools. If that doesn't work, reach for something with more performance like Rust, Go, or C++. So far I've only had to do the latter for 2 use cases, one of which is hardware profiling.

It's funny you mention C# since VS Code is a perfect example of JS devs rewriting existing tools in JS.