Had a quick look through, looks interesting.
Some thoughts
* 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.
I would say that 32bit are more than enough for most web applications. I struggle to recall any web application that would require more than 4GB of RAM to run.
Desktop applications are increasingly moving to the web. Regardless of whether you think this is a good thing, the standard has to take that into account.
I doubt that every single desktop application will move into the web for a good long while, long enough to have a smooth transition from 32bit to 64bit if necessary, though I doubt applications that need more will use WASM.
WebAssembly apps don't have to be hosted on the web, or run in a browser. They will, almost exclusively, because the "browser as OS" model is what modern web developers have fixated on, because of javascript. But, there's no reason users couldn't install and run WASM natively as well.
No. I'm imagining it doesn't even have a traditional DOM. It's using it's own custom rolled framework and web assembly which makes the browser like a blank canvas. Super cool.
I really love the idea of WebAssembly but am super intimidated by it. Being a junior frontend dev it seems like a really powerful piece of tech that could go in a million directions in the future.
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?
If you are a junior frontend developer, WASM probably just doesn't mean much to you, and probably won't. You'll use it, wrapped by a JavaScript facade, to do some performance-sensitive stuff. (Some folks are rubbing their hands together about the possibility of using the DOM in another language and not writing JavaScript; this will eventually happen, but I strongly doubt mainstream frontend development will go that way in the reasonably near future.
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.
> Some folks are rubbing their hands together about the possibility of using the DOM in another language and not writing JavaScript; this will eventually happen
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.
GC interaction is not needed for DOM stuff. That was originally the case, but the "host bindings" proposal lets it shed that dependency. I pasted a link downthread.
I dunno. It's no more massive than most other computing environments. JavaScript is an aberration in the way it's structured. This is certainly a matter of perspective; I tend to think that starting with a restrictive environment like JavaScript (and don't get me wrong, I like JavaScript and write a decent bit of it every day) makes the cage look like the world. Pedagogically speaking, I worry about JavaScript being somewhat damaging...but, whatever.
Anyway, WASM is just trying to remove the restrictions on a strict environment (that's why it's called Web Assembly, yeah?). The example that floated to mind--you've been writing Java? This[1] is written in Clojure, but there's no reason you can't get this wacky in Java. (Not that you should.)
From my understanding one use case is Transpiling into Web Assembly. The tooling isn't there yet, but you can hopefully use it instead of JavaScript and get some type safety and performance.
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.
With enough luck and given time you will be able to skip JS at all! If the community will find the life force after wasting many years on SPA, then we might even see some HTML—near-free canvas/WebGL GUIs!
I am not a fan of this. Browsers by now have awesome text layout and rendering support, highlighting, screen reading, zooming. Individual images can be seen/copied/saved, user scripts and styles and browser plugins can access the loaded html content, and so on.
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.
While I agree that we may be able to rid ourselves of JS, why would we want to rid ourselves of HTML? It's become an excellent language for describing a UI.
I hadn't thought about using it for decoding images, clever! I'd been dreaming of translating my favorite python package over to the web to use without having to spin up django, but from what I'm hearing that isn't really the purpose.
We're not quite ready yet, but later in the year, you should check out Rust and wasm. We explicitly are interested in catering to the "am super intimidated by it" case. Right now, it all works, but is not super nice to use; it's under really heavy development though!
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.
Is anyone else afraid that this will enable a "Tower of Babel" effect where the coming sheer profusion of languages will fragment web programming into dozens of competing, mutually-incomprehensible linguistic camps.
Javascript sucks, but at least it's the web's lingua franca.
>Is anyone else afraid that this will enable a "Tower of Babel" effect where the coming sheer profusion of languages will fragment web programming into dozens of competing, mutually-incomprehensible linguistic camps.
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.
Right, they were their own separate VMs, with a lot of duplicated functionality. WASM is just a way to get native, non memory managed languages executing efficiently in a JavaScript environment.
Transpilation to JS always sucks. JS was not designed as a compiler target. The point of WASM is exactly that: Compile any language on the web without getting into the JS limitation.
Performance. WebAssembly has no JIT stage, it gets AOT compiled straight to machine code. Plus, it gives (or will give) much lower-level access to features like threads and memory allocation.
Thanks to Spectre I don't think we'll be seeing threads anytime soon. Well, not threads with shared memory anyway which removes a lot of the point of them. Same reason JavaScript just lost SharedArrayBuffer, too easy to make a high precision timer out of it.
You're describing asm.js which had significant issues as a compilation target. The generated javascript code was massive and it took several seconds just to parse it.
Right now, some of the biggest users are applications where JavaScript's garbage collection pauses are show-stoppers, like games and audio recording software.
* 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.