Skeptical of rewriting JavaScript tools in "faster" languages

> Whereas if it’s written in a native language, I’d need to check out the source code and compile it myself – a big barrier to entry.

Is it though? Rust/Zig/Go programs are pretty much all incredibly easy to checkout and compile, it's one of the big selling points of those languages. And at the end of the day how often are javascript developers fixing the tooling they use even when it's written in javascript?

I've always felt learning new languages give me not only new tools to use but shapes the way I think about solving problems.

I wonder if author is aware that Node.js is not written in JavaScript.

I agree with you on the easy part, but it’s definitely not as fast. In JS you get instant hot code reload and even without that the interpreter starts up pretty fast. In comparison Rust takes a while to recompile even with simple changes, and if you have more changes in many files (eg. switching between branches) then it’s really slow.

It's definitely more of a pain to figure out rustup than to use the Node.js environment that's already installed. As noted in the article, you can quite literally go edit the source of your NPM packages without downloading or compiling a single thing.

Minor speedbumps like installing Rust don't stop me now, and probably don't stop you either, but they might have at the start of my career. You have to think about the marginal developers here: how many people are able to debug the simple thing who would be unable or unwilling to do it for the complicated thing? As you note, it's already quite rare to fix up one's tooling, so we can't afford to lose too many potential contributors.

I like learning new languages too, but not to the extent that I'd choose to debug my toolchain in Zig while under time pressure. This is something I've actually done before, most notably for FontCustom, which was a lovably janky Ruby tool for generating font icons popular about a decade ago.

That’s not objectively true at all. I learned to use Rust long before I ever touched a Node setup, and the first time I wanted to run a JS app it took me a lot longer to figure out how to do it than it did to type `cargo run foo`.

Neither is easier than the other. Whichever one you already know will be easier for you, and that’s it.

Sorry, I think we might be talking across each other. I am saying from the perspective of someone who is already using a full Node.js environment, adding Rust must necessarily increase complexity. I am taking this perspective because in the article we're talking about, the examples are exclusively JavaScript tooling like Rollup, Prettier, and ESLint, where the only people using those tools are JavaScript developers who are already running node.

I have absolutely no interest in getting into a pissing match about whose language and ecosystem is better, and I in fact agree that the Rust tooling is less complicated than JS to start with. Nevertheless, the article is not about choosing either JS or Rust, it's about rewriting tools for working with JS in Rust, which necessarily makes you learn Rust on top of JS if you want to modify them.

Probably: he is a contributor to Servo

This matters, a lot, for contributing to the tool authored in Rust. But for merely installing and benefiting from it, compile-time is largely a one-time cost that pays returns quite soon.

I didn't say compiling was fast, though compiling go is pretty fast. I also don't think anyone is arguing that tools need to be written in AoT languages, if you or anyone want to use js and js tools go for it.

I think having more choices is a good thing, and sometimes rewriting something from scratch will result in a cleaner/better version. The community at large is going to decide which tooling becomes the standard way to do it, so the author should make an argument on why the js tooling is better instead of weak statements like the one I quoted.

It depends. A lot of it absolutely is, I've been through a ton of that source.

Low level stuff is mostly c++ to talk to v8 or do system calls, talk to libuv, etc... but even that stuff has a bunch of js to wrap and abstract and provide a clean DX.

That's true of any tools, and most tools that a developer uses (e.g. `grep`) are written in C, C++, or more recently Rust. Or if they want to understand the details of how some part of JS actually works, they'll need to delve into C++. So that requirement already exists.

In theory, yes; in practice, the native libraries and tools that most JS developers used to use were stable, widely used, and well tested. Think pg, hash functions, POSIX basics like cp if they didn't need to build on windows, V8 and node, or the OS itself. Practically speaking, the native libpq is less likely to break than its wrapper, which is in turn less likely to break than a newfangled npm package with relatively few users and low test coverage.

I've dipped into V8 to understand a bug...exactly once. Even then, I didn't have to build it, which is good because building node and V8 from source used to take hours and probably still does. It's just a more stable piece of software, because Google has a very strong incentive to keep it that way.

The thing is, there is no requirement to ever touch lower level languages in order to work as a JS developer. I would hazard a guess that most JavaScript developers don't. If you need to touch C++ in order to do certain things, then most JS developers will choose not to do them. Expanding the number of tools that can't be fixed by most of their own users has downsides.