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>
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 bytecodespidermonkey
meaning Firefox and SpiderMonkey based browsers with the ability to digest their own bytecodejsc
meaning Safari and WebKit based browsers with the ability to digest their own bytecodewasm
meaning any browser capable to digestwasm
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" ...>
.
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>
- 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).