No, because that would require exposing implementation details. e.g. the first API version of the bytecode would be the fixed API, and any future changes would require a translation layer for converting from one version of the bytecode to the other.
The bytecode is also an internal format so is consider trusted - once you expose it you have to worry about invalid bytecode.
And what about caching the bytecode so that it only happens once?
JSC already does that internally.
For webviews too?
Yes.
If you're going to precompile your JS, why would you want to emit this bytecode instead of just going to WASM?
Because wasm still doesn't support many features that JS does. For example accessing the DOM.
Re:A New Bytecode Format for JavaScriptCore
by firethief on Friday June 21, 2019 @06:58PM
(#20246944)
Bytecode is a broad category. The design of a bytecode suitable for interpreting JS has little in common with a bytecode for AOT compilation of static languages without tracing GC, other than that they're both made of bytes.
For example for hybrid desktop/mobile apps.