Still infinitely better than WASM blobs where everything is painted on a canvas, which is un-adblockable. The experience will also be hellish, because every website will ship a 10 MB blob of half-baked things that your browser already does a million-times better out of the box. And for what? Because people think it will be faster (it won't).
The experience will probably be hellish anyway because of the Web integrity API. Javascript compiled to asm.js could produce painted-to-canvas websites too, and it won't be any less viable especially considering the growth of the CPU scores. Webassembly is prevalent in the canvas use cases because DOM manipulation with it is slower, clunky(due to the poor browser integration) and because people want to reuse native-language codebases.
If the canvas website really was a threat we would have seen much more of it by now already, but it hasn't happened for a number of reasons -- we only see them in the dedicated desktop-app-like use cases like this one. Anything scrollable won't be viable because it would be inherently less responsive than the real deal. Fonts look different, most designers actually prefer for people to be able to select text, and be able to use browser functionality that looks native for the different OSs. Canvas websites are also more expensive in terms of blob loading and ability to cache pages. So it's not really a threat.
Most adblocking happens by the means of network/URL blocking and I don't see any potential difference between WASM and JS in this regard(unless the APIs are enshittified, but JS isn't impervious to this too). If ads can't be blocked by network, and the website proxies ad contents through its own domain(as far as I know that's not prevalent, maybe I'm ignorant -- they need to track users and clicks themselves anyway), than you could get hard to block websites with JS+DOM too -- it's possible disrupt DOM based blocking by frequent randomization/obfuscation to the degree that one would need some kind of advanced AI to even hope to find the ad DOM elements. Between WEI, web bundles, Topics API push, webassembly's supposed higher indecipherability (which isn't true, chrome "disassembles" WASM into the WAT form and it's pretty readable. More readable than wasm.js) doesn't even register.
>And for what?
To not deal with JavaScript? To be able to develop for the web in the language you want, without floats being the fundamental numeric type and other BS? Is that too fantastical of a desire?
One day I'd love to compile part of Chromium's rendering into a WASM module. In my imaginary world, people just make html+js+css pages using the "firefox.wasm", "chromium.wasm", whatever rendering engine of their preference, and browsers just become wasm players. They can even expose APIs to support local fonts and whatever else browsers need today. I realize that's far-fetched given the sheer amount of rendering optimization Chromium has done just to work on all the hardware, graphics APIs, and platforms they support. But this is honestly one of the reasons I wanted to port our engine to pure WASM. I wanted to see what a minimal API would look like for a full game editor (not just engine!) that a browser would have to expose with basic graphics and audio. It's a lot smaller than I expected, and side note... Emscripten did a great job of hiding all those details! WASI has made huge strides in getting OS level APIs exposed to WASM, but it's mostly headless stuff, not really a focus on GUIs or audio yet. I'm sure proposals exist, but the speed of getting these mainstream is slow because I'm sure they want to get it right. I'm hoping this engine can serve as an example for what we need from WASI to start making this possible.
And I'm sure this fictional browser could find a way to make ad-blocking plugins that analyze network traffic and decompile wasms to scan for whatever using the latest AI magic :P
I was sceptical WASM is ever going to be mainstream, but after reading your post I'm convinced it's the future. This sound like advertiser dream, and adds already rule the internet, so the conclusion is obvious