Hacker News Reader

Comment by Buttons840 | Hacker News Reader

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.

View on HN

> 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.

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?).

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.

Obfuscation? Job security?

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.

Indeed, as if sites today already can't snoop with JS instead of WASM.

Why offer TWO snoop vectors? And crypto miners would target WASM over JS, giving WASM a bad name.

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.

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.

Just like plenty of other bytecode environments since 1961.

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.

Great that we have WASM then,

https://leaningtech.com/cheerpj/

https://leaningtech.com/cheerpj-applet-runner/

https://leaningtech.com/cheerpx-for-flash/

And in regards to "security",

https://training.linuxfoundation.org/blog/webassembly-securi...

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

You will worry about it on the profiler.

WASM can already manipulate the DOM.

Reply on news.ycombinator.com