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.

Yes I planned to support the spec core tests (that's why I implemented WAST in the first place).

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

Ok thanks, can we connect on twitter? https://twitter.com/svensauleau/.

I can see on your GitHub page that you made the famous WebAssembly to JVM, nice job!

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.

(Thanks!)

Ok

Now you just need to compile a JavaScript interpreter from C++ to WebAssembly... Makes me think of “The Birth & Death of JavaScript” talk [1].

[1] https://www.destroyallsoftware.com/talks/the-birth-and-death...

I have bad news for you ;) https://github.com/mbbill/JSC.js

Or good depending on the perspective of course.

We need brainfuck in this pipeline somewhere

I'd prefer C-INTERCAL or LOLCODE

Upvote for INTERCAL. Keywords like "please" and "maybe" should be part of every language :)

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.

I have done a few benchmark but it's still too early to be relevant.

I want to take advantage of the optimization done by the JavaScript VM and asm.js in the future.

Am I the only one wondering whether or not this was created only because of the irony of a WebAssembly interpreter being written in JavaScript?

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.

Wouldn't it be better to just deploy asm.js alongside wasm? Emscripten can easily generate both, and a simple check can select which script to load.

    if(window.WebAssembly != null){
        loadScript('script.wasm.js');
    }else{
        loadScript('script.asm.js');
    }

Quite possibly! Only one way to find out.

Actually polyfilling is only one of my goals. I think that it could work as a good playground for the spec since you can easily try out new things.

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?

Fair question. WebAssembly's browser support is indeed already pretty good, as I understand it.

Might be useful for old versions of IE, I suppose.

Lots of corporate desktops are still running IE11 on Windows 7, and they won't upgrade until they absolutely have to.

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.

You can already play with WASM directly in the browser.

https://wasdk.github.io/WasmFiddle/

https://mbebenita.github.io/WasmExplorer/

I prefer the explorer one.

The s-exp representation is great for doing compiler development, hence why it was chosen.

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.

Browsers won't support it, that's a good point. Note that WAST (text) is much more bigger than WASM (binary).