It'll be equally hard to write it from scratch in rust as it would be to add this to esbuild.

Maybe there are some considerations I don't know about but it does seem like hard forking esbuild would be much faster way to get there (hard fork so that they are not blocked or slowed down by whatever esbuild owner wants).

It really depends on who (which team) is doing it.

I would almost surely give up before understanding what esbuild does and how, and what needs to be modified. (Because Go basically gives me the creeps.) So someone with a lot of Rust experience probably simply opts for the rewrite.

That said, it seems folks on the Vite team decided to give this a try because of oxc_parser (a JS parser written in Rust), so probably it's not because of Rust-Go sentimentalism.

// Though ... there's also https://github.com/robertkrimen/otto (a JS parser in Go) ... so who knows! :))

Speaking of things “written in javascript” for the longest time all I kept hearing is how incredibly fast things written js are…

Is it fair to say that it was a bit of a sales pitch?

When key components of the ecosystem that were written in the language of the ecosystem itself are being rewritten in other languages - I think it’s hard to find a more compelling evidence that all is not as great as it was advertised.

> 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.