# Why I don't use Wayland (and how it can be improved)

2023-04-28

Today I want to talk about Wayland, and why I don't use it. In case you're a
normie and don't know what Wayland is, Wayland is this new display protocol
created by the people over at Freedesktop. They want it to be better than the
display protocol most GNU/Linux users are already using called X11. While I'm
not against the idea of a new display protocol, in my opinion Wayland is a
failure, and it fails at doing everything X11 did right, and that's what I want
to talk about here. Note that most of this will be from a developer's
perspective; if you're using GNOME, KDE or maybe even one of the many wlroots
based compositors, your experience on Wayland is probably going to be pretty good.

## Terminology

First, let's talk terminology. On X11 we have something called a 'Window manager',
and as the name implies it manages your window. The window manager is the root
window, meaning it's the first window. Other than that, it's just like any other
window you may have. This is quite powerful, because it means in theory anything
can be a window manager. You can try this for yourself on Xorg and xinit by
running `startx /usr/bin/firefox`. What you should have is an X11 session with
only firefox open and nothing else. This is why we have window managers, they
allow us to spawn more windows and place those windows wherever we want. Even
desktop environment users have a window manager, because your desktop
environment comes bundled with one.

On Wayland and X11, we have something called a compositor. Let's ignore
Wayland's definition completely for now. On a basic level, the compositor provides
fancy effects such as transparency, rounded corners with anti-aliasing, shadows,
animations and other things you may or may not want. One of the most popular
compositors today is called Picom, and most standalone window manager users use
it, if they use a compositor at all. This works by creating buffer where these
effects are added, and then displaying the buffer to the user. This is why
older machines may feel slow when a compositor is running, it's just not
displaying that buffer quickly enough.

In X11, a client is pretty much the same thing as a window. I am going to be
using the term 'window' throughout this blog post, but client is what I
usually use when referring to an X11 window.

'Xorg' is an *implementation* of the X11 protocol, and it's the implementation
most users are using. There are other ones like XFree86, but most users use Xorg.

## The compositor problem

This is where Wayland's problem for me comes in. On X11 these two components are
separate, so I can pick and choose each component and just combine what I like.
With Wayland, they have decided to combine the compositor and window manager
into one program, which to make it even more confusing is also called a
compositor. Now, why is this so bad?

- Less modular

By combining the compositor and window manager, you're slowly making the display
stack less and less modular. The days of choosing your compositor and choosing
your window manager are now gone. It's all one big program, meaning even if you
avoid desktop environments you're still going to have one big program that does
everything. This is just not the way forward if you ask me. I believe the main
reason for this is "making the desktop easier for new users", but at this point
the GNU/Linux community should give up on new users who aren't willing to
learn our technology.

- Window managers are so complex

It is incredibly easy to make an X11 window manager, because again it's a window
like any other. You really just need to create a window, read atoms and finally
move/resize windows around. On Wayland you now also need to implement a compositor,
which adds a lot of complexity and room for failure. Even one of the more minimal
Wayland compsitors dwl, a dwm rewrite for Wayland has many more lines of code
than the original dwm, because now you also need to do the compositing yourself.
Not to mention, if you're using a minimal compositor like dwl, you can't have
fancy effects and a minimal window manager, that's just not possible anymore,
at least as of now.

This added complexity led to libraries like wlroots being created, and its slogan
really says it all; "about 60,000 lines of code you were going to write anyway".
However even with wlroots you still need to implement compositing, there's no
way to have a separate compositor with your window manager.

- No, a Wayland compositor is not a window like any other.

As I said earlier, a window manager on X11 is a window like any other. The only
difference is it's the first window spawned (root window), and it is responsible
for creating, resizing and displaying all other windows, although this is technically
not a requirement. This is good because you can for example `startx /usr/bin/firefox`
and have an X11 session that runs Firefox. Nothing else, just Firefox. This goes
for any graphical program such as your terminal emulator, text editor, Emacs, etc.
On Wayland, this is not possible, because windows do not implement compositing
whatsoever. They are only responsible for creating themselves.

- How about no compositor

I think this is worth mentioning as well. A lot of X11 users simply don't use a
compositor at all. They deem it unnecessary, and it makes sense. If you don't need
transparency, fancy effects, Vsync and other nice features like that, why should
you waste your system resources on a compositor? Good luck omitting the compositor
when you're using Wayland. You can't.

Those are the problems that come as a result of combining the compositor and
window manager. While I'm sure there could be benefits to combining the
compositor and window manager as well, I just cannot think of a single reason.

## What change do I want to see?

I want a more minimal display protocol. Wayland is more minimal so I think it
passes here. What I also want is a more *modular* display protocol, and this
is where Wayland seems to fail. X11 did this right, but I want it even more
modular than X11. Everything should be separate, as long as it doesn't harm the
user experience. Not to mention, more modular software is usually more secure,
because each module is much smaller and easier to maintain.

I also want a library which allows creating BOTH X11 and Wayland clients without
writing any extra code for it. This would be ideal, although I'm sure there
are potential challenges from doing it this way. You might say, "Just use GTK
or QT" but they also require writing extra code for Wayland or X11 support.
This leads to developers not supporting one or the other.

For example, I want to add Wayland support into spmenu. I'd be happy to do so,
but the problem is it would require rewriting the code for creating the
window, handling events, keybinds, clicks, drawing, mapping, and more.
It's just not something I want to deal with, which is why I've
chosen to not write any of my software to use Wayland native libraries.
There is XWayland, but to my knowledge there's no such thing in reverse.

## Conclusion

I want to mention that I'm very much open-minded towards a new display protocol.
I'm all for a new, more minimal, more stable display protocol. It's just that
Wayland makes it a pain to write compositors, and in many ways it's a downgrade
from X11, which is *really* old I might add. That's not to say Wayland has no
improvements and X11 is perfect. The most popular X11 implementation, Xorg
is extremely bloated and has a lot of legacy code that really doesn't matter
today and the protocol itself is probably not much better.

It also has absolutely horrible security. But all things considered, I think X11
just has much better ideas on what the desktop should be than Wayland does. If
Wayland improves the things I don't particularly like, I may end up switching
to it. But as of now, X11 works fine for me and the benefits of Wayland just aren't
worth it, so I am going to be sticking with X11. If you know of any solution
to this problem, I'd love to hear it, and I'd love to give Wayland a proper chance.

Thank you for reading, have a good day!