10 ms·

Assembling WebAssembly

202 points by jfbastien 9y ago

jfbastien 9y 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 https://news.ycombinator.com/item?id=14489577 Now that these points are out of the way, let's discuss implementation details, WebAssembly, and things!
- baq 9y ago
  Give me qt in the browser, the rest are details.
  - jlebrech 9y ago
    boom, qt, gtk, even xlib (or a win32 clone) would be better than html/css/js bullshit
    - majewsky 9y ago
      HTML/CSS/JS has some huge advantages from the user perspective. When a designer has made some questionable choices, all it takes is a user stylesheet or a quick tour to the devtools to fix the font size and contrast ratio. The whole world of extensions that improve existing websites with additional buttons etc. is only possible because the page structure is exposed in the DOM. If Reddit were only WASM rendering on a <canvas>, there were no "Better Reddit" extensions.
      - jlebrech 9y ago
        reddit would probably have an opensource rendering layer or third party uis that use it's api. wasm will be the new android without the need to install apps.
        majewsky 9y ago
        That's what they said about HTML 5, too.
      - k__ 9y ago
        Also, nobody wants to pay a C++ dev for doing a JS devs work, haha
        jlebrech 9y ago
        you can still code in js or any other language.
        fpoling 9y ago
        It is more like "you can code in any language as long as it JS".
        k__ 9y ago
        I know. I just thought, with JavaScript front-end development has been commoditized and C++ is harder than JavaScript. So I don't think many people would pay a more expensive C++ dev to use Qt for a WASM based app, if they could get it all going with a cheap JS dev.
      - baq 9y ago
        there's reddit and then there are all the in house enterprise-ish apps that basically amount to moving buckets of bits between cross-linked tables for which html+css is not cost effective.
    - oblio 9y ago
      How do you easily skin xlib or win32? (I think that Qt and Gtk support stylesheets)
      - jlebrech 9y ago
        I think you could still use stylesheets, just not for the good defaults.
  - bigato 9y ago
    tcl/ttk is all i want
  - Ajedi32 9y 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.
    - CyberDildonics 9y ago
      That's why you don't want Qt in the browser? It isn't having to download 25MB for a hello world program?
JoshTriplett 9y 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.
- pizlonator 9y 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.
  - TazeTSchnitzel 9y 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?
    - saamyjoon 9y ago
      It's implementation dependent. Most implementations JIT Wasm up front (I think Chakra is the only engine that interprets). So, JS loads faster because almost all engines interpret first (all?).
      - TazeTSchnitzel 9y ago
        Is “interpreting” necessarily faster? Consider also this is perhaps a false distinction. V8 always produces machine code when running JS IIRC. And that code is JITed doesn't mean the entire module is.
mcphage 9y 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"?
- pizlonator 9y ago
  WTF stands for Web Template Framework. BBQ and OMG both use it.
  - mozumder 9y ago
    Ok now make LOL: LLVM Optimized Language
    - jfbastien 9y ago
      That's called B3 instead: https://webkit.org/blog/5852/introducing-the-b3-jit-compiler/ https://webkit.org/blog/5852/introducing-the-b3-jit-compiler...
    - yusukesuzuki 9y ago
      We had a chance to have LOL: Low-level Object Library. But now it is named as PAL.
HugThem 9y 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 9y 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.
  - zurn 9y 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.
    - jfbastien 9y ago
      That is incorrect. See: https://github.com/WebAssembly/spec/blob/master/papers/pldi2017.pdf https://github.com/WebAssembly/spec/blob/master/papers/pldi2... These are already old numbers, and section 7.3 says 33.7% more efficient. Were one to run updated numbers, and use more than Chrome and Firefox, I'm pretty sure the numbers would be better still.
      - zurn 9y ago
        Very interesting looking paper, thanks. I note that the comment in 7.3 says the biggest speedup vs asm.js is in validation, so I assume this means the measurement includes startup. This advantage is easy to concede to WebAssembly due to its design.
        jfbastien 9y ago
partycoder 9y 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.
- tyingq 9y 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.
  - jfbastien 9y 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.
    - tyingq 9y ago
      I don't see it as THE harbinger, but one of many. Some people will use it for the same reasons that they obfuscate things today. See, for example, the dropbox client. It's python, but they go to great lengths to keep you from peeking behind the kimono. I understand WASM isn't reverse engineering proof, but it certainly raises the bar. Especially sans source maps.
      - jfbastien 9y ago
        Source map is totally optional! It provides zero help in understanding asm.js or minified JS. I see what you're saying about binaries being opaque blobs, but I just don't see how that's different from asm.js or minified JS. Kinda sounds like you're trolling pcwalton TBH: https://twitter.com/pcwalton/status/872151997473972224 https://twitter.com/pcwalton/status/872151997473972224 I approve ;-)
phero_cnstrcts 9y ago
When will this come to mobile devices?
phero_cnstrcts 9y ago
When is this coming to iOS though? I think chrome for mobile already has it?
trishume 9y 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.
- jfbastien 9y 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 9y 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 9y 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 https://github.com/WebAssembly/design/blob/master/GC.md
AriaMinaei 9y 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 https://wiki.mozilla.org/Platform/GFX/Quantum_Render [1] https://github.com/KhronosGroup/WebGLNext-Proposals https://github.com/KhronosGroup/WebGLNext-Proposals [2] https://github.com/gpuweb/nxt-standalone https://github.com/gpuweb/nxt-standalone
childintime 9y 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.
- jfbastien 9y 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 https://twitter.com/pcwalton/status/872151997473972224
  - childintime 9y 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.md https://github.com/WebAssembly/design/blob/master/TextFormat... I am delighted :)

