So hopefully https://blog.cloudflare.com/binary-ast/ will become a standard.
Already part of Firefox Nightly! about:config, unrestricted BinaryAST
It's important to realize: binary-ast is no more readily executable than plain JS, it is no more trustable than plain JS, and even if they were parsing is not been a significant part of ttfe in JSC in a long time. It's the interpreter codgen that eats up time, and the execution speed difference between AST (which JSC used for a looonng time, and the final builds beat the contemporary bytecode interpreters of other engines when it was replaced). The performance of an AST is so much slower than bytecode interpreter that you require a tiny amount of JS before the cost of codegen+execution beats just execution using the AST.
Because then any changes require duplicating the byte code parsers, and adding translation logic to manage those changes.
You must understand: any change would be an API break, and API cannot change. Deprecating an API takes years. You also can't change/add API in security updates, which means if a security fix required changing some aspect of the bytecode that change couldn't be made.
Lets say you change numbering of registers? Thats an API change.
Lets say you change number of opcodes? API change.
Any new API in macOS and iOS requires weeks of review cycle to ensure:
* It solves a problem in a generic manner: e.g. it doesn't solve a very specific version of a general issue
* It can be kept stable: e.g. it doesn't expose implementation details that may change
* It is ABI stable: direct memory access APIs cannot expose layout that can vary based on any internal details.
Shipping API is incredibly difficult if you care about ABI stability for software.