News for hackers. Stuff that matters.

A comment on WebAssembly Specification Prototype. Parent comment

Re:WebAssembly Specification Prototype by comex on Wednesday July 13, 2016 @04:34PM (#12089458)
It depends what you mean by "access". The MVP won't have direct DOM access, but it's not really necessary. WebAssembly code can synchronously and efficiently call JavaScript functions (with numeric arguments), so it should be pretty easy to write a WebIDL-based stub generator to provide natural syntax for calling DOM functions from any given compiled language, with a little JavaScript stub on the other end. A future spec might make things more efficient by providing direct access, but it's really a micro-optimization.
[ Parent | on HN ]
Re:WebAssembly Specification Prototype by pcwalton on Wednesday July 13, 2016 @06:50PM (#12090336)
Well, the tricky part is not getting the basic FFI to work but getting the memory management right. Making sure that DOM nodes that are not part of the document stay alive and that dead nodes die is the hard part, especially if JS/wasm cycles are involved.

(This is not a criticism of wasm, by the way. It's merely motivating potential future GC extensions to the spec.)

[ Parent | on HN ]
Re:WebAssembly Specification Prototype by bluejekyll on Wednesday July 13, 2016 @09:03PM (#12091013)
How does that differ from today? Don't all rendering engines have to deal with that GC now?
[ Parent | on HN ]