202 points by jfbastien 9y 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 https://news.ycombinator.com/item?id=14489577 Now that these points are out of the way, let's discuss implementation details, WebAssembly, and things!

baq 9y ago
Give me qt in the browser, the rest are details.
- jlebrech 9y ago
  boom, qt, gtk, even xlib (or a win32 clone) would be better than html/css/js bullshit
  - majewsky 9y ago
    HTML/CSS/JS has some huge advantages from the user perspective. When a designer has made some questionable choices, all it takes is a user stylesheet or a quick tour to the devtools to fix the font size and contrast ratio. The whole world of extensions that improve existing websites with additional buttons etc. is only possible because the page structure is exposed in the DOM. If Reddit were only WASM rendering on a <canvas>, there were no "Better Reddit" extensions.
    - jlebrech 9y ago
      reddit would probably have an opensource rendering layer or third party uis that use it's api. wasm will be the new android without the need to install apps.
      - majewsky 9y ago
        That's what they said about HTML 5, too.
    - k__ 9y ago
      Also, nobody wants to pay a C++ dev for doing a JS devs work, haha
      - jlebrech 9y ago
        you can still code in js or any other language.
        fpoling 9y ago
        It is more like "you can code in any language as long as it JS".
        k__ 9y ago
        I know. I just thought, with JavaScript front-end development has been commoditized and C++ is harder than JavaScript. So I don't think many people would pay a more expensive C++ dev to use Qt for a WASM based app, if they could get it all going with a cheap JS dev.
    - baq 9y ago
      there's reddit and then there are all the in house enterprise-ish apps that basically amount to moving buckets of bits between cross-linked tables for which html+css is not cost effective.
  - oblio 9y ago
    How do you easily skin xlib or win32? (I think that Qt and Gtk support stylesheets)
    - jlebrech 9y ago
      I think you could still use stylesheets, just not for the good defaults.
- bigato 9y ago
  tcl/ttk is all i want
- Ajedi32 9y 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.
  - CyberDildonics 9y ago
    That's why you don't want Qt in the browser? It isn't having to download 25MB for a hello world program?

JoshTriplett 9y 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.

pizlonator 9y 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.
- TazeTSchnitzel 9y 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?
  - saamyjoon 9y ago
    It's implementation dependent. Most implementations JIT Wasm up front (I think Chakra is the only engine that interprets). So, JS loads faster because almost all engines interpret first (all?).
    - TazeTSchnitzel 9y ago
      Is “interpreting” necessarily faster? Consider also this is perhaps a false distinction. V8 always produces machine code when running JS IIRC. And that code is JITed doesn't mean the entire module is.

mcphage 9y 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"?

pizlonator 9y ago
WTF stands for Web Template Framework. BBQ and OMG both use it.
- mozumder 9y ago
  Ok now make LOL: LLVM Optimized Language
  - jfbastien 9y ago
    That's called B3 instead: https://webkit.org/blog/5852/introducing-the-b3-jit-compiler/ https://webkit.org/blog/5852/introducing-the-b3-jit-compiler...
  - yusukesuzuki 9y ago
    We had a chance to have LOL: Low-level Object Library. But now it is named as PAL.

HugThem 9y 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 9y 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.
- zurn 9y 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.
  - jfbastien 9y ago
    That is incorrect. See: https://github.com/WebAssembly/spec/blob/master/papers/pldi2017.pdf https://github.com/WebAssembly/spec/blob/master/papers/pldi2... These are already old numbers, and section 7.3 says 33.7% more efficient. Were one to run updated numbers, and use more than Chrome and Firefox, I'm pretty sure the numbers would be better still.
    - zurn 9y ago
      Very interesting looking paper, thanks. I note that the comment in 7.3 says the biggest speedup vs asm.js is in validation, so I assume this means the measurement includes startup. This advantage is easy to concede to WebAssembly due to its design.
      - jfbastien 9y ago

partycoder 9y 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.

tyingq 9y 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.
- jfbastien 9y 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.
  - tyingq 9y ago
    I don't see it as THE harbinger, but one of many. Some people will use it for the same reasons that they obfuscate things today. See, for example, the dropbox client. It's python, but they go to great lengths to keep you from peeking behind the kimono. I understand WASM isn't reverse engineering proof, but it certainly raises the bar. Especially sans source maps.
    - jfbastien 9y ago
      Source map is totally optional! It provides zero help in understanding asm.js or minified JS. I see what you're saying about binaries being opaque blobs, but I just don't see how that's different from asm.js or minified JS. Kinda sounds like you're trolling pcwalton TBH: https://twitter.com/pcwalton/status/872151997473972224 https://twitter.com/pcwalton/status/872151997473972224 I approve ;-)

phero_cnstrcts 9y ago

When will this come to mobile devices?

phero_cnstrcts 9y ago

When is this coming to iOS though? I think chrome for mobile already has it?

trishume 9y 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.

jfbastien 9y 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 9y 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 9y 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 https://github.com/WebAssembly/design/blob/master/GC.md

AriaMinaei 9y 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 https://wiki.mozilla.org/Platform/GFX/Quantum_Render [1] https://github.com/KhronosGroup/WebGLNext-Proposals https://github.com/KhronosGroup/WebGLNext-Proposals [2] https://github.com/gpuweb/nxt-standalone https://github.com/gpuweb/nxt-standalone

childintime 9y 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.

jfbastien 9y 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 https://twitter.com/pcwalton/status/872151997473972224
- childintime 9y 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.md https://github.com/WebAssembly/design/blob/master/TextFormat... I am delighted :)