My big hangup is understanding a low level use case for it. I've console.logged in wasm but only knowing javascript I don't know where to go from here. Is the idea that you can utilize packages in any language then rebuild it in js?
I don't really see why you should be intimidated by it any more than a Java programmer who sees JNI barf once in a while should be intimidated by C. If you're that interested, all you really have to do is learn a normal, natively-compiled language. Which would be wise anyway--nobody serious about the field should only know one language, JavaScript or not. Then you can learn how to compile down to WASM (it's rarely difficult) and just go from there.
Sadly WASM doesn't help here at all due to lack of way to interact with the GC. Not only lack of finalisers but that having two GCs doesn't work. I learnt this 2 times over the hard way.
For something today, look to fengari: https://fengari.io/ . It implements a VM in javascript, reusing the javascript garbage collector, which means that you get seamless DOM interaction.
Thanks for explanation though, I'm not intimidated of it taking my job as much as I am the wide scope of the thing. Seems massive!
Sure you can use a language like TypeScript or one of the others that will transpile down to JavaScript giving you type safety, but you won't have the performance of web assembly. Although, I've yet to see what you'll need that performance for. A few of my co-workers are excited about it, but I've been pressing them, we don't need that level of performance on the SPA type stuff we write.
I think having web assembly will give you new avenues and use cases people haven't fully considered yet.
All this will have to be redone in canvas for no good reason and I doubt it will be nearly as good as what browsers can do already, and we will lose a lot of openness and interop.
Expect the revenge of browser plugins.
Two real world use cases for WebAssembly are image decoding and audio decoding.
WebP image decoding: https://webmproject.github.io/libwebp-demo/webp_wasm/index.h...
Opus audio decoding: https://www.scirra.com/blog/211/opus-audio-in-construct-3
Move heavy number crunching into WASM.
* Only 32-bit address space (although they do say "Future version of WebAssembly might provide memory instructions with 64 bit address ranges")
* Webassembly is pretty low level. Just 4 basic types (integers, floats). No C-style structures even. This is lower level than e.g. LLVM IR, and lower level than the Java VM.
* No garbage collection support.
I hope Webassembly can be used from not just Javascript, but something like C++, directly.
https://github.com/appcypher/awesome-wasm-langs/blob/master/...
As for lacking a GC in its present version, the runtime can always bring one along, just like in most CPUs.
I'd like to know because a real committment could signal a huge shift, although personally I'd rather use flux+react but written in c#.
If the DOM gets accessible from wasm, we'll finally be able to avoid using javascript entirely.
It's crazy how much time and effort are necessary to finally be able to make a piece of software work on any computer, without having to make different high level graphical API work together.
The cherry on top would be to have both the dom AND websockets.
In fact, that's also currently the only way to access other APIs like WebGL from WASM.
Javascript sucks, but at least it's the web's lingua franca.
That's already happening - web development seems to assume that compiling to javascript from any one of a legion of languages should be standard practice.
