10 ms·

I know this is tangental, but will WASM ever get the ability to manipulate the DOM? And will JavaScript as we know it survive if it does? All these people buil

I know this is tangental, but will WASM ever get the ability to manipulate the DOM? And will JavaScript as we know it survive if it does? All these people building JavaScript tooling in other languages would probably be so happy if there was no need for tooling in the first place.

tabtab 4y ago
That would probably expose it to so many security concerns that it would face a similar fate as Java applets & Flash: causing more hacking/snooping than benefits for a typical browser user. And I can't get a consistent answer on what problem WASM is trying to solve.
- ihatepython 4y ago
  Obfuscation? Job security?
- NoahKAndrews 4y ago
  The problem with Flash and Java was that they were not integrated with the browser's sandbox. WASM is integrated with the sandbox. How would allowing DOM access be insecure? The DOM is designed to be completely controlled by the webpage. I don't see how adding an additional way for the webpage to do so adds any insecurity.
  - satvikpendem 4y ago
    Indeed, as if sites today already can't snoop with JS instead of WASM.
    - tabtab 4y ago
      Why offer TWO snoop vectors? And crypto miners would target WASM over JS, giving WASM a bad name.
  - pjmlp 4y ago
    Yet, one can still compile Heartbleed into a WASM module. It adds more ways to sneak unwanted code into the page or do cross execution that shouldn't happen in first place, while staying inside the sandbox.
- nine_k 4y ago
  WASM neatly solves a pretty common problem of running code that can't be easily ported to JS inside the browser. It also sort of solves a common problem of running untrusted code, both in browser or on server, because WASM VMs are much more isolated and restricted.
  - pjmlp 4y ago
    Just like plenty of other bytecode environments since 1961.
    - nine_k 4y ago
      Javascript is a language like many since 1961, too, and not the best of them; it has the unique advantage of having been universally implemented and deployed already. Same thing with WASM. JVM never achieved this level of penetration, and Flash allowed way too much access to ever be secured.
      - pjmlp 4y ago
        Great that we have WASM then, https://leaningtech.com/cheerpj/ https://leaningtech.com/cheerpj/ https://leaningtech.com/cheerpj-applet-runner/ https://leaningtech.com/cheerpj-applet-runner/ https://leaningtech.com/cheerpx-for-flash/ https://leaningtech.com/cheerpx-for-flash/ And in regards to "security", https://training.linuxfoundation.org/blog/webassembly-security-now-and-in-the-future/ https://training.linuxfoundation.org/blog/webassembly-securi...
junon 4y ago
WASM can already manipulate the DOM.
afavour 4y ago
> And will JavaScript as we know it survive if it does? IMO yes, for two reasons: 1. a lot of people like coding in JS! I know, anathema. But having coded in both JS and Rust I know which one is going to be more acceptable to the largest audience of developers. There's a reason Node got as popular as it has. 2. libraries. I'm sure there will be plenty of people doing DOM manipulation via WASM but if there are going to be a limited number of libraries you can pull off the shelf to do it. By comparison JS is always going to have a ton (arguably too many, but still). But I'm sure Microsoft won't be able to resist raising the ghost of WebForms to make something that actually does run .NET in the browser.
deleted 4y ago
[deleted]
kevincox 4y ago
I am fairly certain the answer is "Yes". The DOM and other APIs have well-defined interfaces so it would likely be reasonable to wholesale export those to WASM. If the timeframe is "ever" the answer is "yes". However I don't think it will be soon. I think the current biggest question is how garbage collection works with WASM. DOM nodes and many other resources are garbage collected. You need to define how WASM interfaces with that. (Does every object just get reference counted when passed to WASM and require an explicit free? Is there some sort of GC that traces over WASM memory?).
postalrat 4y ago
WASM can manipulate the DOM. You just need a bit of javascript glue that you don't need to worry about.
- pjmlp 4y ago
  You will worry about it on the profiler.

tabtab 4y ago

That would probably expose it to so many security concerns that it would face a similar fate as Java applets & Flash: causing more hacking/snooping than benefits for a typical browser user. And I can't get a consistent answer on what problem WASM is trying to solve.

ihatepython 4y ago
Obfuscation? Job security?
NoahKAndrews 4y ago
The problem with Flash and Java was that they were not integrated with the browser's sandbox. WASM is integrated with the sandbox. How would allowing DOM access be insecure? The DOM is designed to be completely controlled by the webpage. I don't see how adding an additional way for the webpage to do so adds any insecurity.
- satvikpendem 4y ago
  Indeed, as if sites today already can't snoop with JS instead of WASM.
  - tabtab 4y ago
    Why offer TWO snoop vectors? And crypto miners would target WASM over JS, giving WASM a bad name.
- pjmlp 4y ago
  Yet, one can still compile Heartbleed into a WASM module. It adds more ways to sneak unwanted code into the page or do cross execution that shouldn't happen in first place, while staying inside the sandbox.
nine_k 4y ago
WASM neatly solves a pretty common problem of running code that can't be easily ported to JS inside the browser. It also sort of solves a common problem of running untrusted code, both in browser or on server, because WASM VMs are much more isolated and restricted.
- pjmlp 4y ago
  Just like plenty of other bytecode environments since 1961.
  - nine_k 4y ago
    Javascript is a language like many since 1961, too, and not the best of them; it has the unique advantage of having been universally implemented and deployed already. Same thing with WASM. JVM never achieved this level of penetration, and Flash allowed way too much access to ever be secured.
    - pjmlp 4y ago
      Great that we have WASM then, https://leaningtech.com/cheerpj/ https://leaningtech.com/cheerpj/ https://leaningtech.com/cheerpj-applet-runner/ https://leaningtech.com/cheerpj-applet-runner/ https://leaningtech.com/cheerpx-for-flash/ https://leaningtech.com/cheerpx-for-flash/ And in regards to "security", https://training.linuxfoundation.org/blog/webassembly-security-now-and-in-the-future/ https://training.linuxfoundation.org/blog/webassembly-securi...

junon 4y ago

WASM can already manipulate the DOM.

afavour 4y ago

> And will JavaScript as we know it survive if it does? IMO yes, for two reasons: 1. a lot of people like coding in JS! I know, anathema. But having coded in both JS and Rust I know which one is going to be more acceptable to the largest audience of developers. There's a reason Node got as popular as it has. 2. libraries. I'm sure there will be plenty of people doing DOM manipulation via WASM but if there are going to be a limited number of libraries you can pull off the shelf to do it. By comparison JS is always going to have a ton (arguably too many, but still). But I'm sure Microsoft won't be able to resist raising the ghost of WebForms to make something that actually does run .NET in the browser.

deleted 4y ago

[deleted]

kevincox 4y ago

I am fairly certain the answer is "Yes". The DOM and other APIs have well-defined interfaces so it would likely be reasonable to wholesale export those to WASM. If the timeframe is "ever" the answer is "yes". However I don't think it will be soon. I think the current biggest question is how garbage collection works with WASM. DOM nodes and many other resources are garbage collected. You need to define how WASM interfaces with that. (Does every object just get reference counted when passed to WASM and require an explicit free? Is there some sort of GC that traces over WASM memory?).

postalrat 4y ago

WASM can manipulate the DOM. You just need a bit of javascript glue that you don't need to worry about.

pjmlp 4y ago
You will worry about it on the profiler.