WASM Wayland Web (WWW)

Original Article ↗ Hacker News Discussion ↗

Proposed WASM/Wayland Web Model

  • Some participants are excited by the idea of running Wayland inside WASM, with the browser acting as compositor and the “web page” effectively being a native-like app surface.
  • Others like the conceptual cleanliness: a small core (HTTP + WASM + a graphics surface), with all higher-level APIs (DOM, HTML, layout, etc.) provided as replaceable components or libraries.

Accessibility, Text, and Canvas Rendering

  • Major concern: if HTML is replaced by opaque WASM blobs rendering to canvas, text becomes harder to access, internationalize, copy, search, and index.
  • People highlight broken or missing semantics: screen readers, native input, selection, keyboard shortcuts, zoom, and platform-consistent behavior are all at risk.
  • Several compare this directly to Flash-era problems: everything “looks” like text but isn’t really part of the document model.

Ad Blocking and User Control

  • Many worry that WASM/canvas apps would kill ad blockers, content filters, and user scripts, since there’s no DOM to inspect or modify.
  • Counterpoint: network-level blocking (filtering ad domains) would still work, but fine-grained content manipulation becomes nearly impossible.
  • Some argue the ultimate “ad blocker” is refusing to use ad-heavy sites or paying for ad-free versions, though others note that’s unrealistic for many use cases.

Browser Monoculture and Web Complexity

  • There’s debate over the article’s claim that web standards complexity has been “weaponized” to lock out new engines.
  • One side: three engines (Blink, WebKit, Gecko) exist plus projects like Ladybird/Servo; standards are better defined than ever; hard but not impossible.
  • Other side: Chrome’s market share and churn make keeping up prohibitively expensive; Firefox and Safari survive largely due to platform or funding asymmetries; real-world “Chrome-only” sites are common.
  • Some see complexity as largely user-driven feature growth; others as an anti-competitive moat.

Flash/Applets Redux vs New Opportunities

  • Many say a WASM-only web recreates Java applets/Flash/Silverlight: opaque binaries, no view-source, poor SEO, broken tooling, and user-hostile behavior.
  • Others note key differences: WebAssembly is standardized, sandboxed, and already used successfully inside existing pages; it can either draw to canvas or manipulate the DOM via glue code.
  • Flutter and similar canvas-based frameworks are cited as proof that this model “works” for apps, but users complain about jank, non-native text handling, and broken browser affordances.

Documents vs Applications on the Web

  • Strong sentiment that the web’s strength is as a document and linking system (REST, “principle of least power”), not just an app delivery channel.
  • Several advocate a clearer split: a simple, markup-focused “document web” and a separate “app runner” environment for rich applications.
  • Others argue that in practice this split is already blurred: SPAs and React have made many sites app-like, though they still emit HTML and remain at least somewhat indexable and scriptable.