WASM doesn't need DOM access. You can just implement a browser in WASM and target canvas. I'm really surprised somebody hasn't done this already and marketed it as an unblockable ad delivery platform.
You can be certain that, when this does happen, these considerations will be dealt with. I feel very strongly that this is going to happen. The chance to execute arbitrary code on clients will be too alluring for adtech companies to ignore.
For accessibility compliance, you _need_ text and a DOM. Screen readers rely on HTML element semantics, ARIA attributes, and text content. The only way to make a canvas element (which is what you'd typically need to render custom UI) accessible is to have a textual fallback.
Outside accessibility there's also the issue of responsive design, huge SEO impacts, rendering performance... I'm probably missing a bunch.
Lifting a sedan with my bare hands is obviously easier than lifting a 10 wheeler, but it's still a massive problem. Rendering stuff is not the biggest issue.
Embed a browser with all that stuff into a page. Whatever APIs are missing to make the "inner browser" unable to fulfill all the requirements that the "outer browser" will eventually be filled-in by well-meaning developers who want the Javascript VM in the "outer browser" to be able to host general purpose applications.
You won't be able to block the binary, because the binary will be what renders the content. Your browser is going to act as a VM to run a browser that will display the content. The "inner" browser will be running on your computer, but short of binary reverse engineering, you won't be able to control it.
> Your browser is going to act as a VM to run a browser that will display the content.
Gary Bernhardt's talk "The Birth & Death of JavaScript"[1] was an ominous portent of a terrifying future. Unfortunately, some people apparently saw it as development roadmap.
Functionally, nothing. WASM being a compiler target just lowers the bar (although we've had Emscripten for years). The browser developers are working hard to make it performant, too. Sufficiently obfuscated Javascript is as difficult to reverse engineer as a binary, though.
I don't do web, but I imagine there must be some webpack plugins that make an obfuscated mess out of your code, so the barrier to entry must already be quite low.
WASM at least is standardized, so there will be a whole ecosystem dedicated to it. Think IDA Pro for WASM.
> although we've had Emscripten for years
We did. And I didn't see the "asm.js apocalypse" you seem to fear.
I don't "fear" an "asm.js apocalypse". It's just the next step in the arms race between those who would have the Internet be like television, and those who would prefer it not. I'm one of the people who would have rather had the web stay more like Gopher and less like Java, but that's not the predominant opinion. We're going to lose the document-oriented declarative web because the web is financed by advertising. The spice must flow-- the ads must not be allowed to be blocked.
WASM is different between Emscripten was always a fun curiosity, and WASM is being "marketed" to developers as "get native app performance in a browser". "Modern" Javascript has been able to deliver this future for a few years now, but it lacked the marketing and tooling to make it mainstream. Flash and Java were attempts to move to that future that didn't pan out.
Having IDA Pro for WASM is all well and good, but doing binary reverse engineering on every single website isn't practical.
The web, as it has been, was nice. We're not going to get to keep it. I'm unhappy with it, but I'm resigned to it.
Take Facebook or Gmail. Last time I looked -- a couple of years ago -- Facebook served some 18 MB of JavaScript. I imagine it's not hand-written, but compiled from ReasonML and whatever other languages they're using. There's nothing nice in that, it's a mess. You can't crack open Developer Tools and figure out how the timeline updates when you scroll. You can't figure out where the ads are inserted into the DOM.
So WASM doesn't take away anything from us, because we haven't had the "nice" you mention for 10 or 15 years. Sites like HN will stay like this, sites like Facebook will get even bigger. It will happen with or without WASM.
But yes, I do see where you're coming from. You want a less bloated Web, and you're worried that WASM is not going to lead to that, which I pretty much agree with. While I'm saying that cat is already out of the bag and WASM at least has the potential to bring performance improvements over JavaScript (which will be promptly negated by the sites getting even more bloated).
The cat absolutely is out of the bag. It has been. I'm not railing against WASM.
I want a declarative web. I wish there wasn't a VM in my browser. I want a web where my user agent, under my control, dictates how documents are interpreted and displayed.
So much of information security relies on not letting third parties execute arbitrary code on your computer. The price to view "mainstream" websites is increasingly becoming "allow third parties to execute arbitrary code on your computer". I can sandbox that code and perhaps limit the impact to my privacy (though thanks to processor microarchitecture "features" that's increasingly difficult), but I lose virtually all ability to control the presentation experience.
To be blunt: The kind of assholes that delighted in using Javascript to block opening context menus, blocking "Paste" into password fields, etc, have won. That pisses me off. Developers with good intentions who wanted to make something "cool" end up being the architects of the tools that will be used turn the web into cable TV.
