Assembling WebAssembly
webkit.org
Assembling WebAssembly
1–10 of 91 posts
Re: Assembling WebAssembly
#2Summarizing the "JSC https://news.ycombinator.com/item?id=14489577
Now that these points are out of the way, let's discuss implementation details, WebAssembly, and things!
Re: Assembling WebAssembly
#3I 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.
Re: Assembling WebAssembly
#4I 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.
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 .
- 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.
Re: Assembling WebAssembly
#5> 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"?
Re: Assembling WebAssembly
#6> 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"?
WTF stands for Web Template Framework. BBQ and OMG both use it.
Re: Assembling WebAssembly
#7I 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.
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 . - 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…
> 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?
Re: Assembling WebAssembly
#8I 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.
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 . - 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…
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...
Re: Assembling WebAssembly
#9I 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.
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 . - 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…
> - 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 .
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.
Re: Assembling WebAssembly
#10Earlier quoted context omitted.
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 . - 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…
> 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?).