Hacker News new | ask | show | jobs
by franga2000 1609 days ago
Yes, I really hope this doesn't become common. By not utilising the DOM, you're killing accessibility, autofill, customization (things like reader mode, automatic dark themes...)... These are things that regular people rely on every day (not just us techies writing userscript a and Stylus themes).
4 comments

It will definitly be the new common, by killing Flash et all without comparable tooling, while at the same time offering WASM, it was only a matter of time until we had the revenge of plugins.

Basically 10 years wasting time to come full circle.

https://leaningtech.com/cheerpj

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

https://opensilver.net/

All of the three major ones are now back, but it is ok, WASM is great!

It's not really a "WASM problem", as such; you can use the DOM from WASM and that works quite well. Similarly, you can do all this kind of graphics drawing with just JS as well.

It's just a choice this framework made. I bet there are actually some real advantages to it, but also disadvantages. I very very much like the customizability of the web, so I'd be very surprised if the advantages would outweigh the problems.

In short, I don't think it's really the same as Flash.

Concur. I block wasm and webgl, mostly for security and privacy, so don't use sites that require it. Unfortunately, as I also block trackers, most site operators won't even realize people like me visit their sites.
Does blocking WASM improve privacy? As I understand it, it essentially has the same capabilities as regular JS(?) but I never looked very deeply in to it, so maybe there's some parts I don't know about(?)
Theoretically, wasm shouldn't have more access, though I would be moderately concerned about bugs, and better access for timing and rowhammer.

Practically, it's mostly used for tracking and making users' machines execute even more inscrutable code. IMO, if you need wasm for |"normal" pages and apps, you're doing something wrong. There are notable exceptions (say machine emulators, maybe 3d games and such), but they are spread far between most pages.

It's ridiculous to me to even call these things web browsers anymore. A more realistic term is any-type-of-application-cross-platform engine. But that's not really concise. Why did the web have to become the primary development platform for nearly everything, with WebAssembly, WebGL, notifications, etc?

I, for one, am a fan of the fact that Gemini is growing in adoption (at least as far as I can tell). Such a nice, stout protocol.

The good thing is this new cross-platform runtime call the web browser has much better sandboxing and permissions models. Not perfect, but better than before, and can be improved. Something like uMatrix with granular comprehensive per site permissions to enable all the settings such as e.g. wasm is needed. Does anyone know of such?
It feels like a huge step backward in terms of all of that. It's what Flash used to be, except less blatant security risks I guess.
> less blatant security risks

For now. Flash was also fine in the early days.

Just look at the growth in the number of Adobe employees between 1990 and 2019 at this link :

https://dazeinfo.com/2019/11/08/number-of-adobe-employees-wo...

if headcount was any way to measure success, then the killing of Flash did Adobe the world of good.

edit : not corollary, but the capacity to manage Flash security might have arrived too late, if I recall that late 2000s sudden Acrobat hegemony that was so absolute a stranglehold on corporate document cultural defaults they were uncaring about opt out only browser extension auto installation and more dark patterns than I care to remember. Unless the dark patterns secured that growth. Ugh. One of the primary factors in my purchase of a top model iPhone for my first Apple product that wasn't Snow White era was the ability to print to PDF (edit removed anecdote accidentally aggregated)

I mean I would just argue that the accessibility APIs are currently tied to the DOM and we should fix that.
Accessibility API need a semantic layer that the DOM provide. You can't just make every arbitratry gui accessible. The app developers will have to pay the price (more development time).
I’m only familiar with Flutter which just happens to have a render to Canvas option on the web but they have a full accessibility tree that is designed for exactly that already with zero work from the developer.
Hopefully the GUI developers realize this is needed and put in the work, so that work can be shared by the end users of the GUI frameworks. I'd hate to think developers are going to reinvent the wheel on each project, but I've been less surprised before.