It doesn't seem surprising to me. As X.org has gained extensions over the last 30 years, toolkits that speak X11 find themselves having to decide which extensions they'd like to use. Adding flexibility on this naturally leads to a bigger feature matrix. Of course, the toolkits are also free to drop support for X servers that don't have those extensions, which in turn would shrink the X11 backend.
I have no doubt that in 30 years, they'll have a similarly-sized feature matrix for all the Wayland extensions they'll want to support.
Also, how often do you write gui apps without any framework? It is absolutely hidden away in both gtk and qt apps.
What is a wl_registry_listener and why do I need it? What is a simple XGetImage() equivalent on Wayland? On Xlib function names at least give you an idea about what they are supposed to be doing.
> Also, how often do you write gui apps without any framework?
As soon as you have a Toolkit you don't need Wayland anymore. Windows then are just additional nodes in the object tree. There was even a demonstration of GTK applications running in a framebuffer without X11 way before Wayland even existed. If Wayland can only be used sanely with toolkits it indeed is completely pointless.
Wayland’s abstraction is basically a buffer. The client simply creates a buffer either in shared memory, or directly on the GPU and then passes the compositor a handle to the buffer. That’s it.
Also, it is sort of ingenious to compare the two — the XLib is a higher level lib than libwayland. There is absolutely no reason why someone could not create a wrapper for this — although I again ask, how often does one create an only X/only Wayland window without a framework.
I am not sure what you mean by Wayland can only be used sanely with toolkits, any GUI usually need a toolkit or some equivalent, even under X. if you are not using a pre-existing toolkit and are writing your own routines to draw buttons and text boxes and such, that would be implementing your own toolkit.
