[yxre]

He has been saying this for a decade. I had to double check the dates to see if it was even relevant.

A problem is that the 3 problems that the articles highlights have been fixed with incremental fixes. Performance with V8. Object lifecycle management has had improvements from ES6 WeakMap and WeakRef although JS will never have RAII. ES6 also added more data structures.

No new alternative will be able to keep up with javascript's incrementalism

[paulgb]

> A problem is that the 3 problems that the articles highlights have been fixed with incremental fixes.

(author here) - I disagree. If V8 solved performance, we wouldn't see so much of the JS tooling stack being rewritten in Rust. Modern JS runtimes are fast because they are tuned for the types of workloads that are common on the web. This is great for the performance of a virtual DOM, but if you go off the beaten path of workloads that the browser is used to, you're still limited by the performance of the runtime.

JS has improved for sure but it’s always going to be slower than a language with a BDFL because it has so much legacy baggage and political consensus-building required. IMHO WebAssembly is the right approach: standardize a minimal bytecode and let languages compete on innovation.

[yxre]

Javascript is optimized for workloads to keep latency low and maximize concurrency while constraining itself for resources. This is pretty ideal for a GUI scripting language, and covers most use cases for the web.

It is hard to get performance perfect in all workloads. I have always been able to optimize my scripts to get the responsiveness that I need.

[paulgb]

> This is pretty ideal for a GUI scripting language, and covers most use cases for the web.

Yep, fully agreed. This is why I say in the article that JavaScript hasn’t been and won’t be replaced for those use cases.

> It is hard to get performance perfect in all workloads.

The way languages do this in practice is by giving developers the ability to drop down to lower levels of abstraction if they want to. With modern JavaScript you don’t have any levers to pull, you have to hope that a runtime optimized for the GUI use cases you mentioned happens to also take a happy-path for whatever non-GUI code you write.

For example, AFAIK the JS spec doesn’t provide runtime bounds. Array.shift() could be O(N) depending on the runtime. At my company we spend way more cycles than I’d like trying to figure out why some code happy-paths on Chrome but not Firefox or vice versa.

[svieira]

I'm not _entirely_ sure which RAII you mean, but if you mean something like C#'s `using` or Java's `try-with-resources` or Python's `with`, then https://github.com/tc39/proposal-explicit-resource-managemen... and https://github.com/tc39/proposal-async-explicit-resource-man... are in stage 3 (of 4 stages) in ECMAScript's language proposal lifecycle and will be coming to a JS engine near you behind a flag soon-ish.