7 ms·

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

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.
    - saamyjoon 9y ago
      V8 used to do this. Now they have a JS interpreter called Ignition.
    - bzbarsky 9y ago
      > V8 always produces machine code when running JS IIRC. They used to. They stopped doing that because it made initial load too slow...
  - luke_wagner 9y ago
    I think the primarily-AOT compilation strategy we see today is a consequence of many of the initial workloads being frame-based animation where AOT avoids animation stutters. But this is likely to evolve over time as wasm workloads evolve. If and when we see wasm showing up in frameworks in contexts where page-load is the primary concern I can see a more lazy JIT strategy being the right thing and then we'd want to specify some sort of developer knob to control this. But given a pure-JIT approach like Chakra is using, wasm should be able to load code byte-for-byte faster than JS.
    - saamyjoon 9y ago
      I agree. Chakra uses a pure JIT approach? I thought they interpret both in JS and Wasm?
      - luke_wagner 9y ago
        Maybe some terminology difference here but what I meant by 'pure JIT' was that, iiuc, Chakra waits until the function is called to even validate it, then warms up in an interpreter and only if the function is hot compiles it in a background thread. I think that's one end of the eager/lazy spectrum that may well be what a category of wasm uses will want.
    - deleted 9y ago
      [deleted]
    - Someone 9y ago
      WebKit already has a more lazy JIT strategy. From the article being discussed: "WebKit’s WebAssembly implementation, like our JavaScript implementation, uses a tiering system to balance startup costs with throughput. Currently, there are two tiers to the engine: the Build Bytecode Quickly (BBQ) tier and the Optimized Machine-code Generator (OMG) tier. Both rely on the B3 JIT as their low-level optimizer."
sp332 9y 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-fast/ https://hacks.mozilla.org/2017/02/what-makes-webassembly-fas...
- pizlonator 9y ago
  WebKit has a fast JS parser. I don't think this would be true for us.
  - merb 9y ago
    I'm not sure if that is true. our application takes at least 100ms or more to parse. only parsing. on Safari 10.1.1 on a macbook pro 2013 late. well chrome and firefox is as slow as that. I don't think the same stuff in WebAssembly would take that long (i.e. angular 1 application, if we add angular 4 which we are planning it will prolly take even longer since we need more vendor stuff.)
    - jfbastien 9y ago
      Link to repro?
      - merb 9y ago
        not open source. but start with angular 4 hello world. that takes a little while to parse, too.
JoshTriplett 9y 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.
- jfbastien 9y ago
  For reference, the current GC proposal is here: https://github.com/WebAssembly/gc/blob/master/proposals/gc/Overview.md https://github.com/WebAssembly/gc/blob/master/proposals/gc/O... I expect it'll be discussed at an upcoming CG meeting. Either the next one or the one after.
