6 ms·

WASM doesn't have access to the DOM, or a GC, or very easy interop with JavaScript, so the answer is mostly "no".

stupidcar 10y ago
All that is planned though, just not for the MVP: https://github.com/WebAssembly/design/blob/master/GC.md https://github.com/WebAssembly/design/blob/master/GC.md
- mintplant 10y ago
  No idea why you've been downvoted. I'm interning at Mozilla right and as that design document says, GC and DOM access for WASM are very much on people's radar - they just won't make it into the initial roll-out.
warbiscuit 10y ago
I hope DOM access comes very close on the heels of the initial design... Javascript is an interesting language (particularly after it's recent revival), but IMO it's recent jumpstart would never have happened if it weren't for one killer feature: access to the HTML DOM. People would (and have) forgiven many other things, just for the utility of that as the presentation layer. I certainly would have picked up whatever language the browsers were pushing, where DOM access was a requirement. Conversely, I remember trying to get java applets to interact with HTML -- you have to message things through a tiny hole to/from javascript; which was (one of the many) things which made everyone hate java applets.
- megalodon 10y ago
  I just hope that when it happens we will be able to view and read the source of WASM in the same way we can with javascript now. This is one of the foundations of WWW, please don't turn it into a closed source app store.
  - gsnedders 10y ago
    We lost that years ago with minification. Source maps can work as well for WASM as they can for minified JS.
    - kuschku 10y ago
      Then make browsers require full source maps for every website, or refuse to run them. That’d be finally a solution. Or require source maps by law. EDIT: Why the downvotes? The only way to preserve the right to modify and decompile in the long term is by creating technical or legal measures enforcing it. JS was one technical measure, so now we need alternatives.
      - jfbastien 10y ago
        That would be awfully slow to transfer (or just verify) when most people never view the source map. What's a "valid" source map anyways? Furthermore, debugging with sourcemaps is suboptimal. WebAssembly wants to support much better debug information than this.
        gsnedders 10y ago
        And it'd imply you need a source map even with unminified JS. And what's to say the source map maps to non-minified JS?
        kuschku 10y ago
        It’s not about debugging, it’s about the legal "right to decompile", which is intended to give customers and companies the right to take apart products and software they bought (even from competitors), and gain knowledge from that. It’s also intended to allow them to modify it for their own purposes, and provide the modifications to others who have a license to the original product. Especially on the web this was finally possible, and now you’re suggesting to take this away again?
        rabbitfang48 10y ago
- comex 10y ago
  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.
  - pcwalton 10y ago
    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.)
    - bluejekyll 10y ago
      How does that differ from today? Don't all rendering engines have to deal with that GC now?
