Re:Doom 3 in WebAssembly
by tyingq on Thursday January 03, 2019 @04:12PM
(#18819316)
The WASM folks have plans to deepen the browser ties with direct DOM access, tying threads to webworkers, GC that's tied to the browser js, etc. I can see why you want what you do, but it will get harder over time.
[ Parent
| on HN ]
Re:Doom 3 in WebAssembly
by neurotrace on Thursday January 03, 2019 @04:54PM
(#18819685)
That's not quite true. They intend to create a way of interfacing with ANY GC which would then allow them to make APIs that call in to the DOM. None of this would tie it directly to browsers. The whole intent is to keep it platform-agnostic, last I heard.
> An important constraint is that, while WebAssembly should allow tight integration with the Web, it should not bake in details or Web standards dependencies that prevent execution in a non-Web embedding. This suggests a design (called opaque reference types below) that hides the details of JavaScript and WebIDL behind Web-embedding-specific builtin modules. On the other hand, WebAssembly can define a set of native GC primitives that allowed portable GC code to be written regardless of the host environment.
That's encouraging. As far as I can tell, threading is currently webworker centric.
Re:Doom 3 in WebAssembly
by rafaelvasco on Thursday January 03, 2019 @04:19PM
(#18819378)
Unfortunate.