> JavaScript isn't as fast as C++ or Rust, but it's pretty fast. Around the speed of Java and Go in some cases, which are compiled.
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.
Speed is achieved via optimization, which is achieved via constraints. Javascript is being known for its inefficiency.
Saying JS is just as fast is a hot take and whoever claims that has the burden to proof otherwise.
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.
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.
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.
This is classic goal-post moving - you started out by saying that Intellij was faster than VSCode, then after a commentator said that their experience was the opposite, you moved the goal-post to "well it doesn't matter". You should be willing to admit when you're wrong.
> Sorry, not even remotely close. I want to see some serious evidence.
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.
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.
I did a double take when I read this too. However, I’d wager that in 99% of cases the bottleneck isn’t at the language level for most desktop apps or GUI apps in general.
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.
Well then you’re back to the bridge problem. postMessage is crazy slow. There are some problems where parallelization will outperform the ipc cost with postMessage but those problems are few and far between. I haven’t dove into the new web GPU api but it does look kinda promising (shared memory is hard, so I’m apprehensive). I’m sure some of these things will get solved in the long run but for the time being, the bottleneck to browser performance is not necessarily JavaScript itself but the webapis that are crafted around a single threaded model. This is really my only point. Aside from providing systems engineers familiarity with syntax/devex and possibly some portability with some llvm/wasm compatible libs, there is little point in wasm runtimes at this current time imo.
“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.”
The key words here are: "around", which is to say same order of magnitude for performance, and "in some cases" which is to say for certain applications. I've already posted evidence for this claim specifically in sibling posts.
Also, why do you compare JS written by amateurs with Go/Java experts? There are JS experts too.
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.