> for the longest time all I kept hearing is how incredibly fast things written js are…

I am sure no-one ever claimed that things (properly) written in JS are as fast as things (properly) written in C, Go, or Rust, and running in a native environment.

JS on the server may have been faster than php or python, due to the non-blocking nature of the event loop; but even that may not be the case anymore.

Generally, the pitch has been that js is "fast enough" for most tasks.

Everything is relative! Moreover, just because something is fast doesn’t mean it’s the fastest.

I don't know what OP is referring to here, but from discussions like this: https://stackoverflow.com/a/4417485 It seems like circa 2010 folks were referring to JavaScript as "fast" because it was more performant in some ways than other interpreted languages like Ruby and Python and those were the only major popular options at the time that people would consider for some use cases. The event loop model of JavaScript led to some creative use cases for having a single-threaded application handle many highly parallel requests that require very little CPU usage or computation but a large amount of blocking I/O, which I think was also pitched as "fast". But I think it's always been uncontroversial that interpreted languages like JS, Ruby, and Python are all "slow" compared to compiled ones for CPU heavy use cases.

Not just that, but Google pouring way more money and engineering effort into V8 than either the Ruby or Python teams could.

Things in JS (node.js) are fast when:

a) It's actually calling some native code internally (i.e. rust, c/c++ or V8 internals)

b) JIT'ed

Path "b" is very hard to achieve in CLI tool

> Path "b" is very hard to achieve in CLI tool

Why say that?

Yes, perhaps if the CLI tool is being invoked many many times in succession.

But otherwise JITing isn't an issue: either (a) your program runs quickly in which case the Ignition interpreter is used and the JIT is not used, or (b) your program runs slowly in which case JIT (Sparkplug/Maglev/Turbofan) has time to warm up.

> Yes, perhaps if the CLI tool is being invoked many many times in succession.

Each execution will be a fresh VM though. A CLI tool isn't a long-running daemon. There is also the whole lack of parallelism without forking in this ecosystem.

Node/JS (really any scripting language) is fast enough in scenarios where the productivity gains are worth the performance trade off (example: many web backends). Tooling is not one of those use cases.

Golang has the same or better productivity than JS and is objectively running faster. So JS/Node don't have any real edge here.

Productivity gains of using Node.js are a myth. You will be better served by C# + ASP.NET Core with massive performance gains while writing about the same amount of code. Or sometimes a little more but cutting down 10 times on ensuring it works correctly.

JS IS fast compared to many languages. In general use, it’s about as fast as Haskell.

Yeah. It’s in the order of 4x slower than Java for most things, but it’s also like 100x faster than Python.

It’s all a matter of perspective, but in general, JS is probably about the slowest language I’d be inclined to reach for for long term solutions.

I find VSCode is fast enough for me. I work on a project with ~800k files. VSCode launches fast, finds files fast, greps fast enough, etc... So to me, JS is working as advertised. Choose the right solutions and algorithms and it works fast.

I get that VSCode might not be performant for others. I'm on a M1 Mac with 32gig of ram. I never notice any slowdown compared to any other editor I've used. I'm not saying other editors aren't measurably faster. I'm saying I don't notice any issues personally.