Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WASM Wayland Web (WWW)

joeyh.name

Post reply on HN
Print view View original

121–130 of 226 posts

Re: WASM Wayland Web (WWW)

#121

Post by taikahessu »

noduerme wrote: post #68
nmfisher wrote: post #43

Earlier quoted context omitted.

This is exactly how Flutter (now) works on web - the browser loads a JS/WASM blob, and your app renders everything to a canvas - and you're right, almost everything you mention is problematic. There is a time and a place for that paradigm, but it's niche. The lack of SEO alone is usually enough to stop it in its tracks.

Hasn't SEO been dead for like 10 years? It's not as if there's a search engine you can get to the first page on without paying, so why waste ad dollars on stuffing SEO garbage in your page and chasing the algorithm when you can just buy ads, if that's what you need? And does anyone find anything anymore by doing generic web searches anyway?

It sucks if you are non-profit working on subjects like drug abuse. Or anything that is considered "difficult" for our ad-overlords and thus all the relevant keywords are against ToS.

Re: WASM Wayland Web (WWW)

#122

Post by [deleted] »

jfoster wrote: post #88
neuroelectron wrote: post #22

Earlier quoted context omitted.

The "weaponization of complexity" is real—modern web standards are an endless labyrinth of APIs, performance optimizations, and security requirements. Large players like Google have the resources to dictate how the web evolves, while any newcomer faces insurmountable hurdles in achieving compatibility, security, and speed. Even major tech companies have tried and failed (e.g., Microsoft ditching EdgeHTML for Chromium…

With the way that AI is unfolding right now, this might be an outdated problem fairly soon. In 2026 if you can just tell your AI to build a new full-featured browser before you go to sleep, you might have something in the morning.

[deleted]

Re: WASM Wayland Web (WWW)

#123

Post by youngtaff »

torginus wrote: post #119
nmfisher wrote: post #43

Earlier quoted context omitted.

This is exactly how Flutter (now) works on web - the browser loads a JS/WASM blob, and your app renders everything to a canvas - and you're right, almost everything you mention is problematic. There is a time and a place for that paradigm, but it's niche. The lack of SEO alone is usually enough to stop it in its tracks.

I'm ignorant on this - but are there browser APIs that make it possible for the dev to integrate testing and accessibility tools, such as screen readers? If not, this sounds like a major oversight, and basically kills accessibility dead in these software and makes testing pretty painful.

Yes, browsers expose APIs to accessibility tools

Re: WASM Wayland Web (WWW)

#124

Post by fauigerzigerk »

DannyBee wrote: post #93
neuroelectron wrote: post #22

Earlier quoted context omitted.

The "weaponization of complexity" is real—modern web standards are an endless labyrinth of APIs, performance optimizations, and security requirements. Large players like Google have the resources to dictate how the web evolves, while any newcomer faces insurmountable hurdles in achieving compatibility, security, and speed. Even major tech companies have tried and failed (e.g., Microsoft ditching EdgeHTML for Chromium…

The "weaponization of complexity" as you call it is simply "work is done by those who show up". Google, Microsoft, Mozilla, Apple, etc took the horribly dastardly approach of "participating" and then "doing the work". The horror. Microsoft gave up because it wasn't worth it when someone else was willing to do the work. It was not something that was adding value to them by them doing it themselves anymore. It's hilari…

I think the "weaponization of complexity" claim can only be understood in relation to the "gimping browsers to protect the App Store" counter claim.

The situation is far more complex than three browser engines competing on a level playing field. "Showing up" is not even possible on iOS. And Firefox is funded by the maker of Chrome.

I think all of this rhetoric that browser vendors use against each other has to be seen against the backdrop of their respective business models.

Re: WASM Wayland Web (WWW)

#125

Post by [deleted] »

apatheticonion wrote: post #106
eadmund wrote: post #99

Earlier quoted context omitted.

The difference between now and then is that people back then wanted bookmarks, search engines, CLIs, user preferences, user scripts, view source, right-click menus, ad blockers, auto-translations, user stylesheets, assistive tools, bookmarklets, deep links and so forth. While some of us still do, the great mass of web users now just want TV on their smartphones: they want an attention-consumption device to distract t…

I launch Chrome with a bunch of flags to disable security and have a bunch of client scripts to override websites. I'm this close from creating my own browser based on Chromium

[deleted]

Re: WASM Wayland Web (WWW)

#126

Post by dleeftink »

_bent wrote: post #96
chrismorgan wrote: post #86

Earlier quoted context omitted.

That gives you a distinct accessibility tree in the DOM, which is kinda dumb as an approach. One of the reasons for going pure-canvas on the web was supposed to be performance (I don’t think it was ever true, though—only if comparing with a bad DOM implementation), and if you have to enable this accessibility DOM, you’re guaranteeing you’re doing double work. And no, on the web you can’t just do it when you need it:…

No, performance and fidelity are definitely better with the canvas renderers, especially skwasm. Flutter is very inspired by React, but instead of React which does tree diffing to minimize rebuilds, Flutter tries to make rebuilds as cheap as possible instead - for example through its single pass layout algorithm. The issue is that this doesn't map well to the DOM. You can't rebuild cheaply on the DOM because you'd be…

I'm sure this is tried (I've done it myself), but a hybrid approach would take best of both worlds; heavy rendering on a canvas, the rest as SVG/DOM elements.

Even this relation can be inverted: to speed up SVG interactions, I pre-render complex path and text elements at a sufficient resolution, which are shown during transitions/user interactions, but replaced with the SVG original elements once the render loop settles down again.

Re: WASM Wayland Web (WWW)

#127

Post by soulbadguy »

zanderwohl wrote: post #114
DannyBee wrote: post #93

Earlier quoted context omitted.

The "weaponization of complexity" as you call it is simply "work is done by those who show up". Google, Microsoft, Mozilla, Apple, etc took the horribly dastardly approach of "participating" and then "doing the work". The horror. Microsoft gave up because it wasn't worth it when someone else was willing to do the work. It was not something that was adding value to them by them doing it themselves anymore. It's hilari…

This reads like a semi-incoherent essay from someone who doesn't really understand what complexity is and has a chip on their shoulder about something completely unrelated to the topic at hand.

Yeah and coming from someone with so much experience and industry knowledge as dannybee i find that perspective very puzzling.

Just painting the situation as well google have influence because they work the hardest is just bizare. Having been in some standard / comity meetings. Everyone in those room work very hard... but someone hard work is not enough

Re: WASM Wayland Web (WWW)

#128

Post by paulrouget »

That's something I was thinking a lot about back when I was working on Servo. Wasm + a protocol to talk to WebRender (expose display lists [0] to the wasm runtime). Some sort of "mini web", a minimal runtime that would do just enough that most web APIs could be re-implemented and shipped from the webpage directly. The DOM, the CSS parser, the layout engine, … could just be shipped as wasm modules.

Kind of defeat the purpose of view-source, but nowadays, it's a lost battle already.

And I didn't think too much about sandboxing, accessibility, network or whatnot. Just a fun idea…

[0]: https://github.com/servo/webrender/blob/c4bd5b47d8f5cd684334...

Re: WASM Wayland Web (WWW)

#130

Post by charrondev »

_bent wrote: post #96
chrismorgan wrote: post #86

Earlier quoted context omitted.

That gives you a distinct accessibility tree in the DOM, which is kinda dumb as an approach. One of the reasons for going pure-canvas on the web was supposed to be performance (I don’t think it was ever true, though—only if comparing with a bad DOM implementation), and if you have to enable this accessibility DOM, you’re guaranteeing you’re doing double work. And no, on the web you can’t just do it when you need it:…

No, performance and fidelity are definitely better with the canvas renderers, especially skwasm. Flutter is very inspired by React, but instead of React which does tree diffing to minimize rebuilds, Flutter tries to make rebuilds as cheap as possible instead - for example through its single pass layout algorithm. The issue is that this doesn't map well to the DOM. You can't rebuild cheaply on the DOM because you'd be…

I went and loaded up the flutter web demo on my iPhone 15 Pro https://flutter.github.io/samples/web/material_3_demo/

In addition to the pitfalls mentioned like being unable to select text, every interaction including scrolling is noticeably laggy and dropping frames.

Post reply on HN