Hacker News Reader

Comment by JoshTriplett | Hacker News Reader

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.

View on HN

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.

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

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

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

Binary bytecode, which is what webassembly apps are, is often, generally, almost always smaller than source code. Except for really small programs.

Also, js code needs to be parsed previously. Webassembly code does not. Webassembly should load faster and execute faster.

Happy times ahead on the browser side...

I believe the thought was that, for many languages, there is an additional, standard runtime, which is not always remove-able from the language itself, which may not always be of a trivial size, and which is not guaranteed to be already available on a client machine.

I think you're misunderstanding Fil's point: JS is more expressive, and can often encode more things in a smaller package.

For same-code wasm / asm.js / x86 comparison (not what Fil was talking about) see section 7.3: https://github.com/WebAssembly/spec/blob/master/papers/pldi2...

Additionally, WebAssembly definitely needs to be parsed. See: https://github.com/WebKit/webkit/blob/master/Source/JavaScri... and https://github.com/WebKit/webkit/blob/master/Source/JavaScri...

Granted, that's simpler than parsing JavaScript.

For reference, the current GC proposal is here: 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.

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

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?

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

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.

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.

Just look at Go binaries. They include all the standard library modules that they use. A typical "Hello World" in Golang compiles to around 1-1.5 MB (and that's after you strip debug info).

> Nothing prevents one to implement a GC on top of existing WebAssembly as it is

Except that efficient GC implementations use concurrency with a shared memory space and locking and memory-barrier instructions that are not yet available in WASM. (AFAIK, please prove me wrong)

Correct, shared memory and atomics are likely the first big post-MVP feature: https://github.com/WebAssembly/threads/blob/master/proposals...

Those operations are not available in all hardware architectures anyway, and they surely weren't even common before processors went multi-core.

So GC were implemented within those constraints, which means it is possible to do within the current state, even if it isn't the most optimal one versus the availabilities of such CPU features.

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

WebKit has a fast JS parser. I don't think this would be true for us.

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

Link to repro?

not open source. but start with angular 4 hello world. that takes a little while to parse, too.

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

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

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.

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

I agree.

Chakra uses a pure JIT approach? I thought they interpret both in JS and Wasm?

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.

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.

V8 used to do this. Now they have a JS interpreter called Ignition.

> V8 always produces machine code when running JS IIRC.

They used to. They stopped doing that because it made initial load too slow...

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

See here: https://news.ycombinator.com/item?id=14501262 Proposal: https://github.com/WebAssembly/gc/blob/master/proposals/gc/O...

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

No worries! It's all non-obvious :-) Yes GC == Garbage Collection.

Reply on news.ycombinator.com