bytecode.md

Bytecode And Web

Coming from this tweet: https://twitter.com/mathias/status/1115525813670227968

Similar way scripts with type module has been introduced, script with type bytecode and a specific engine target, including wasm, could make it too, so that engines able to digest pre-optimized code can benefit from this.

<script type="bytecode" engine="v8" src="v8.bc"></script>
<script type="bytecode" engine="spidermonkey" src="sm.bc"></script>
<script type="bytecode" engine="jsc" src="jsc.bc"></script>
<script nobytecode type="module" src="esm.js"></script>
<script nobytecode nomodule src="es5.js"></script>

The engine attribute

As new proposal, and to avoid confusion, keeping the semantic spirit of the Web, the engine attribute could be used to target:

• v8 meaning Chromium and v8 based browsers with the ability to digest their own bytecode
• spidermonkey meaning Firefox and SpiderMonkey based browsers with the ability to digest their own bytecode
• jsc meaning Safari and WebKit based browsers with the ability to digest their own bytecode
• wasm meaning any browser capable to digest wasm

If other engines can digest their own bytecode, this list can grow.

If one specific bytecode is shared between more engines, the engine attribute can have multiple targets: <script engine="v8 jsc" ...>.

The nobytecode exclusion

As it is for the nomodule directive, and without being mutually exclusive, the nobytecode one would communicate to any browser capable of understanding type=bytecode that the source should not be downloaded, parsed, or executed.

If the engine parsing the page didn't encounter its bytecode related script, it must ignore the nobytecode directive.

<script type="bytecode" engine="v8" src="v8.bc"></script>
<!-- only v8 won't parse the next script, Firefox and Safari would -->
<script nobytecode type="module" src="esm.js"></script>
<!-- old browsers will simply run this -->
<script nobytecode nomodule src="es5.js"></script>

But ... why

• 100% backward compatible
• browsers ble to digest their own optimized version of JS can benefit right away from pre-optimized code

Last point means: if v8 can bootstrap bytecode faster than JS, there's no reason, in a world of bundlers, to not bring this possibility to the Web, unless the optimized code won't be too heavy, in its compressed file size, compared to its JS compressed and minified counter-part (otherwie the whole idea becomes kinda useless).