3 ms·

I don't think it is that easy. These languages rely a lot on the underlying Javascript features and how they work, like objects, strings, etc. - browsers had a

by rf15 9y ago

I don't think it is that easy. These languages rely a lot on the underlying Javascript features and how they work, like objects, strings, etc. - browsers had a long time to optimise JS interpretation on the level beyond primitive values: OO-features in general, reusing classes/objects efficiently, good string concatenation/handling, things like that. And suddenly, Typescript et al should take care of those features as well? Sounds like an explosion of low-level feature requirements if you cut out the JS middleman.

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 ago
  you 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 ago
  Compiling 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 ago
    Thank you for explaining!
kronos29296 9y ago
JS is not being completely replaced if i understand correctly but the performance critical parts can be sped up. (Kinda like Cython and C extensions in Python).

by rf15 9y ago

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 ago
you 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 ago
Compiling 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 ago
  Thank you for explaining!

kronos29296 9y ago

JS is not being completely replaced if i understand correctly but the performance critical parts can be sped up. (Kinda like Cython and C extensions in Python).