3 ms·
What if you just add a generalized JS-to-WASM step then? That way all languages that currently transpile to JS could use that same final step.
by sbarre 9y ago
What if you just add a generalized JS-to-WASM step then? That way all languages that currently transpile to JS could use that same final step.
- rf15 9y agoyou could do something like V8 in wasm, sure, but.....think about this for a bit: in chrome, you already have V8 as a native implementation, without the overhead of wasm -> cpu instructions. nothing would be gained. You would need to do memory/etc. management on a level that is either more in line and more optimizable with your language design, or just stick to things as they are.
- Matthias247 9y agoCompiling JS to WASM has the same problems as just compiling JS to normal assembly ahead of time: It's just too dynamic. The thing which you can compile ahead of time is an interpreter, which then checks during runtime what the actual types are and what needs to be done. You can run such an interpreter in WASM, but that will be a lot slower than what the current JS engines are able to do with Just In Time compilation. I don't know whether it's possible to implement a JIT compiler in WASM (and thereby dynamically output and execute WASM), but running a JIT-in-WASM on top of a native-JIT (the JS engine) sounds not really desirable.
- sbarre 9y agoThank you for explaining!