Can WebAssembly make HTTP request invisible to the browser?

It doesn't need to. Don't think about it as documents being delivered to the browser anymore. Think of it as a binary executing inside the browser. You're not going to have HTTP requests to block, apart from the one that downloads the binary.

A minified JavaScript bundle is just slightly less obscure than a WebAssembly binary though.

Absolutely. I'm not railing against WASM. WASM just has better marketing and tooling than straight Javascript.

Putting a VM into our browsers, along with sufficient API support to make that VM useful, is what spells the eventual end of the document-based web. I think that future arrived a few years ago and it's just not evenly distributed yet.

>the eventual end of the document-based web

That sounds like the worst future possible. I love the fact that I can go to any web page and look at all of the HTML, CSS, JS (even if I need to use a tool to un-obfuscate it). Have you never wondered how someone did something and then looked at their code to find out how they did it? I love being able to use curl and wget to grab a web page. How would that work in a non document-based web? I really think this would be a terrible thing if it actually came to fruition. I truly hope I'm retired or dead before it occurs.

That's already an issue with minified JavaScript. Can we still call minified JavaScript "Web" ? What about non-minified JavaScript?

WASM doesn't have DOM access (yet).

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.

How many accessibility laws does this violate? Does it work with a screen reader?

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.

"Dealing with it" basically means re-building a browser rendering engine inside the browser renderer.

You don't need to build a browser rendering engine, with everything that entails; you only need to render your content. This is a much easier problem.

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.

How big of a WASM binary would that be? Can we block WASM binaries that are over a certain size in the browser?

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.

[1] https://www.destroyallsoftware.com/talks/the-birth-and-death...

You can already do that in JavaScript, what's the difference?

You can even implement a WASM interpreter in JS.

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.

> blocking "Paste" into password fields

Change your `dom.event.clipboardevents.enabled` in about:config to false.

those two would be easy blocks: the canvas showing the ad, and the wasm payload for that to happen

Except the content is mixed into the WASM payload...

That is interesting. I didn't realize WASM was designed to be so constrained.