Hacker News Reader

Comment by EvanAnderson | Hacker News Reader

I envision horrible "all WASM" websites, just like the old "all Flash" websites, that won't have accessibility, won't be able to be linked to, etc. Worse, I envision this as being another step in the ad blocker arms race. Inevitably there are going to be websites that package an entire WASM-based browser that will need to be used to access the site, nullifying client-side ad and script blockers. I can see the pitch now-- "Keep your existing website but add our tools to prevent ad blockers!"

(Edit: Typos. I should know better than to post from my phone by now. Grrr...)

View on HN

This is a criticism that would be more suited to the Canvas API than the WASM API. WASM is still meant to drive the DOM API which is still as introspectable as before.

[EDIT]: Steve is right of course, and I misspoke here, "WASM is still able to drive the DOM" is closer to what I meant to say.

I agree with your first sentence, but not your second: wasm is meant to access all platform APIs, not just the DOM ones. Canvas is part of the platform as well.

I think we will start to see a lot of all-in-one frameworks that use wasm for constraint based layouts so people don't have to learn CSS. I hope I'm wrong but I can definitely imagine something like this coming from the enterprise java/.net types.

I sure hope we do. CSS has had 20 years and is still the most error-prone way of doing layout I've ever seen.

I don't think so. Accessibility, links, ad blocking etc. behave exactly the same with wasm as with JS.

What difference do you see?

no if you don't target DOM, if i could have "browser" in a browser that targets canvas or webgl then i cannot block it, only on network level.

You can use canvas or webgl from JavaScript too, so there's no change here specific to wasm.

Except JS alone wasn't good enough for that; WASM, especially as a compilation target, seems to make the task of embedding a browser within a webpage easier.

you can but, wasm should be an order of magnitude faster then javascript, this makes it possible to run all kinds of "heavy" apps in the browser. some kind of client that outputs to webgl in this case shoud be doable, in pure js it would be to slow /expensive.

You won't be able to block it on a network level either when it's running on a locked-down platform like iOS and using an eventual iteration of TLS that prevents man-in-the-middle inspection. This feels like yet one more step in the direction of "you don't own your computer anymore".

i was more thinking on DNS level, but with DNS encryption even that falls on it's face.

DNS encryption is done by the OS, which you control, so you could still null route ad servers.

except iOS has some of the best ad-blocking available, with OS level extensions that are almost impossible to get around. So your point doesn't really make a ton of sense.

The OS-level tools won't be able to inspect the websockets-based channel that the browser-in-browser uses to communicate with its back-end. It will all be opaque TLS-encrypted traffic to the OS. The native browser will be hosting a canvas element that will host the UI and running WASM code and that'll be all the OS will see.

Documents are documents.

Apps are apps.

Sometimes both are in the browser.

It'd be great if all "documents" had an HTML version, with minimal JS. For accessibility, searching, deep linking, etc.

like Flipboard created? React Canvas rendered the site directly to canvas.

https://engineering.flipboard.com/2015/02/mobile-web

How the hell do you retain any accessibility when rendering a custom UI in Canvas?

you dont. they reinvented their own css and dom.

There are sites where accessibility isn't much of a concern (esp things like games) or where it would be easily handled (eg. an image aggregator). For the rest, it seems inevitable that another (probably not-quite-compatible) accessibility layer gets built on top (for example, using the Qt accessibility model when compiling Qt into a canvas).

Overall though, I think wasm shouldn't be replacing HTML/JS.

It already is possible, with JavaScript. WASM doesn't change anything. And the fact that although it happens with JavaScript, it isn't pervasive, I think should assuage this fear.

I agree WASM doesn't bring in anything fundamental to this picture that isn't already there with JS. But that is no comfort.

In the ancient web world, the site author wrote HTML to describe the data she wanted presented and the browser took care of making it accessible. But authors (especially companies) wanted detailed control of how their sites looked, so they turned to flash etc.

JS has long been re-playing this trend in slow motion -- moving away from web pages being interactive documents presented by the GUI app called browser and towards them being stand-alone GUIs like in flash.

SEO is too big of a concern nowadays for a resurgence of black-box websites, specially if they depend on large audiences and ad revenue.

But you can still get social media traffic. I think that it's very possible that will help allow black box web sites to return.

I suspect some appeal of Electron apps is that the user can't block ads or scripts running in what's basically a website.

To be frank, I'm surprised Wildvine hasn't been used in conjunction with DoubleClick/GoogleAds to enforce websites in showing adverts.

Sure, there's "fuckAdblock" but that shortly spawned "FuckFuckAdblock". It's a whole different case when the very browser prevents the content from being tampered with.

Reply on news.ycombinator.com