I hate: Programming Wayland applications

Original Article ↗ Hacker News Discussion ↗

Overall Tone

  • Strong split between people who like Wayland as users and those who find it painful as developers.
  • Many agree the raw Wayland API is hostile for simple apps; disagreement on whether that’s acceptable for a “low-level” protocol.

Wayland vs X11 (and Win32) Design

  • Wayland is seen as “theoretical / pure” and minimal: surfaces + events, everything else pushed out of core.
  • Critics say X11 and Win32 are more pragmatic: easy to open a window in a few calls, whereas a trivial Wayland client can be hundreds of lines and heavy on boilerplate.
  • Some argue X11 already handled HiDPI and tearing “well enough”; others say X11 had practical issues, especially with mixed-DPI and compositing.
  • Network transparency: some rely heavily on X11’s ability to run remote GUI apps; others say X11 forwarding is fragile and not a compelling reason to keep X11.

Security, Isolation, and Lost Capabilities

  • Pro‑Wayland side: X11 is a “security disaster” (keylogging, full-screen inspection, clipboard snooping) that undermines sandboxing.
  • Critics: these problems could have been fixed in X11 (e.g., ACLs, trusted/untrusted clients, Win32-style access checks) without a new protocol.
  • Complaints that Wayland’s security model breaks common workflows:
    • Global hotkeys, automation tools (xdotool-like), independent window managers, and accessibility tools become compositor-dependent or impossible.
    • People note OBS-style global shortcuts and a11y tools are now hard to implement or require per-compositor extensions and user workarounds.

Compositor Fragmentation & Missing Standards

  • Many frustrations stem from delegating functionality to compositors:
    • Global shortcuts, window management APIs, key remapping, a11y, screenshots, etc. all live in non-standard extensions.
  • Result: feature matrix across compositors, poor portability, and apps needing compositor-specific code or extensions.
  • Some see this as analogous to web platform fragmentation; others say lack of a standardized “window manager layer” is fundamentally problematic.

APIs, Callbacks, and Abstraction Layers

  • Wayland client API criticized as:
    • Callback-heavy, object-graph-based, XML-generated, with confusing functions (e.g., dispatch vs roundtrip).
    • Difficult compared to simple event-loop + switch-based models.
  • Defenders note:
    • It’s synchronous from the app’s perspective and primarily about queueing; “callback hell” is overstated.
    • Low-level APIs are supposed to be verbose; developers should use toolkits (GTK, Qt, SDL, GLFW, winit, Avalonia).
  • Others counter there should be an officially blessed, stable mid-level client library shipped with Wayland, rather than relying on third-party hobby projects.

Systemd Analogy & Community Dynamics

  • Some comments liken the Wayland debate to systemd controversies: loud, repetitive complaints vs defenders seeing necessary modernization.
  • One camp sees opposition as fear of change; another argues criticism is justified because these components are effectively forced by distros, not optional apps.