- GC types in WebAssembly. That's still an open problem, but that would give you API access.
- Ability to load WebAssembly via something like <script>.
- WebAssembly would have to load and start as quickly as JS.
The last one is probably the hardest in the long run, since wasm is being optimized for the kinds of apps where you want to pay some cost up front so that you get great throughput later.
Note also that GC types would make it harder to compile existing languages to wasm, since those GC types will probably have to have JS semantics built into them from the start to allow API interoperability. So, even if wasm succeeds in the way you'd like, it would probably mean that the language of the web is still something JavaScriptey.
I've seen numerous discussions about integrating WebAssembly with the JavaScript heap. That might not require full GC; ownership semantics might suffice (such that either wasm or JS can own the object at any given time, and within the wasm world it can use wasm memory management).
> - Ability to load WebAssembly via something like <script>.
What we have today seems very close to that in practice.
> - WebAssembly would have to load and start as quickly as JS.
A combination of a fast bytecode interpreter and compiled code caching could probably manage that. Or a fast, targeted JIT.
> Note also that GC types would make it harder to compile existing languages to wasm, since those GC types will probably have to have JS semantics built into them from the start to allow API interoperability. So, even if wasm succeeds in the way you'd like, it would probably mean that the language of the web is still something JavaScriptey.
Still an improvement, but also see above about ownership semantics.
Nothing prevents one to implement a GC on top of existing WebAssembly as it is, no different than when implementing bare metal runtimes.
Of course having a GC as part of WebAssembly does simplify implementations, but only as an easy solution, because the best GC implementations need to be language aware for optimal performance.
Wouldn't it already load faster than JS, because it's much less work to compile and doesn't require guessing types?
A massively simpler frontend than JS itself — it's closer to, well, assembly :) while JS is a dynamic language.
What we get in return is very very close to native execution speed for all the performance-sensitive things you might want to run on a computer — game engines, crypto, compression, codecs, etc. — in a sandboxed and portable way. One executable for everything from the typical Windows/amd64 desktop to your NetBSD/mips toaster, potentially.
Right now the chain is: Developer writes code in something like Typescript that then is translated to Javascript and then is downloaded by the browser (huge downloads compared to binary code). The browser then needs to parse that huge amount of javascript code to compile it into a bytecode that can then be JIT executed or interpreted.
With webassembly it would be as follows:
Developer writes code in the language of his/her choice, that then is compiled to a small bytecode. This bytecode is downloaded by the browser and then it is JIT executed or interpreted.
It is simpler, more flexible, and potentially faster.
There's countries in the world that still use IE6, and that's comparatively an easier transition :)
Also, as has been mentioned by others, WebAssembly could perhaps evolve to take a greater role, leading to a greater potential impact of performance gains.
Finally, if the complexity does in fact outweigh the benefit, the idea would eventually fade away. So far it looks promising. Time will tell.
JavaScript is not bad at the high level, but at the low level it has been hell for engineers to implement a fast VM. A wasm VM is way easier to implement than a JavaScript VM.
I'm not sure what you think makes it the harbinger of closed web. As the WebAssembly CG chair, I'd be interested in understanding that.
The fastest VMs on the planet are JS VMs right now.
Now that these points are out of the way, let's discuss implementation details, WebAssembly, and things!
I assume the next tier they're going to do will be "WTF"?
Also, it probably means the end of the Web as we know it.
Browsers very likely should treat closed source like they treat our microphone or camera: don't give access unless the user consents.
But do allow it to run without consent if, and only if, the source code is public.
You can get text out of WebAssembly as well as you can get text out of minified JS.
Further, users don't care about this. It's literally just developers. Open Source / Free Software is a super valid discussion to have, but I highly doubt any non-technical user cares.
Amusingly, pcwalton brought up this discussion recently: https://twitter.com/pcwalton/status/872151997473972224
But I looked it up and it seems WebAssembly preserves the structure of the original document, just like minification, at least that's what I understand from the following quote:
"In practice, outer blocks can be used to place labels for any given branching pattern, except that the nesting restriction makes it impossible to branch into the middle of a loop from outside the loop. This limitation ensures by construction that all control flow graphs are well-structured as in high-level languages like Java, JavaScript and Go." See: https://github.com/WebAssembly/design/blob/master/TextFormat...
I am delighted :)
Given the work that has gone into B3 it might make a good target IR for compilers that want fast compilation to native executables, and you'd get to target the web for free as a bonus.
Depending on what you want to do, there are a few experimental .wasm -> LLVM IR -> machine code things around.
Problem is really what your embedder would be. Import / export is what you'd have to define! In JavaScript we have a standardized API for that.
I imagine programmable layout, GPU contour rasterization, motion-blur, programmable shaders, layer blending, LOD and infinite zooming, and render-to-texture (for putting 2D surfaces in a 3D scene).
None of this is unnecessary if you bring AR/VR to the mix. Soon people will want to put on their AR/VR glasses and read books, select pieces of text, open links, etc. There are no APIs that allows them to do that in a web browser. Ergo => flock to native.
Quite a bit of work remains for that to happen. A whole bunch of APIs need to be exposed in the browser, such as native text rendering APIs, a better-than-WebGL2 API for graphics [1][2], a way to make the webpage accessible to non-humans (eg. How do you make the page reader-friendly? how do you do "Find in page"? How do you index the content?), etc.
[0] https://wiki.mozilla.org/Platform/GFX/Quantum_Render [1] https://github.com/KhronosGroup/WebGLNext-Proposals [2] https://github.com/gpuweb/nxt-standalone
I think chrome for mobile already has it?
