3 ms·
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 wou
by neurotrace 8y ago
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.
https://github.com/WebAssembly/proposals/issues/16 https://github.com/WebAssembly/proposals/issues/16
- tyingq 8y agoThat's encouraging. As far as I can tell, threading is currently webworker centric.