Earlier 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…
What would it take to give WebAssembly access to the DOM?
Assembling WebAssembly
31–40 of 91 posts
Re: Assembling WebAssembly
#32When will this come to mobile devices?
Re: Assembling WebAssembly
#33When is this coming to iOS though?
I think chrome for mobile already has it?
Re: Assembling WebAssembly
#34Earlier quoted context omitted.
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
Re: Assembling WebAssembly
#35I 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.
Re: Assembling WebAssembly
#36Earlier quoted context omitted.
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.
Re: Assembling WebAssembly
#37I 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.
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.
Re: Assembling WebAssembly
#38Man, 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.
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.
Re: Assembling WebAssembly
#39Man, 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.
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 promisin…
Where does even the 2x come from? Currently it looks very much like 1x vs integer hinted JS code like generated by asm.js.
Re: Assembling WebAssembly
#40Earlier quoted context omitted.
> - 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 somethi…
> 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 a…
> 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...