So it sounds like it's not aligned-enough to take advantage of TS's expansive ecosystem? It's more just "a high-level language designed for WASM, with syntactic decisions familiar to people who know TS but which don't actually make it compatible". That's a much less compelling proposition
However, because it’s not actually compiling to JavaScript like typescript is normally, this means there must be quirks and differences that must be understood to solve harder problems. Depending on how friendly the compiler is, this can be very painful or intuitive.
I’m guessing it’s infeasible to compile TS to WASM since they’re targeting very different outputs - a ahead of time, dynamic weakly typed scripting language can’t possibly be compatible with an ahead of time, strongly typed, binary output.
And if someone tells you it is, I suspect they’re doing a lot of magic that’s hiding problems that only become obvious after writing nontrivial programs.
On Firefix and Safari we have the same missing optimizations. Basically wasm in all browsers reuse the same codegen from JS. But this will improved in the future.
Also, don't forget about SIMD, multi-threading with stared buffers and atomics and multi-values, a lot of special instructions like popcnt, ctz, clz, rotl/rotr and etc which not supported by JS and usually emulate not in the best way that complicates or make impossible to optimize this by the JS compiler.
In some points JS is really fast, so much that it is not inferior, for example, to the C language with the LLVM compiler without vectorization (-O2). Obviously WebAssembly can't outperform JS in such cases.
https://medium.com/@robaboukhalil/webassembly-and-simd-7a7da...