I saw some tests, but WASM edge cases can get pretty complicated (especially around post-unreachable stack validation logic). I suggest "git-submoduling" the stuff from "core" at https://github.com/WebAssembly/spec/tree/master/test. This is a pretty good test suite for both your parser and your interpreter and doesn't require too much work on the part of a harness to support.
Cool. I ran into lots of gotchas when I was doing it. Granted there is a much better written spec now. If you hit any snags, feel free to hit me up (email is on github profile which is on HN profile).
Sorry, I don't do Twitter or FB, though if you want to keep it public, feel free to start a gitter or just open a github issue/discussion and @-mention me.
That could be really useful to deploy on browsers without native WASM support.
Can you give us an idea of the perfs though?
Since WASM is used for some performance intensive applications it would be useful to know how does this polyfill compare to native WASM /asm.js or regular js.
Maybe not, but I wouldn't be sure that that's it; the stated version on the top of the page is an important one, or at least is as long as IE 11 is a thing.
Considering that all major [evergreen] browsers support it, what are the use cases for something like this?
Adding support to IE?
A starting point for polyfilling future versions of WASM?
Do browsers that support WASM support reading the text format?
If not, this could be useful to write WASM directly.
In the article, the links under "The parsing is available for the following formats:" are broken. Does anybody know where they should point to?
As soon as it is possible to write WASM directly and have it execute it by the browser, I would start trying it out. I hope somebody will come up with a better textual representation then the currently proposed one with all the parenthesis.
WASM is bytecode and a spec - writing it by hand would make as much sense as writing an executable binary in assembly. You could do it that way, but it kind of defeats the point, and writing anything nontrivial becomes impractical.
Write something in a language that targets WASM and compile to it - it's an easier way of accomplishing the same end result, and that's what it's for.