Hyprland Gives You a Compositor, Not a Desktop
Every thread about switching to a tiling setup ends the same way. Someone posts a screenshot with a translucent terminal, a blurred wallpaper and a bar full of glyphs, and someone else replies: just use Hyprland.
That advice is not wrong so much as it is answering a different question. Hyprland is excellent. It is also not a desktop, and the gap between what it gives you and what you were using before is bigger, and stranger, than the screenshots suggest — because the missing pieces are cheap to assemble and expensive to keep.
I want to be precise about that gap, because "is Hyprland worth it" is really two questions wearing one coat, and only the second one is hard.
What a compositor actually is
Hyprland is a Wayland compositor. It arranges windows, handles input, draws borders and animations, and exposes an IPC socket so other programs can ask it things and tell it things. It does that very well, with the smoothest animation work in the Wayland ecosystem and a configuration surface that goes deeper than most people ever need.
Here is what it does not do, out of the box, because none of it is a compositor's job:
- no bar or status line
- no notifications
- no application launcher
- no clipboard history
- no screenshot or screen-recording flow
- no audio, network, or bluetooth panel
- no power menu, no session dialog
- no idea what your wallpaper is
- no lock screen, no idle handling
- no display-configuration UI — your monitor layout is a config file
The Hyprland project fills a few of those in with sibling tools: hypridle for idle, hyprlock for locking, hyprpaper for wallpaper, hyprpicker for colour picking. The rest, the community fills by choosing — Waybar or Ironbar for the bar, Walker or wofi or rofi for the launcher, Mako or dunst or swaync for notifications, grim and slurp for screenshots, wl-clipboard plus cliphist for clipboard, wlogout for the power menu — and then gluing the result together with keybindings.
Count that up. A working Hyprland desktop is six to ten independent programs, from six to ten independent maintainers, with six to ten configuration formats, that have never agreed on anything including what colour your accent is.
The assembly is a weekend. That is the trap.
Here is the thing that makes this hard to reason about: assembling it is genuinely fun and genuinely fast.
You will have something usable in an evening and something beautiful in a weekend. The feedback loop is tight, every change is visible, and the community has produced an enormous body of copy-pasteable configuration. This is a real hobby with real craft in it, and I am not going to be sniffy about it — the results are often more pleasant to use than anything a corporate design team has shipped.
But the weekend is not the cost. The weekend is the deposit. The cost is the next three years, and it is paid in a currency nobody quotes you up front: upstream churn, multiplied by the number of independent projects your desktop is made of.
Every one of those six to ten programs will, over three years, rename options, change defaults, deprecate a syntax, break a plugin, or die and be replaced by a fork. None of them coordinate with each other. None of them know your setup exists. And every one of those events lands, in full, on you — usually at the least convenient moment, because the moment you notice is the moment something stopped working.
Upstream just proved the point
If that sounds theoretical, Hyprland ran the experiment in public. Version 0.55 deprecated hyprlang in favour of Lua — not a renamed option, not a changed default. The entire configuration language.
Read that as a maintenance event rather than a news item. Everyone running a hand-rolled setup now owns that migration personally: their own hyprland.conf, plus every accumulated option rename from the releases before it, plus whatever their bar and their launcher and their lock screen decided to do in the same period.
To be clear, moving to Lua is a good decision. Config-as-a-program is better than config-as-a-document — it gives you conditionals, functions, and the ability to have one file call another, which turns out to be the load-bearing property for everything below. The problem was never the direction. The problem is that a config-language migration is exactly the class of change that a distribution can absorb on your behalf and a dotfiles repo cannot.
And notice which half of the ecosystem this hit hardest. It is not the person who set up Hyprland last month; they will just write Lua. It is the person with a four-year-old rice that has been quietly working, who has now discovered that their desktop has a maintenance backlog.
Three ways to answer the churn question
There are exactly three coherent answers, and picking between them is the decision. Everything else is theming.
Own it yourself. A dotfiles repo, your own migrations performed by hand, your own testing when a package updates. This is the default and it is what most people are doing without having decided to. Its virtue is total control; every piece is yours and nothing surprises you that you did not install. Its cost is that you are the integrator for a ten-project desktop, permanently, and integration work does not scale down when you get busy.
Declare it away. NixOS, or Home Manager on top of another distro. Configuration becomes a function of a config file and the machine is rebuilt rather than modified, which genuinely solves the problem — your desktop is reproducible, rollback is a generation, and upstream churn shows up as a build failure at a time you chose rather than a broken session at 9am. The price is that every small tweak is a build, and that you have taken on a second, quite large, thing to learn. If you are the sort of person who enjoys that trade, it is the strongest answer available.
Delegate it. Run a distribution that ships the whole assembly and takes responsibility for moving it forward — Omarchy is the current example, and its interesting property is not the theme collection but a migrations/ directory of timestamped, idempotent repair scripts for exactly the churn described above. Its own .conf files became .lua files in 4.0, and because the shipped defaults are the package's file and yours merely calls it, the defaults half of that migration was not your problem. I wrote about how that machinery works in detail.
The price of delegating is the usual one: you get someone else's opinions, and stepping outside them is discouraged by design.
So: is Hyprland worth it?
Split the coat back into two questions and both get easy.
"Is Hyprland a good compositor?" Yes, unambiguously. If you want tiling, smooth animations, and a deep configuration surface on Wayland, it is the strongest option available and the ecosystem around it is the healthiest in that niche.
"Should I build my desktop out of Hyprland?" That depends entirely on which of the three answers above you want, and the honest test is not about taste. It is: when your bar breaks on a Tuesday morning before a meeting, is fixing it something you will enjoy or something you will resent?
If you will enjoy it — and plenty of people genuinely will, this is a good hobby — build the rice. You will end up with something better than any distribution ships, because it is fitted to you.
If you will resent it, you have two options that are both better than the rice, and neither of them is going back to GNOME. Declare it with Nix, or delegate it to a distribution that has committed to maintaining the assembly. What you should not do is build the weekend rice while quietly hoping the three years will not happen. They will.
The part that generalises
Strip out the Wayland specifics and this is a shape that shows up everywhere in infrastructure.
A composable ecosystem moves the integration cost, it does not remove it. Ten small sharp tools with clean interfaces is a genuinely better architecture than one monolith — right up until you notice that "clean interfaces" describes the tools' relationship to each other and says nothing about their relationship to time. Somebody has to absorb ten independent release cadences. In a monolith that somebody is the vendor. In a composed system it is you, unless you have explicitly hired someone else for the job.
That is the same argument as microservices versus a modular monolith, as npm dependencies versus a standard library, as self-hosting versus managed. Every time, the pitch is flexibility, the hidden line item is integration-over-time, and every time the mature answer is not to abandon composition but to be explicit about who owns the seams.
Hyprland gives you the mechanism, and it is a very good mechanism. The assembly is a weekend. The maintenance contract is the actual product, and it is the one thing nobody puts in the screenshot.
Written against Hyprland's own documentation and release notes as of 22 August 2026, including the 0.55 Lua migration announcement. The Omarchy machinery is covered at length in Omarchy 4.0: The Distro Is Mostly a Migration Runner.