I think the problem is that we've let JS engines become absurdly complex so there's no way to avoid them having really gross bugs.

That said, I think that the V8 team has done a fantastic job of securing their engine. Their heap sandbox feature is really inspiring! It's really wild that (as far as I can understand this issue) someone is able to bypass it.

(Posted from a memory safe browser - WebKit MiniBrowser compiled with Fil-C. Pretty sure this is safer than even V8 and the heap sandbox.)

Running code by itself isn't that bad, it's the fact that browser developers have decided for some reason that this code needs to be as performant as possible, so, JIT.

I don't get it! The way JS is typically used, it doesn't even benefit from JIT all that much. Making ajax requests, doing stuff with strings, and moving DOM elements around doesn't need every CPU clock cycle to be used as optimally as possible. It's exceedingly rare for websites to actually be doing something that needs raw performance. And SPAs will be slow no matter what.

> decision we have made

This might oversell the agency that practicioners have.

Sandboxed zero-install delivery will outcompete anything with more frictionful installs.

It's probably not the right model for a pacemaker though.

Web/JS has been a double-edged sword for FOSS: sure, I can run a free OS, but if most of my "apps" happen to be JS that I can't practically control, then I have won a battle and lost a war.

I remember noticing this shift in nerd culture. In the early 2000s, it was common for people to say on places like Slashdot that they don't trust JavaScript and run their browser with it off. In the early 2010s, I noticed HN commenters thought this was insane, tinfoil hat type thinking.

In the future we can ask that your JaveScript and Wasm comes with a proof of being benign.

V8 as a runtime goes far deeper than just webpages.