4 ms·

My question is when will web assembly able to access the DOM without the need to call Javascript to jump back and forth.

flohofwoe 4y ago
That's how all browser APIs are accessed from WASM, the DOM is nothing special in that regard. The only way for WASM to interact with the 'outside world' is through import and export function tables, and at least in the browser all functions in the import table will be Javascript functions. The only alternative would be for all browser Javascript APIs to get a separate "native C-like API" which could be plugged into the WASM import table and circumvent Javascript. That's basically how NaCl worked, with the downside that it only exposed a very small slice of browser APIs, for everything else one had to interact with Javascript via messaging, and this was a massively royal PITA. WASM does everything right in that regard.
kitkat_new 4y ago
it's less important than you probably think: https://news.ycombinator.com/edit?id=35240914 https://news.ycombinator.com/edit?id=35240914
moffkalast 4y ago
Isn't Wasm just stuff transpiled to javascript and then pre-interpreted to bytecode anyway? The ole' Emscripten console port.
- deathanatos 4y ago
  No. WASM is its own byte-code, which can be either interpreted directly, or JIT'd to machine code. There's no transpile to JS step. (There's a text representation too.)
  - moffkalast 4y ago
    Wait was that asm.js then? It's so confusing, I swear that each time I check I find people claiming different things about this.
    - lxgr 4y ago
      asm.js is something of a spiritual predecessor to WASM. The neat thing about it is that it's both syntactically and semantically valid JavaScript, but also compiles to native code much more directly than JavaScript generally does. WASM is essentially a successor to asm.js that is not valid JavaScript anymore – browsers do need to provide a different runtime for it. I believe some early WASM runtimes did reuse parts of their JS stack for JIT compilation, but I believe this is no longer the case, since WASM can efficiently be AOT compiled (unlike JS, which does need the JIT to be efficient due to its much more liberal type system, among other things).
rektide 4y ago
This depends chiefly on the component-model work shipping. https://github.com/WebAssembly/component-model https://github.com/WebAssembly/component-model At the heart is an longstanding wasm "interface types" idea (WIT), defined by a IDL, https://github.com/WebAssembly/component-model/blob/main/design/mvp/WIT.md https://github.com/WebAssembly/component-model/blob/main/des... Once we know how bits of wasm talk to each other we can have browsers expose web platform "host objects" via this standard inter-module means. While an interesting topic to most app developers, this is pretty off-topic for language nerds. It will greatly level implementations when it becomes available, as opposed to those willing to pour in enormous effort writing their own serializing bridges... but it doesnt really alter what the language can do and how it will work in wasm. This talk is, to me, more about languages. WIT & host objects will be an enormous boom but they overall won't much affect language design.
- syrusakbary 4y ago
  I disagree that the component Model or WebAssembly Interfaces (WAI) is what holds a standardization to the DOM access from Wasm. All those things can already be done via WebIDL (and in fact, is the standard that wasm-bindgen in Rust already uses to generate the Rust bindings)
  - deleted 4y ago
    [deleted]
  - rektide 4y ago
    None of that is standard though. wasm-bindgen goes away after this. Objects just become usable directly. wasm-bindgen is a monstrously complex layer, and it doesn't allow wasm direct access to the DOM. It very cleverly installs a complex bridge that translates on the fly between js and wasm, making wasm think it has transparent access, but it's quite clear if you actually start debugging what's happening in the browser, there is a huge middle layer of code wasm-bindgen has built for you to present that illusion. And again, none of it is standard. There I think may be a creative language or two who has built atop Rust's painstaking cross-serialization... but these techniques are far from standard. The actual standard makes a raft of these ugly unsightly slow intermediary translation layers go away. It makes an actual standard for cross language communication. Not just rust<->js, but rust<->go or scheme<->f# or whatever else.

flohofwoe 4y ago

That's how all browser APIs are accessed from WASM, the DOM is nothing special in that regard. The only way for WASM to interact with the 'outside world' is through import and export function tables, and at least in the browser all functions in the import table will be Javascript functions. The only alternative would be for all browser Javascript APIs to get a separate "native C-like API" which could be plugged into the WASM import table and circumvent Javascript. That's basically how NaCl worked, with the downside that it only exposed a very small slice of browser APIs, for everything else one had to interact with Javascript via messaging, and this was a massively royal PITA. WASM does everything right in that regard.

kitkat_new 4y ago

it's less important than you probably think: https://news.ycombinator.com/edit?id=35240914 https://news.ycombinator.com/edit?id=35240914

moffkalast 4y ago

Isn't Wasm just stuff transpiled to javascript and then pre-interpreted to bytecode anyway? The ole' Emscripten console port.

deathanatos 4y ago
No. WASM is its own byte-code, which can be either interpreted directly, or JIT'd to machine code. There's no transpile to JS step. (There's a text representation too.)
- moffkalast 4y ago
  Wait was that asm.js then? It's so confusing, I swear that each time I check I find people claiming different things about this.
  - lxgr 4y ago
    asm.js is something of a spiritual predecessor to WASM. The neat thing about it is that it's both syntactically and semantically valid JavaScript, but also compiles to native code much more directly than JavaScript generally does. WASM is essentially a successor to asm.js that is not valid JavaScript anymore – browsers do need to provide a different runtime for it. I believe some early WASM runtimes did reuse parts of their JS stack for JIT compilation, but I believe this is no longer the case, since WASM can efficiently be AOT compiled (unlike JS, which does need the JIT to be efficient due to its much more liberal type system, among other things).

rektide 4y ago

This depends chiefly on the component-model work shipping. https://github.com/WebAssembly/component-model https://github.com/WebAssembly/component-model At the heart is an longstanding wasm "interface types" idea (WIT), defined by a IDL, https://github.com/WebAssembly/component-model/blob/main/design/mvp/WIT.md https://github.com/WebAssembly/component-model/blob/main/des... Once we know how bits of wasm talk to each other we can have browsers expose web platform "host objects" via this standard inter-module means. While an interesting topic to most app developers, this is pretty off-topic for language nerds. It will greatly level implementations when it becomes available, as opposed to those willing to pour in enormous effort writing their own serializing bridges... but it doesnt really alter what the language can do and how it will work in wasm. This talk is, to me, more about languages. WIT & host objects will be an enormous boom but they overall won't much affect language design.

syrusakbary 4y ago
I disagree that the component Model or WebAssembly Interfaces (WAI) is what holds a standardization to the DOM access from Wasm. All those things can already be done via WebIDL (and in fact, is the standard that wasm-bindgen in Rust already uses to generate the Rust bindings)
- deleted 4y ago
  [deleted]
- rektide 4y ago
  None of that is standard though. wasm-bindgen goes away after this. Objects just become usable directly. wasm-bindgen is a monstrously complex layer, and it doesn't allow wasm direct access to the DOM. It very cleverly installs a complex bridge that translates on the fly between js and wasm, making wasm think it has transparent access, but it's quite clear if you actually start debugging what's happening in the browser, there is a huge middle layer of code wasm-bindgen has built for you to present that illusion. And again, none of it is standard. There I think may be a creative language or two who has built atop Rust's painstaking cross-serialization... but these techniques are far from standard. The actual standard makes a raft of these ugly unsightly slow intermediary translation layers go away. It makes an actual standard for cross language communication. Not just rust<->js, but rust<->go or scheme<->f# or whatever else.