5 ms·
This assumes WebAssembly will have virtually no performance overhead when compared to C/C++, and still doesn't address the fact that JavaScript "binaries" will
by megaman821 11y ago
This assumes WebAssembly will have virtually no performance overhead when compared to C/C++, and still doesn't address the fact that JavaScript "binaries" will be much larger than today's scripts that rely on a JavaScript interpreter being present inside the browser.
- JoshTriplett 11y ago> This assumes WebAssembly will have virtually no performance overhead when compared to C/C++, It won't have zero performance overhead, since unfortunately it will still require translation to native code. But it'll be far higher-performance than asm.js, and precompiling JavaScript to WebAssembly could produce higher performance than a JavaScript JIT. > and still doesn't address the fact that JavaScript "binaries" will be much larger than today's scripts that rely on a JavaScript interpreter being present inside the browser. You don't need to do the compilation in the browser; do the compilation ahead of time and ship wasm bytecode. The DOM and all other web APIs will still be provided by the browser, so I don't see any obvious reason why wasm needs to have substantial size overhead compared to JavaScript.
- leoc 11y agoThe Web has enough commercial heft that maybe we could see things like ARM's Jazelle https://en.wikipedia.org/wiki/Jazelle https://en.wikipedia.org/wiki/Jazelle DBX Java support.
- pcwalton 11y agoJazelle died for good reason. More interesting would be something like Transmeta/Project Denver, where the JIT is deeply integrated with the CPU.