- pizlonator 9y ago
  > 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). Those discussions have not resulted in a proposal. Ownership semantics are most likely not going to work. The options being considered are: - WebAssembly has strong or weak handles to JS objects. That's not ownership. - WebAssembly can allocate GC'd objects. That's not ownership. - WebAssembly exposes enough stuff so that you can write your own GC. That's ownership, sorta, but doesn't allow wasm to access JS objects. Wasm would simply own objects it allocated in its own heap and would never be able to claim ownership of JS objects or relinquish ownership of its objects to JS. By itself, this means zero GC interop with JS. Most likely, we'll end up with all three options. It sounds like you're proposing that WebAssembly can somehow come to own a JS object. That's not practical, since it would imply either eagerly ref-counting all JS objects (that's a 2x slow-down), or it would imply full synchronous GC every time you share any object (totally impractical), or it would imply pretending that WebAssembly can own an object without first proving it (then wasm code could create use-after-free bugs to escape the web sandbox). > What we have today seems very close to that in practice. You have to use JS API to load wasm, so we're not close to this at all. > A combination of a fast bytecode interpreter and compiled code caching could probably manage that. Or a fast, targeted JIT. So long as WebAssembly is a low-level compiler target, that implies that developers shipping WebAssembly will also be shipping a userland for whatever their source language is. See emscripten for example, which has a large userland (the "emsdk", which includes libc and other things). So long as this is the pattern, WebAssembly will necessarily take longer to load than JS because the same program written in wasm will be bigger than its JS variant. > Still an improvement, but also see above about ownership semantics. I don't think your ownership idea will work, see above.
madeofpalk 9y ago
What would it take to give WebAssembly access to the DOM?
- jfbastien 9y ago
  See here: https://news.ycombinator.com/item?id=14501262 https://news.ycombinator.com/item?id=14501262 Proposal: https://github.com/WebAssembly/gc/blob/master/proposals/gc/Overview.md https://github.com/WebAssembly/gc/blob/master/proposals/gc/O...
  - madeofpalk 9y ago
    Ahh my bad. I'm just a lowly CSS developer, so I didn't realise that GC (garbage collection?) came with interoperability to the DOM
    - jfbastien 9y ago
      No worries! It's all non-obvious :-) Yes GC == Garbage Collection.
pjmlp 9y 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.
- OskarS 9y ago
  I hadn't thought about this before, but your comment made me aware that if you wanted to compile any kind of high-level language with GC into WebAssembly, you have to download it with an entire runtime. I wonder how much overhead that adds to downloads. Like, if you compile a C# or Java thing for wasm, do you have to download a 30mb runtime every page you load?
  - pjmlp 9y ago
    Yes, but one can probably trim it down to what is actually used. Java runtime is only 8MB (JVM) + whatever classes are actually required, other ones can be removed by something like ProGuard or the new linker. .NET Native is quite similar. Same applies to OCaml, Haskell, Scala, Go, ....
  - flohofwoe 9y ago
    I think it'll be more like 1..3 MB for something like the .NET mscorlib, but yes, the runtime overhead cost is definitely there. The more "managed" the language is the worse this will be. That's why it makes a lot of sense to use 'bare metal' languages which have a very small, or even completely optional runtime for WebAssembly, and use an 'embedded platform' programming style, that way you can get useful WebAssembly modules down to a few dozen kilobytes.
  - vanderZwan 9y ago
    Wouldn't modules allow you to load the language runtime separately from a CDN, so that it remains cached? Kind of like people do right now with jQuery? It still would be nice if that runtime was slim of course; IIRC mobile browsers especially have small caches.

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.
  - saamyjoon 9y ago
    V8 used to do this. Now they have a JS interpreter called Ignition.
  - bzbarsky 9y ago
    > V8 always produces machine code when running JS IIRC. They used to. They stopped doing that because it made initial load too slow...
- luke_wagner 9y ago
  I think the primarily-AOT compilation strategy we see today is a consequence of many of the initial workloads being frame-based animation where AOT avoids animation stutters. But this is likely to evolve over time as wasm workloads evolve. If and when we see wasm showing up in frameworks in contexts where page-load is the primary concern I can see a more lazy JIT strategy being the right thing and then we'd want to specify some sort of developer knob to control this. But given a pure-JIT approach like Chakra is using, wasm should be able to load code byte-for-byte faster than JS.
  - saamyjoon 9y ago
    I agree. Chakra uses a pure JIT approach? I thought they interpret both in JS and Wasm?
    - luke_wagner 9y ago
      Maybe some terminology difference here but what I meant by 'pure JIT' was that, iiuc, Chakra waits until the function is called to even validate it, then warms up in an interpreter and only if the function is hot compiles it in a background thread. I think that's one end of the eager/lazy spectrum that may well be what a category of wasm uses will want.
  - deleted 9y ago
    [deleted]
  - Someone 9y ago
    WebKit already has a more lazy JIT strategy. From the article being discussed: "WebKit’s WebAssembly implementation, like our JavaScript implementation, uses a tiering system to balance startup costs with throughput. Currently, there are two tiers to the engine: the Build Bytecode Quickly (BBQ) tier and the Optimized Machine-code Generator (OMG) tier. Both rely on the B3 JIT as their low-level optimizer."

sp332 9y 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-fast/ https://hacks.mozilla.org/2017/02/what-makes-webassembly-fas...

pizlonator 9y ago
WebKit has a fast JS parser. I don't think this would be true for us.
- merb 9y ago
  I'm not sure if that is true. our application takes at least 100ms or more to parse. only parsing. on Safari 10.1.1 on a macbook pro 2013 late. well chrome and firefox is as slow as that. I don't think the same stuff in WebAssembly would take that long (i.e. angular 1 application, if we add angular 4 which we are planning it will prolly take even longer since we need more vendor stuff.)
  - jfbastien 9y ago
    Link to repro?
    - merb 9y ago
      not open source. but start with angular 4 hello world. that takes a little while to parse, too.

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

jfbastien 9y ago
For reference, the current GC proposal is here: https://github.com/WebAssembly/gc/blob/master/proposals/gc/Overview.md https://github.com/WebAssembly/gc/blob/master/proposals/gc/O... I expect it'll be discussed at an upcoming CG meeting. Either the next one or the one after.
pizlonator 9y ago
> 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). Those discussions have not resulted in a proposal. Ownership semantics are most likely not going to work. The options being considered are: - WebAssembly has strong or weak handles to JS objects. That's not ownership. - WebAssembly can allocate GC'd objects. That's not ownership. - WebAssembly exposes enough stuff so that you can write your own GC. That's ownership, sorta, but doesn't allow wasm to access JS objects. Wasm would simply own objects it allocated in its own heap and would never be able to claim ownership of JS objects or relinquish ownership of its objects to JS. By itself, this means zero GC interop with JS. Most likely, we'll end up with all three options. It sounds like you're proposing that WebAssembly can somehow come to own a JS object. That's not practical, since it would imply either eagerly ref-counting all JS objects (that's a 2x slow-down), or it would imply full synchronous GC every time you share any object (totally impractical), or it would imply pretending that WebAssembly can own an object without first proving it (then wasm code could create use-after-free bugs to escape the web sandbox). > What we have today seems very close to that in practice. You have to use JS API to load wasm, so we're not close to this at all. > A combination of a fast bytecode interpreter and compiled code caching could probably manage that. Or a fast, targeted JIT. So long as WebAssembly is a low-level compiler target, that implies that developers shipping WebAssembly will also be shipping a userland for whatever their source language is. See emscripten for example, which has a large userland (the "emsdk", which includes libc and other things). So long as this is the pattern, WebAssembly will necessarily take longer to load than JS because the same program written in wasm will be bigger than its JS variant. > Still an improvement, but also see above about ownership semantics. I don't think your ownership idea will work, see above.

madeofpalk 9y ago

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

jfbastien 9y ago
See here: https://news.ycombinator.com/item?id=14501262 https://news.ycombinator.com/item?id=14501262 Proposal: https://github.com/WebAssembly/gc/blob/master/proposals/gc/Overview.md https://github.com/WebAssembly/gc/blob/master/proposals/gc/O...
- madeofpalk 9y ago
  Ahh my bad. I'm just a lowly CSS developer, so I didn't realise that GC (garbage collection?) came with interoperability to the DOM
  - jfbastien 9y ago
    No worries! It's all non-obvious :-) Yes GC == Garbage Collection.

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

OskarS 9y ago
I hadn't thought about this before, but your comment made me aware that if you wanted to compile any kind of high-level language with GC into WebAssembly, you have to download it with an entire runtime. I wonder how much overhead that adds to downloads. Like, if you compile a C# or Java thing for wasm, do you have to download a 30mb runtime every page you load?
- pjmlp 9y ago
  Yes, but one can probably trim it down to what is actually used. Java runtime is only 8MB (JVM) + whatever classes are actually required, other ones can be removed by something like ProGuard or the new linker. .NET Native is quite similar. Same applies to OCaml, Haskell, Scala, Go, ....
- flohofwoe 9y ago
  I think it'll be more like 1..3 MB for something like the .NET mscorlib, but yes, the runtime overhead cost is definitely there. The more "managed" the language is the worse this will be. That's why it makes a lot of sense to use 'bare metal' languages which have a very small, or even completely optional runtime for WebAssembly, and use an 'embedded platform' programming style, that way you can get useful WebAssembly modules down to a few dozen kilobytes.
- vanderZwan 9y ago
  Wouldn't modules allow you to load the language runtime separately from a CDN, so that it remains cached? Kind of like people do right now with jQuery? It still would be nice if that runtime was slim of course; IIRC mobile browsers especially have small caches.