One thing that a great majority of commenters here seem to be missing is that Wayland's issues that make it unsuitable to replace X Windows will not just be ironed out in a couple of years (at least not in a way that would be an improvement over X), because it is flawed by design.
The thing is, Wayland developers do not want you to take screenshots or automate input events (injection and interception). Those are both "power-user" and "accessibility" features. So respectively those who like to use the Unix (or other OS) programming environment to its full potential (hackers?), and the blind/visually impaired will have a hard time if Wayland gets forced on them.
It is possible to solve those problems with effort on a per-compositor basis (meaning less choice for users and more redundant programming effort - programs that interact with GUIs will need to have separate code for each compositor!), or with protocol extensions - that, of course, would not be universally accepted. For example, I think no compositor currently give a Wayland user the option to mess with input events (key presses, etc.). This means no hot-keys!
Quoting Red Hat: "Furthermore, there isn’t a standard API for getting screen shots from Wayland. It’s dependent on what compositor (window manager/shell) the user is running, and if they implemented a proprietary API to do so."
An interesting Reddit discussion: "It has been almost a decade, why does Wayland not have a protocol definition for screenshots?" - answer - "Because security, dude! Wayland is designed with the thought that users download random applications from the interwebz which are not trustworthy and run them. Wayland actually makes a lot of sense if you don't think of Linux desktop distributions and desktop systems, but of smartphones. But for some reason we absolutely need this technology on the desktop, like we had not enough pain and lose ends over here without it." [7]
See [1] [2]. And my previous comments on the same topic: [3] [4].
Another thing wrong with Wayland is that forced compositing means noticeably (in interactive applications) more latency.
Small nitpick regarding the blog post: Chromium depends on GTK3.
[1] https://wiki.gnome.org/Accessibility/Wayland
[2] https://www.freedesktop.org/wiki/Accessibility/Wayland/
[3] https://news.ycombinator.com/item?id=20310200
[4] https://news.ycombinator.com/item?id=20308011
[7] https://www.reddit.com/r/linux/comments/7lb5l7/new_screensho...
You cannot take screenshots with wayland??
Nope! Not unless your DE has implemented their own custom screenshot solution, and your screenshot program has Code to interface with that DE.
Don't throw such bullshit. Of course you can take screenshots, and no a screenshot program does not need to be adjusted for each DE.
The screenshot program only needs to interface with the org.freedesktop.portal.Screenshot api, which works on GNOME, KDE and wlroots.
That requires Dbus, LOL.
Also, the API is not part of the Wayland protocol. In other words, not every compositor will implement it, and if they do, it will have its costs.
The dbus screenshot API does not work on wlroots without a standalone bridge.
That seems like a good design. A screenshot protocol can be outside the core wayland spec.