I hate: Programming Wayland applications

Original Article ↗ Hacker News Discussion ↗

Wayland’s low-level, callback-heavy API is portrayed as far more complex and fragmented than X11 or Win32, making even simple tasks like opening a window, handling global hotkeys, or integrating automation tools feel disproportionately hard. Commenters argue over whether this complexity and the tighter security model (which restricts global input, screen capture, and window introspection) are worthwhile trade-offs, with some seeing Wayland as a necessary modern replacement for X11 and others viewing it as user- and developer-hostile NIH syndrome pushed by major desktop projects. Many conclude that in practice most applications must rely on higher-level toolkits (GTK, Qt, SDL, etc.), and that better standardized, cross-compositor interfaces for “insecure” but useful features are still missing.

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.