now we need to rewrite tsc/babel/npm/eslint/etc... in a language that compile down to native binary that is also cross platform (like go or rust),
to gain the same performance improvements across the entire JS tool-chain.
* based on the benchmark on their landing page.
I’m sure it would make sense to rewrite certain things in Rust or Go (then possibly pull them into Node as native modules) but they’re not magic. Good engineering will win out no matter what.
The problem with any interpreted language is that to run the tool you need all the source and all the dependencies plus the interpreter in something like their intended versions to be present in the right locations on disk. This is a huge PITA, and if you're say writing JavaScript targeting ES5 but your tools are targeting ES2020 or vice versa, there can be painful yak shaving sessions getting everything on the same page.
Essentially all developer tools should be static binaries.
1) Modern JITed JS is fast. It's closer to Java than it is to what we typically think of as "interpreted languages".
2) "something like their intended versions to be present in the right locations on disk"; Node packages really just depend on the user having a new-enough install of Node and NPM, somewhere in the path. Any dependencies that live on npm will install to the local directory to ensure against conflicts or permissions issues. The only exception I can think of is that occasionally (looking at you, node-sass) npm dependencies will have to do a native build of something and require a local C/++ compiler somewhere in the path. This is pretty rare in my experience, and isn't a super brittle dependency anyway.
3) "if you're say writing JavaScript targeting ES5 but your tools are targeting ES2020 or vice versa, there can be painful yak shaving sessions getting everything on the same page"; this really doesn't happen in any distributed NPM dependencies I've worked with. The great majority are written for the least-common-denominator of environments; if they use ES2020 internally, they'll do their own transpilation step to make sure you can use them in older environments. Also, "or vice versa" really doesn't apply because all ES versions are 100% backwards-compatible. You just need a Node version new enough to cover the newest features that any of your code or dependencies is using. Dependencies will be as compatible as they can be; your own code is under your control. Virtually never an issue.
2. Node is much better than Python because the correct location on disk is pretty much project/node_modules. However, it is still that case that e.g. Babel was broken by Node 12.17.0 [1] last year, which necessitates something like NVM. I don't want to deal with that for my build tools. I just want a binary that is known to work to continue to work until it is replaced.
3. Yes, conventionally everything in Nodeland was written out to dist as ES5. This also sucks ass because now you end up shipping a bunch of ES5 crap to your end users even though you aren't targeting ES5. It is very hard to build an actual ES2020 module unless you're willing to not use external dependencies at all. Snowpack et al are shifting this slowly, but it has barely even begun as a trend.
[0] https://nodejs.org/en/blog/release/v12.17.0/ https://www.google.com/search?q=babel+compat+data+corejs3+sh...
The caveat here is that it's not nearly as fast for code that isn't properly warmed up, even in the face of herculean efforts to make it so.
Now, you could argue that JS encourages complex, inefficient abstractions and over engineering and Go encourages the opposite. That, I’d believe.