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