Sorry, not even remotely close. I want to see some serious evidence.
JS id as unoptimizable as can be, thanks to its hyper dynamic nature. And js developers without any clue about memory will happily allocate hundreds of thousands of unnecessary objects to save a line of code. Completely unknowingly of course.
Funny that you say "not even remotely close" while providing zero evidence yourself, but then ask other people to present their evidence.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
There you go. There's the evidence. No goalpost-moving, please.
For evidence that Javascript can be used to build large, production-quality applications, see coldtea's comment: https://news.ycombinator.com/item?id=37568707
Sorry, about benchmarks I just quote myself: > I take these performance benchmarks with a rock of salt. They are mostly hyper-optimzied generics which are as far away from actual production code as it can be. They are written in a way to allocate as little memory as possible and is done by people who know exactly what they are doing.
Do you think we should only compare JavaScript written by newbies?
And yet it has been optimized.
> Sorry, not even remotely close. I want to see some serious evidence.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
JS is ~30% slower than Java or Go.
Go is a lot closer to JS perf than to C++ perf.
---
For real-world applications....compare IntelliJ, Eclipse, Visual Studio, or Sublime against VSCode.
Especially the garbage collection strategies of Java are second to none (sorry, don't want to be a shill).
> For real-world applications....compare IntelliJ, Eclipse, Visual Studio, or Sublime against VSCode. My experience is that VSCode has horrible input latency and Intellij is blazingly fast once indexing is done.
There was this blog post of a company trying improve their clients' webpage performance by incrementally migrating them from JS to WASM/Rust: https://zaplib.com/docs/blog_post_mortem.html
In short, their idea failed. Those rewrites did not yield the "orders of magnitude" perf improvements that they were hoping for. A quote from the article:
> Rust is faster than JS in some cases, but those cases are rarer than we expected, and the performance gain is on the order of 2x some of the time, not 10x most of the time.
Having had a good deal of experience programming in JS, this doesn't surprise me. JS engines are extremely good at JIT optimizing, especially if you know what you're doing and give them code that's suitable for optimization (e.g. using mostly primitives and arrays, simple loops, avoid creating tons of intermediate data structures, etc).
IDK if any of this counts as "serious evidence". It's purely anecdotal really. But it's on par with the "evidence" presented as a counter to this.
Claiming JS has the same performance as Java or Go is not.
JS also has had decades of optimizations. So if WASM with essentially no optimization is just as fast as JS, that's a huge interoperability win.
> Claiming JS has the same performance as …
"in some cases"
Yes, it's a 30 year old game but the typical CRUD web app doesn't have close to the complexity of quake. Good C++ code is significantly faster than JS, that's true, but JS is also much, much faster than you'd think.
Here's the Unreal engine demo from 10 years ago: https://www.youtube.com/watch?v=XsyogXtyU9o
I have an app that has one pretty frequent cpu intensive call (it computes the lcs for diffing). I decided to benchmark a rust wasm bindgen implementation against the js one I was using and found that ironically enough, node did perform better than rust. To be fair to the rust version, I think the JS implementation was slightly better optimized. I then looked into parallelizing LCS, (which is possible) but bindgen and almost all node:rust ports don’t support multithreaded calls, I can think of a myriad of ways to overcome this but not in a browser context. At that point I gave up on worrying about porting to lower level languages for cpu intensive work because if you’re forced into a single threaded context the gains of a memory managed language are going to be trivial at best and add ipc overhead at worse.
The main culprit of poor JS performance in native contexts is almost always bridges and the serialization/deserialization that comes with them. Electron apps don’t really suffer from the bridge problem. While, I’d never claim that JS is as fast as GO or Java (objectively it isn’t), it’s seems equally naive to suggest that using memory managed languages without exploiting multicore is going to lead to significant performance gains in a native app or web app.
I think the real power of wasm is the power of virtualization, it won’t be performance unless web APIs decide to break the single thread paradigm.
citation:
https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers...
“Data is sent between workers and the main thread via a system of messages — both sides send their messages using the postMessage() method, and respond to messages via the onmessage event handler (the message is contained within the message event's data attribute). The data is copied rather than shared.”
https://developer.chrome.com/blog/transferable-objects-light...
Also, why do you compare JS written by amateurs with Go/Java experts? There are JS experts too.