Assembling WebAssembly

https://webkit.org/blog/7691/webassembly/

by jfbastien • 9 years ago

202 86 9 years ago

jfbastien15• 9 years ago

Summarizing the "JSC <3 ES6" discussion and translating to WebAssembly: no ServiceWorker, polyfills from C++ / asm.js to WebAssembly won't be fast enough, "ES6" is a bad name and so is "WebAssembly", "we" is the WebKit team (as individuals), no tail call in WebAssembly but it's on the roadmap. https://news.ycombinator.com/item?id=14489577

Now that these points are out of the way, let's discuss implementation details, WebAssembly, and things!

baq2• 9 years ago

Give me qt in the browser, the rest are details.

jlebrech4• 9 years ago

boom, qt, gtk, even xlib (or a win32 clone) would be better than html/css/js bullshit

bigato• 9 years ago

tcl/ttk is all i want

Ajedi32• 9 years ago

Please no. We only just finished killing Flash (mostly); the last thing we need is another UI framework which doesn't respect standard features of the web platform taking its place.

JoshTriplett2• 9 years ago

I really look forward to the day when WebAssembly stops being seen as "JavaScript's fast sidekick" and starts being seen as "the language of the web". It won't take that much to expose APIs directly to WebAssembly rather than just to JavaScript.

pizlonator4• 9 years ago

We're a long way away from that. Here's what you'd need:

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

TazeTSchnitzel2• 9 years ago

WebAssembly would have to load and start as quickly as JS.

Wouldn't it already load faster than JS, because it's much less work to compile and doesn't require guessing types?

sp332• 9 years ago

Large JS applications take so long to parse that they could already be slower on startup. https://hacks.mozilla.org/2017/02/what-makes-webassembly-fas...

JoshTriplett2• 9 years ago

- GC types in WebAssembly. That's still an open problem, but that would give you API access.

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.

madeofpalk2• 9 years ago

What would it take to give WebAssembly access to the DOM?

pjmlp3• 9 years ago

GC types in WebAssembly. That's still an open problem, but that would give you API access.

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.

mcphage• 9 years ago

Currently, there are two tiers to the engine: the Build Bytecode Quickly (BBQ) tier and the Optimized Machine-code Generator (OMG) tier.

I assume the next tier they're going to do will be "WTF"?

pizlonator4• 9 years ago

WTF stands for Web Template Framework. BBQ and OMG both use it.

mozumder• 9 years ago

Ok now make LOL: LLVM Optimized Language

HugThem• 9 years ago

Man, we are bringing a giant load of complexity into the browser with this. As I understand it, what we get in return is a 2x speed increase. I wonder if its worth it.

dwg• 9 years ago

As I understand it, potential performance gains are higher than 2x, and we're still in a pretty early stage. It depends on your application.

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.

zurn2• 9 years ago

Where does even the 2x come from? Currently it looks very much like 1x vs integer hinted JS code like generated by asm.js.

floatboth• 9 years ago

What complexity? It's just a new frontend for the complex tiered interpreter-and-JIT-compiler monstrosities that JS engines have.

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.

jfbastien15• 9 years ago

It's quite a bit more than a frontend, but I agree it isn't as complex as the JS engine itself. For comparison, this is the JSC wasm implementation: https://github.com/WebKit/webkit/tree/master/Source/JavaScri...

flavio812• 9 years ago

We are potentially removing the complexity at all ends.

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.

oblio2• 9 years ago

That's assuming the old ways are deprecated and removed.

There's countries in the world that still use IE6, and that's comparatively an easier transition :)

partycoder2• 9 years ago

I hope wasm becomes the first class citizen and JavaScript becomes just one out of many languages that compiles to it.

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.

tyingq3• 9 years ago

I do like the upside, but coupled with DRM support, it's going to be used to obfuscate, hide and control things. I'm expecting a much less open web coming.

jfbastien15• 9 years ago

WebAssembly is as Turing-complete as JavaScript is, and has fewer APIs. The only API it has JS doesn't really is grow_memory, and even that can kinda be done with ArrayBuffer.

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.

partycoder2• 9 years ago

Well, while true, today many things are being hidden from browsers by doing them server-side.

k__4• 9 years ago

Has it?

The fastest VMs on the planet are JS VMs right now.

stevedonovan• 9 years ago

Well, there's a smart fellow called Mike Pall who would like to race Lua against JavaScript for you. Plus, the very best VMs are Java.

phero_cnstrcts• 9 years ago

When is this coming to iOS though?

I think chrome for mobile already has it?

trishume• 9 years ago

I wonder how easy it would be to use JSC's WebAssembly backend separately from the rest of Webkit, and maybe even have it output to a static binary. And maybe connect its FFI with a different language than Javascript (maybe Go?).

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.

jfbastien15• 9 years ago

Not too bad. Some things are connected to GC and JIT-code generation, but if you wanted just BBQ or OMG (no tiering) something could be done. Tiering too, but then you have more of JSC in there, really depends what you want.

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.

themihai• 9 years ago

This sounds quite disappointing to me: "WebAssembly cannot access the DOM except by calling into JavaScript. WebAssembly is meant to be used in conjunction with JavaScript."

comex• 9 years ago

That text is a bit misleading. WebAssembly currently can't access the DOM directly, but it's definitely a goal to let it do so in the future:

https://github.com/WebAssembly/design/blob/master/GC.md

AriaMinaei• 9 years ago

I hope soon we'll have a shot at rethinking the browser's rendering stack. Not necessarily ala WebRender [0] since it needs to be backwards-compatible, but something with a clean slate.

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

childintime2• 9 years ago

WebAssembly means closed source binaries all over again, and threatens our ability in all the metrics Stallman advocates.

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.

jfbastien15• 9 years ago

This is pure nonsense. WebAssembly is no more obscure than asm.js or minified JavaScript. "Binary" versus Unicode-enabled minified and transformed "source" is the same thing.

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

childintime2• 9 years ago

I guess you may be right! I presumed WebAssembly to be some sort of opaque "goto-soup" (unlike minification), as the term "assembly" suggests.

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

Assembling WebAssembly

Related Stories