Right now we have a dozen languages that transpile to JS. What WASM proposes is that we replace that with WASM. Then we will have several dozen languages with JS in first place that have critical bits compiled to WASM. We still have frameworks and other fragmentation but It promises performance.
What you say may happen but what the primary purpose of WASM is to replace JS as the target of compilation as it is now. They want a more robust and lower level language which can give higher performance as the base kinda like LLVM except for browsers. So languages like Typescript, Dart, Elm don't have to transpile to JS but to WASM which is less work and more performance.
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.
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).
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.
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.
> transpile to JS but to WASM which is less work and more performance.
Citation needed. :)
It is not at all clear that WASM is an easier compilation target for a high level language like TypeScript, Dart, or Elm. You may be able to get better performance, but in return you have to implement and ship an entire runtime, GC, string representation, etc. Also, interaction with the DOM (the thing you need to actually get pixels on screen) is much harder.
Nobody will write directly in WASM just like nobody writes Assembly directly for complex stuff. Also the entire thing is officially supported now in Firefox and Chrome with Edge and safari soon to support. (P.S I am not a web developer and most of my info is from other people so I maybe wrong. If I am do tell me)
GC has been a future goal since mid-2015 [1]. At some point in the future when (if?) that's supported then WASM may become a better target for compilers than JS is today. Until then, I don't see WASM as super compelling.
Think of it like this: WASM is effectively a subset of JS. If you're compiling to run in a browser, by targeting that subset, you don't get to use any of the features outside of that subset that browsers already have high performance, battle-tested implementations of. Worse, you then have to reimplement those features yourself and ship them down with the application.
> Right now we have a dozen languages that transpile to JS
Not used in any meaningful amount, we don't. And in any case, a library transpiled from Elm to JS is usable by some other code that was transpiled from Typescript to JS. Will that be the same with WASM? Will I be able to make easily reusable WASM libraries? Will they all use the same mechanism to do so? All I've seen discussed is entire apps being converted.
By itself that’s the equivalent of dynamic linking; I don’t know if anyone’s written a static linker yet, but it’s an obvious next step.
However, just like with native code, there will be problems with different languages having different representations of strings, arrays, etc., and C and its sparse type system being the least common denominator.
> I don’t know if anyone’s written a static linker yet, but it’s an obvious next step.
Essentially just wasm-merge [0].
> However, just like with native code, there will be problems with different languages having different representations of strings, arrays, etc.,
This is the biggest hurtle. Someone needs to provide a WASM interface for backends to implement and frontends to target that provides a minimal stdlib. Until then, it's libc and posix by way of emscripten.
> And in any case, a library transpiled from Elm to JS is usable by some other code that was transpiled from Typescript to JS. Will that be the same with WASM? Will I be able to make easily reusable WASM libraries?
In short: No
With the current transpile-to-JS mechanisms all those languages use the same object model (from Javascript), the same string types, the same garbage collector, etc.
Once you compile-to-WASM, you reduce the common API surface to the WASM primitives, which are reading and writing numeric values from locations in byte arrays. To get some interoperability one would need to create a Javascript wrapper for all those WASM modules. Or in the future there might be a shared garbage collector in WASM, but even when that's the case one would require a standardized object model between all languages that compile-to-WASM and would like to interoperate.
So essentially the only hope for interop is for some language to gain enough traction early on that other languages implementers all want to be compatible with it so that it becomes the de-facto cross language interface like C did on most native platforms.
What you say may happen but what the primary purpose of WASM is to replace JS as the target of compilation as it is now. They want a more robust and lower level language which can give higher performance as the base kinda like LLVM except for browsers. So languages like Typescript, Dart, Elm don't have to transpile to JS but to WASM which is less work and more performance.