It’s unique only in the combination of features.

• No configuration file, at all. When hlwm starts, it runs ${XDG_CONFIG_HOME}/herbstluftwm/autostart, which can be anything but it’s usually a shell script making a lot of calls to herstclient which do all of the configuration. So there’s no configuration syntax, and all WM configuration and control can be done exactly the same on the command line. No exceptions. bspwm does the same; I think niri and river on Wayland do this, too
• It’s tiled and keyboard controllable is, again, a first-class citizen.
• It has a sane tree model, with no weird exceptions. This is one area bspwm fails, although I grant this is subjective.
• It’s stable.
• It’s fast and small. You never see it in top, sorting either by CPU or memory.
• It supports

It’s that hlwm has them all. Very subjectively, I find the client syntax to be intuitive, rich, and full featured. It has good and consistent monitor detection. It has a variety of common built-in layout, but custom layouts are easily scripted with bash (or anything that can call the client). It has an event listening model, for writing layouts, or anything else you might want to do - again, the interface to this is a command line client. I find not having bespoke languages, non-Turing-complete configs, or being forced into a specific language is increasingly important to me for things I rarely, but deeply when I do - change.

It does build-in hotkey configuration (via the command line), unlike bspwm which farms this out to something like sxhkd. There’s nothing forcing you to use the built-in hotkey management, and in fact when I first switched I from bspwm I used sxhkd. Doing it within hlwm did have the advantage of eliminating yet another configuration file (for sxhkd), and made hotkey configuration just another purely command-line operation. No multistep edit & reloading. When you have CLI-first, you can make changes without worrying that you’ll screw something up that prevents a clean reboot. You make changes, test then, and then if you like it you make a permanent change to autostart (or some subscript).

This is orthogonal to how I manage firewalls: I always make manual changes with nft on the cli and IFF everything works after extensive testing, then I persist the changes to the /etc/nftables.conf.

There are many tiling WMs, but far fewer that make command line C&C fully competent in all ways. It narrows down field considerably.

bspwm is a close second, but I have trouble with the bspwm tree model, and especially how monitors and tags are represented. There are also some extremely caustic prominent members of the bspwm community. But, really, it’s the model weirdness that had me switch.

River seems to be the closest in model, C&C, and capabilities to hlwm, and is probably where I’ll end up. I need to confirm that all of the DPI issues I last had with Wayland a few months ago are fixed, and that everything I need runs, and that I’m not adding a ton of overhead to run common things (extra layers, emulators, whatever). The gap between “can” and “does well”; between “possible” and “efficient” has IME been a Wayland weakness.

TL;DR: for features and idiom, on X bspwm has fair overlap with hlwm. For Wayland, River seems to be a good alternative.

Edit: Niri commentary removed; it does have configuration files, and they’re in kdl.

I don’t need a project to explicitly say they are DEI inclusive, I generally don’t care who is contributing, but when you explicitly state you are against it in the README of your project that is just wild. The only divide I’m increasing by saying I don’t support or respect people who choose to, and makes it very clear they are, excluding people based on diversity is a divide they’ve created for themselves. Especially when it’s a fucking open source software project, like wtf does DEI have to do with it that the owner has to bring it up to begin with if not to intentionally hurt someone.