I assume he means something like turning off the JS JIT, not turning off JS completely. IIRC iOS turns off Safari's JIT when in lockdown mode. Ladybird browser also abandoned its JIT apparently due to security concerns. JS JIT is one important example but also in general if you write your code to only focus on correctness and not performance then you will get safer code (all else being equal).
Haha, well that’s what I use now. I think it is the opposite though. I’d like a JavaScript implementation that doesn’t break any sites, but which makes absolutely no security compromises, even if that means they have to give up a lot of performance.
Sometimes, I just have to load a site that has JavaScript running. Or is unfortunate, but some work sites don’t work without it, etc. I’m fine with those sites being slow (I’ll minimize my use of them naturally), but totally blocking them is slightly inconvenient.
Disabling (all of) the JITs is a decent approximation of this. It's very site-dependent as to how much of a performance impact it makes, but for many sites it'll be fine.
Obviously this isn't the same as making "absolutely no security compromises", but in practice most JS-related security exploits go through the JIT iiuc. Your JS will be executed with a safe interpreter, where by "safe" I mean the dispatching and basic value manipulation are going to be simple enough to be bulletproof, and also slow enough to prevent most timing attacks. The underlying implementation of all of the built-in methods is still going to be more vulnerable, but those tend to be relatively safe as compared to JIT-optimized versions of them. They also don't change much, so have been tested for much longer as compared to the JITs that tend to get refactored and rewritten relatively frequently.
Isn't this just the noscript, which breaks most sites to a degree where they're impossible to use or load?