- kabes 10y ago
  Step 1) Replace the 2d library of your desktop GUI language to draw using HTML canvas API. Step 2) Compile to wasm No need for the DOM anymore... (not saying it's a better approach, but it is technically possible).
supster 10y ago
If there is no GC, could a language like Rust or Swift still target WASM?
- steveklabnik 10y ago
  We plan on having Rust target webassembly, and there's already basic support for doing so.
  - brett40324 10y ago
    Where can I learn more about this basic support? There's the next full stack paradigm right there. I give it two years, and it will be called rustic-asm framework...
    - steveklabnik 10y ago
      https://github.com/brson/mir2wasm https://github.com/brson/mir2wasm It's still very early, and there's other avenues as well: an LLVM backend, for example.
      - brett40324 10y ago
        Cool, i appreciate the link.
    - fizzbatter 10y ago
      haha :D. I also have plans for a Rust web framework. Nothing fancy, and it will likely suck, but it's a dream :)
- PudgePacket 10y ago
  Rust doesn't use a GC, so it should be fine. Is that what you meant ?
- DasIch 10y ago
  Languages that don't require a GC would be fine to begin with, other languages would have to implement a GC in WASM.
supster 10y ago
If there is no GC, could a language like Rust or Swift still target WASM?
fizzbatter 10y ago
DOM and GC are on the plan list thought, fwiw. It will, as far as the planning is concerned.

All that is planned though, just not for the MVP: https://github.com/WebAssembly/design/blob/master/GC.md https://github.com/WebAssembly/design/blob/master/GC.md

mintplant 10y ago
No idea why you've been downvoted. I'm interning at Mozilla right and as that design document says, GC and DOM access for WASM are very much on people's radar - they just won't make it into the initial roll-out.

warbiscuit 10y ago

I hope DOM access comes very close on the heels of the initial design... Javascript is an interesting language (particularly after it's recent revival), but IMO it's recent jumpstart would never have happened if it weren't for one killer feature: access to the HTML DOM. People would (and have) forgiven many other things, just for the utility of that as the presentation layer. I certainly would have picked up whatever language the browsers were pushing, where DOM access was a requirement. Conversely, I remember trying to get java applets to interact with HTML -- you have to message things through a tiny hole to/from javascript; which was (one of the many) things which made everyone hate java applets.

megalodon 10y ago
I just hope that when it happens we will be able to view and read the source of WASM in the same way we can with javascript now. This is one of the foundations of WWW, please don't turn it into a closed source app store.
- gsnedders 10y ago
  We lost that years ago with minification. Source maps can work as well for WASM as they can for minified JS.
  - kuschku 10y ago
    Then make browsers require full source maps for every website, or refuse to run them. That’d be finally a solution. Or require source maps by law. EDIT: Why the downvotes? The only way to preserve the right to modify and decompile in the long term is by creating technical or legal measures enforcing it. JS was one technical measure, so now we need alternatives.
    - jfbastien 10y ago
      That would be awfully slow to transfer (or just verify) when most people never view the source map. What's a "valid" source map anyways? Furthermore, debugging with sourcemaps is suboptimal. WebAssembly wants to support much better debug information than this.
      - gsnedders 10y ago
        And it'd imply you need a source map even with unminified JS. And what's to say the source map maps to non-minified JS?
      - kuschku 10y ago
        It’s not about debugging, it’s about the legal "right to decompile", which is intended to give customers and companies the right to take apart products and software they bought (even from competitors), and gain knowledge from that. It’s also intended to allow them to modify it for their own purposes, and provide the modifications to others who have a license to the original product. Especially on the web this was finally possible, and now you’re suggesting to take this away again?
        rabbitfang48 10y ago
comex 10y ago
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.
- pcwalton 10y ago
  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.)
  - bluejekyll 10y ago
    How does that differ from today? Don't all rendering engines have to deal with that GC now?
kabes 10y ago
Step 1) Replace the 2d library of your desktop GUI language to draw using HTML canvas API. Step 2) Compile to wasm No need for the DOM anymore... (not saying it's a better approach, but it is technically possible).

supster 10y ago

If there is no GC, could a language like Rust or Swift still target WASM?

steveklabnik 10y ago
We plan on having Rust target webassembly, and there's already basic support for doing so.
- brett40324 10y ago
  Where can I learn more about this basic support? There's the next full stack paradigm right there. I give it two years, and it will be called rustic-asm framework...
  - steveklabnik 10y ago
    https://github.com/brson/mir2wasm https://github.com/brson/mir2wasm It's still very early, and there's other avenues as well: an LLVM backend, for example.
    - brett40324 10y ago
      Cool, i appreciate the link.
  - fizzbatter 10y ago
    haha :D. I also have plans for a Rust web framework. Nothing fancy, and it will likely suck, but it's a dream :)
PudgePacket 10y ago
Rust doesn't use a GC, so it should be fine. Is that what you meant ?
DasIch 10y ago
Languages that don't require a GC would be fine to begin with, other languages would have to implement a GC in WASM.

supster 10y ago

If there is no GC, could a language like Rust or Swift still target WASM?

fizzbatter 10y ago

DOM and GC are on the plan list thought, fwiw. It will, as far as the planning is concerned.