(This is a technical counterpart to my post on using Wuffs to decode GIFs in the browser. If you'd just like to see fast GIF decoding, go here! 🖼️➡...
For further actions, you may consider blocking this person and/or reporting abuse
Wonderful article, though I have a quick question.
Why do you think this? Personally I think should have been worked on immediately after the MVP and think this is a really important piece of functionality missing from WASM.
I don't think it's unsolvable but as I mentioned, not without changes on the JS side. I suppose the key thing I wanted to say is "directly"—the challenge is that the current
importstatement just isn't expressive enough, because in 99% of cases we need to provide an environment to the.wasmcode itself.And it's challenging because some extension like this makes no sense:
I've invented
withto provide the language support here, but regardless: with ES2015 modules,importis evaluated before all code, soenvis just undefined on the import line.Very basic WASM could be supported, because it doesn't need imports—but as soon as you need to provide memory, or any of the calls or variables I described above, all bets are off.
There might also be some solution I've not thought of yet :)
Hi Sam!
Really great article, and really long.
Thanks for that!
Now I see that wasm isn't silver bullet.
But anyway looks promising.
Are there already other runtimes?
I'm not sure of any other runtimes for compiling C/C++ to WASM, no, sorry. The complaints I have are repeated on the bug tracker (possibly in more places too).
So I suspect there might some community projects because of the issues I'm raising. Let me know if you find any!
(Of course, there's also runtimes/compilers for Go, Rust, etc—I've not researched them enormously. I believe Go is much nicer to work with because its JS boilerplate is just a common bit of code you include, it's not built per-binary, which means it's much, much easier to understand and work with.)