SSA is probably the best idea- I wouldn't put too much effort into making the bytecode nice for interpreters, since that's not a very common way of running JS.

SSA is probably the best idea- I wouldn't put too much effort into making the bytecode nice for interpreters, since that's not a very common way of running JS. With a simpler type system (i.e. not dynamically typed), there would be even less reason to interpret or even partially JIT- may as well just design it to be pre-optimized and fast to just AOT the whole thing. The Mill CPU is interesting here, in that it's a belt machine, so SSA is very close to what its native machine/assembly looks like. It basically takes what is currently register renaming and drops the layer of ISA registers, and just refers to the results of previous instructions relative to the current one. That sort of architecture would be almost trivial to JIT SSA for- you wouldn't even need register allocation, just instruction scheduling. Another consideration to go along with decompiling hints, debug symbols, etc. is that web pages are very transparent and manipulable with the browser's inspector and JS console. Any new bytecode would ideally keep the ability to poke around the app's data and interface- it's a very nice REPL-type tool.