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 ..