How do you think Awesome and i3 compare? Granted, their problem domains are slightly different, but as Awesome was once the king of the ricer WM and i3 currently is, they are worth comparing.
I used to use Awesome. However, I eventually realized that I didn't really have the drive or skill to do anything interesting with it, beyond very basic tweaks. The next time I felt the urge to distro hop, I ended up switching to i3. I found its configuration system somewhat limiting compared to Awesome's, but I don't think that's a flaw in i3, because I've been using it for about six months now. Let me explain why that wasn't a problem.
Awesome is very much like Emacs in design philosophy. Emacs not only provides the facility of a text editor, but also an entire scripting language and a broad range of tools to extend the editor with. In effect, it's an IDE disguised as a humble text editor. Awesome, similarly, not only provides the facility of a window manager, but also an entire Lua implementation and a set of extensions to extend its window management functionality with. Like how Emacs is an IDE disguised as a text editor, Awesome is an entire desktop environment disguised as a window manager. A sufficiently tooled Awesome setup not only offers window management, but also offers a panel with a system tray and its own native widgets, a notification daemon, and third-party extensions that doubtlessly incorporate further functionality. The end result is something extremely flexible, but also massive and complex. Consider the following code, found in Awesome's default configuration file [1]:
awful.key({ modkey, }, "j",
function ()
awful.client.focus.byidx( 1)
if client.focus then client.focus:raise() end
end)
This code snippet makes Mod+j switch focus to a different window. To do that, the user must separately declare the modifiers, the regular key, and an anonymous function that carries out the action. This complexity is good, in one sense, because it allows the user to turn complex actions into simple keybinds. But in another sense, it's terrible, because one of the simplest parts of window management can only be implemented with several lines of user-written code!
If Awesome is like Emacs, then i3 could be compared to Nano. Nano provides very basic text editing functionality: search and replace, undo and redo, cut copy and paste, and syntax highlighting. Nano is configurable, and the DSL its dotfile uses is simple. Nano lacks extensibility, however; there's not much more to it than what's offered on the menu bar at the bottom of the screen. Although habitual use of Nano is frowned upon (often for frankly elitist reasons), even among users of more advanced editors it has a reputation of being easy to use, and good in a pinch. Now, before we get back to i3, imagine, for a moment, a version of Nano that worked well with Unix pipes, such that one could pipe the output of a command into Nano, do a few quick edits, then pipe the results into another command. Despite how limited Nano per se is, its lack of inherent extensibility could more than be made up for by the powerful text processing tools that the Unix environment provides; after all, simple text editing tasks would be all it needed to do to excel! This is where we find i3. i3, too, has a very simple configuration file with a (compared to Awesome) limited set of commands, all of which relate directly to its core functionality. It also has simpler window management capabilities: it can move windows between and around workspaces, but unlike Awesome, it can't place tiled windows above floating windows, create window buttons, minimize windows (without a hack), or do many other things. However, unlike Awesome, the i3 developers expect and encourage users to combine i3 with other utilities. i3, by default, does not have an application launcher; its default configuration offloads this task to dmenu [2]. i3 ships with a taskbar, but i3bar is shipped as an independent utility, which merely takes an arbitrary status line and outputs it on an X display, and also provides a system tray and workspace list. (It lacks a window list.) Be default, i3bar takes input from another independent utility, i3status; however, the i3 documentation encourages the user to replace i3status with another status line utility, such as Conky. The lack of extensibility i3 can and should be compensated with through the use of other utilities, and thus the user sacrifices little or no flexibility. (i3-msg provides further flexibility, but pales in comparison to Awesome's Lua API.)
As a side note, another major difference lies between the tiling functionality of both window managers. Whereas Awesome provides a set of defined "layouts" that the user can apply to a workspace, i3's container system provides the user an immense amount of flexibility in positioning their windows. Several constructs in Awesome's API for arranging windows are totally unnecessary in i3. Although Awesome's layout system allows users to quickly change the layout of windows on the fly, and also allows greater ease in their initial placement, i3 easily beats it out in sheer flexibility.
[1]
https://github.com/aktau/awesome/blob/master/default.rc.lua, lines 169-173
[2]
http://code.stapelberg.de/git/i3/tree/etc/config, line 44
All the above said, I'm curious to see people's opinions on the differences between Awesome and i3. I'm also interested in comparisons between Awesome and Xmonad; their problem domain and design are much closer to each other.
