The most recent open issue is from 6 months ago and posits whether the project is still active. It definitely feels "experimental", but a bit outdated already.
The question is if WASM is really meant to be a compile target for anything resembling Javascript, or indeed of any language implementing garbage collection. And yeah, I know that there are proposals to include GC in WASM. And yeah, I know that a lot of people would love to program at the high abstraction level of JavaScript, only faster. Thing is, Javascript runtimes are already highly optimized at running Javascript type code. I think to really get faster, we'd have to face the tradeoffs.
The main tradeoff, IMHO, is memory management. If you go full OO with a lot of object allocations, and with a garbage collector picking up the litter in the background, then you will be freed to focus upon business logic and your development will move faster. If you manage memory yourself, C style, then you are in for a world of pitfalls and potential pain, but you can make your algorithms tighter and faster. What to pick depends upon your priorites. Postgres is written in C, for speed. A lot of modern web apps are written in full stack Javascript, for agility.
I envision the future of web assembly not as a compile target for your entire codebase, but as a way to optimize the tight loops and algorithms that do the heavy lifting, but leave the rest of the web application as Javascript. Also I think that once you go down that road, you have deliberately picked speed over convenience with respect to the methods in question.
The way that it's going to work, I think, is not by having a Javascript-type language compile into WASM, but by having a more low level language which easily compiles to WASM, but which also compiles to (slower) Javascript to support older browsers.
But what do I know ..
Nice, but I'd rather see existing languages compiled to WASM. Such as C++, OCaml, Haskell, CPython, Rust, ...
Half of the c output seems to be unicode boilerplate. Should there have been unicode to begin with? I guess they are going the way of go, but wonder whether they would take other useful "high level" features like concurrency handling and gc, if they started looking that way.
I'm partially worried about WebAssembly. On one hand it opens up new possibilities... on the other hand, due to backwards compatibility I think that the future will look like this:
- 1 browser tab: Java runtime environment compiled to WebAssembly, loaded by some sort of enterprise app I'll have to use at work
- another browser tab: .NET BCL compiled to WebAssembly, loaded by another sort of enterprise app I'll have to use at work
- yet another browser tab: some sort of other C/C++ runtime compiled to WebAssembly, loaded by fancy site, let's call it XMail
- and yet another browser tab: another C/C++ runtime loaded by another fancy site, let's call it Ywitch
- a million other tabs with Javascript frameworks
From a certain point of view diversity is good, on the other hand there's so much fragmentation. One of the dreams when computers appeared was that programmers will build libraries that everyone will use and people would just build on top of these libraries, reaching ever higher.
Instead, we have I don't know how many re-implementations of things in various incompatible/slightly incompatible languages. And that's just for OSS, nevermind the billion proprietary re-implementations.
Truly the Tower of Babel.
As bad as Javascript is generally considered, from this philosophical point of view at least we seemed to be on the right track...