Why dwl
2025-10-05
For anyone seeking a keyboard-driven, minimalist desktop on Linux, switching to Wayland is usually a massive journey of trial and error. Back in the X11 days, the "suckless" philosophy reigned supreme with dwm—a window manager configured entirely in C source code, blazing fast, and tailored via source patches.
Full disclosure: I actually skipped the X11 era entirely. By the time I jumped into the Linux desktop scene, Wayland was already mature, rock-solid, and ready for prime time, so I’ve never actually used dwm.
Even so, I wanted that same legendary suckless workflow. After bouncing around the ecosystem and testing everything from mainstream giants to rising stars, I finally landed on dwl (built against the cutting-edge wlroots-next branch).
The Evaluation: Why Other Compositors Fell Short
Before settling on dwl, I spent significant time testing the prominent players in the Wayland ecosystem. Each had brilliant ideas, but none could quite nail my specific requirements.
1. Sway vs. dwl: The Layout Dilemma
Sway is the industry standard for a stable Wayland environment. However, it's strictly an i3 clone, which relies on manual split tree layouts. I prefer a Master/Stack layout (the classic dwm style). Trying to force that onto Sway requires heavy external IPC scripts that make the setup feel bloated and sluggish. dwl natively inherits that Master layout out of the box, keeping things incredibly lightweight.
2. The River Evolution: From Classic to 0.4+
I spent a lot of time exploring River, which is currently in the middle of a massive architectural shift.
- River-Classic: This is the older, pre-breaking-change version of River that most people are familiar with. While it's stable, I hit a massive roadblock with its interaction with
wtype(the utility for simulating keystrokes). It turns outwtypeflat-out stops working if an Input Method Editor (IME) like Fcitx5 is running. Choosing between simulated inputs and being able to type in Chinese was an immediate dealbreaker. - The River 0.4+ Breaking Change: The project eventually moved to a much more modular design, essentially becoming a foundation that allows anyone to build their own window manager using the River protocol.
- Custom Implementations (kwm): This modularity led to cool projects like kwm—a tiling window manager written in Zig. I loved the architecture, but it still felt a bit early; it lacked "quality of life" essentials like auto-hiding the cursor while typing.
3. Niri & Hyprland: Too Unique, Too Heavy
- Niri: I genuinely loved its scrollable-tiling concept. Being able to maximize a window without resizing everything else is genius UX. However, the infinite horizontal strip just didn't click with my muscle memory.
- Hyprland: A visual masterpiece, but far too heavy. It’s packed with animations and features I just don't use. I prefer a brutalist, lean compositor where I’m in control of every single feature.
My Ultimate Solution: dwl + wlroots-next
This journey brought me straight back to the suckless architecture of dwl. By pulling from the wlroots-next branch, my compositor stays on the bleeding edge of performance and rendering.
Instead of dealing with a monolithic compositor packed with bloat, I patch dwl to do exactly what I want. Here is my current patch stack:
text-inputforeign-toplevelbarmodesbar-modesgapshide-cursor-when-typingunclutterpertagalwayscentermoveresizekbswapandfocusdir
Conclusion
Building your own desktop environment isn't about finding something "good enough" out of the box; it's about eliminating compromises. Mainstream compositors either brought too much weight, lacked layout flexibility, or broke my essential tools. By stripping everything back to dwl, I finally have a Wayland desktop that is blazing fast, infinitely hackable, and perfectly tailored to how I compute.