The first time I tried a tiling window manager, I spent an hour just trying to figure out how to quit vim—then I realized I’d accidentally opened three terminals layered on top of each other. That’s the unglamorous reality of stepping away from a floating desktop. But stick with it for a week and you start to understand why so many developers swear by them: less mouse movement, a keyboard-first flow, and a desktop that bends exactly to your workflow instead of the other way around. The two names that keep coming up for modern setups are i3 and Sway. Both are tiling, both are configurable, and Sway even reads i3 configs—but they target different display protocols, which matters more than you’d think.

This article is a practical walk-through. It covers why you might choose one over the other, how to get each running, and the small-but-significant tweaks that turn a bare tiling manager into a productive development environment. No prior Linux window manager experience is assumed, though comfort editing text config files will help enormously.

Why a Tiling Window Manager?

Before jumping into the software, it’s worth asking: why bother? A typical desktop environment (GNOME, KDE, Windows, macOS) uses a floating paradigm—windows overlap, and you drag them around with a mouse. A tiling window manager divides your screen into non-overlapping tiles automatically. New windows appear in the next available space, and you control everything with keyboard shortcuts.

For developers, this has concrete benefits:

  • Screen real estate is never wasted. No title bars, no decorative borders eating up pixels. A fullscreen editor and terminal sit side-by-side with nothing wasted on chrome.
  • Keyboard-centric navigation. You assign applications to workspaces, switch between them, and resize tiles without leaving the home row. Once muscle memory kicks in, it’s faster than dragging a mouse.
  • Configuration as code. The entire layout, keybindings, and behavior live in a text file (for i3 and Sway, often a single file). You can version control it, carry it across machines, and tweak it exactly to your taste.
  • Low resource usage. These managers are minimal. They won’t eat RAM or CPU that you’d rather give to a compiler or a local LLM.

The trade-off is an initial productivity dip. Expect to fumble for a few days. The payoff comes when you stop thinking about window placement and just think about code.

i3: The Wayland-less Stalwart

i3 has been around since 2009 and runs on the X11 display server. X11 is the older, battle-tested stack, and that means i3 works on nearly any Linux system, including remote or virtual machine sessions over SSH with X forwarding. It’s also the reference implementation for the i3 IPC protocol, so tools like i3bar, i3status, and countless scripts target it directly.

Setup is straightforward:

sudo apt install i3 i3status i3lock  # or equivalent

After installing, log out, select i3 from your display manager’s session menu, and you’ll land in a mostly blank screen. The first thing you’ll see is a prompt to generate a config file in ~/.config/i3/config. Accept it, choose Mod (the modifier key, typically Super/Windows key), and you’re in.

The default config is surprisingly usable. Open a terminal with Mod+Enter, launch another, and they tile horizontally. Toggle split direction with Mod+v for vertical or Mod+h for horizontal. Close a window with Mod+Shift+q. The i3 documentation walks you through the rest, and it’s well worth reading at least the first few sections.

Because i3 runs under X11, you get full support for tools like xrandr for multi-monitor layout, picom for compositing and transparency, and screensharing that “just works” in most video conferencing apps. That last point matters if you often pair program over a call.

One common hiccup: HiDPI scaling. X11 can handle fractional scaling, but it’s clunky. You might set Xft.dpi: 144 in .Xresources and adjust individual application settings. It’s solvable, but if you spend most of your day on a 4K laptop screen, the next option may feel more natural.

Sway: i3 for Wayland

Sway is a drop-in replacement for i3, but it targets the Wayland display protocol instead of X11. The project explicitly aims for compatibility—most i3 configs work unmodified, and the default keybindings are identical. Install:

sudo apt install sway swaylock swayidle  # for Debian/Ubuntu

Sway launches from a TTY (no display manager required, though they work). After logging in, start it with sway. The first run will generate a config at ~/.config/sway/config, using the same Mod key selection.

Why choose Sway over i3? Wayland brings modern display handling: per-monitor fractional scaling, better security isolation (one app can’t read another’s keystrokes), and tear-free rendering from the start. For developers with high-DPI laptop screens or mixed-DPI multi-monitor setups, this alone can be the deciding factor. Set an output scale with a line like output eDP-1 scale 1.5 in the config, and everything looks crisp.

The downsides are compatibility gaps. Screen sharing in Discord, Slack, or Zoom may require extra steps like installing xdg-desktop-portal-wlr and using browser-based clients over native apps. Some clipboard managers, screenshot tools, and notification daemons need Wayland-native replacements. And NVIDIA GPU users have historically had a rougher time—things have improved with recent drivers, but if your machine uses an NVIDIA card, test Sway before committing.

Setting Up i3 (Concrete Steps)

Let’s walk through a minimal but comfortable i3 configuration. Assume you’ve accepted the default config and want to tweak it.

  1. Open your config: Mod+Shift+c then edit ~/.config/i3/config.
  2. Define your workspaces with names you’ll actually use:
set $ws1 "1:code"
set $ws2 "2:term"
set $ws3 "3:browser"
set $ws4 "4:chat"
set $ws5 "5:misc"

Then assign them:

workspace $ws1 output HDMI-1
workspace $ws2 output HDMI-1

(You can find output names with xrandr.)

  1. Set a wallpaper with feh (install it first) and a compositor for subtle transparency or fade effects. In your config’s autostart section:
exec --no-startup-id feh --bg-scale ~/wallpaper.jpg
exec --no-startup-id picom

  1. Add a status bar that shows workspaces, battery, volume, and system tray. The default i3status is functional, but many people switch to polybar for more visual appeal. To get a tray for network manager or Bluetooth icons, you need tray_output primary in the bar block.

  2. Customize keybindings for application launching:

bindsym $mod+Shift+f exec firefox
bindsym $mod+Shift+t exec alacritty

That’s enough to make i3 feel like home. The beauty is that you can paste snippets from others’ configs—the format is declarative and readable.

Setting Up Sway (Concrete Steps)

The Sway config lives at ~/.config/sway/config. If you’ve already used i3, copy your file over—most lines will work.

Key differences to address immediately:

  • Replace i3status with swaybar and i3status equivalent. Sway includes a swaybar that uses the same JSON protocol, so i3status works, but you might prefer waybar for a Wayland-native bar. Install and add:
exec waybar
  • Set monitor scale and layout explicitly. Use swaymsg -t get_outputs to find output names, then:
output eDP-1 mode 1920x1080@60Hz scale 1.25
output HDMI-A-1 resolution 2560x1440 position 1920,0
  • Screen sharing requires xdg-desktop-portal-wlr and setting up a portal. For PipeWire-based screen capture, install xdg-desktop-portal-wlr, pipewire, and wireplumber, then start them in your Sway config:
exec pipewire
exec wireplumber
exec /usr/lib/xdg-desktop-portal -r & /usr/lib/xdg-desktop-portal-wlr
  • Clipboard management: wl-clipboard provides wl-copy and wl-paste. Add a keybinding to sync clipboards:
exec wl-paste -t text --watch clipman store
  • Lock screen with swaylock (a configurable lock screen) and idle management via swayidle to lock after inactivity.

These extras fill in the gaps that a desktop environment usually handles, so you end up assembling your own. It’s satisfying, but it’s also time you aren’t coding. Weigh that against the control you gain.

Configuring Your Workflow: Modes, Workspaces, and Keybindings

Both i3 and Sway support modes—temporary keybinding layers that let you reuse the same keys for different contexts. The canonical example is a resize mode:

mode "resize" {
        bindsym j resize shrink width 10 px or 10 ppt
        bindsym k resize grow height 10 px or 10 ppt
        ...
        bindsym Return mode "default"
        bindsym Escape mode "default"
}
bindsym $mod+r mode "resize"

Press Mod+r, enter resize mode, adjust with jkl; keys, and exit with Return. This saves you from dedicating permanent shortcuts to infrequent actions.

Workspace discipline is the real productivity booster. Assign fixed applications to named workspaces and use for_window directives to steer applications automatically:

assign [class="Firefox"] $ws3
for_window [class="Alacritty"] move container to workspace $ws2

Now, whenever Firefox launches, it lands on workspace 3 without you thinking about it. Combine this with a scratchpad (a hidden drawer-like area) to stash a terminal or notes app that you can summon with a single key:

bindsym $mod+grave move scratchpad
bindsym $mod+Shift+grave scratchpad show

These patterns feel gimmicky at first, but after a week of not having to drag windows around, you’ll wonder why you ever did it.

Productivity Enhancements: Bars, Gaps, and Scripts

A status bar does more than show the time. With i3status or waybar, you can add custom modules that display the current git branch, CPU temperature, or your Pomodoro timer. Both tools read a simple configuration where you define blocks that execute a script or read a file. For example, a quick Python script that checks for unread emails can feed its output to the bar without any complex IPC.

Gaps (spacing between windows) are entirely optional but many developers find them nice for visual separation. In i3, you need a fork called i3-gaps (packaged in many distros as i3-gaps). Sway includes gaps natively: add gaps inner 5 and gaps outer 2 to your config. Keep them small—more than 10 pixels wastes precious terminal columns.

Scratchpad scripts add quick-access tools. A common one is a pop-up calculator or a floating notes window bound to a hotkey:

bindsym $mod+n exec --no-startup-id $term -e tmux new-session -A -s notes

This opens a persistent terminal running tmux with a notes session, toggled from the scratchpad. It’s there when you need it, invisible otherwise.

Finally, consider rofi or wofi as an application launcher that replaces the default dmenu. They can be themed, index your desktop files, and even include custom scripts for window switching. Map it to Mod+d and you’ll rarely type an application name into a terminal again.

i3 vs Sway: At a Glance

Aspect i3 Sway
Display server X11 Wayland
Config compatibility Reference Reads i3 configs, minor syntax changes
Fractional scaling Patchy (Xft DPI, per-app) Native per-output scale
Screen sharing Works out of the box Needs portals, PipeWire; still finicky
Multi-monitor xrandr; well-tested swaymsg output; mixed DPI works better
GPU support All (NVIDIA, AMD, Intel) NVIDIA problematic; AMD/Intel smooth
Ecosystem maturity Massive (polybar, picom, scripts) Growing; many i3 tools ported
Security Any app can read screen/keyboard Wayland sandboxing prevents one app from spying
Tear-free rendering Needs compositor (picom) Built-in, no tearing

This table isn’t a winner-takes-all verdict. If you rely on legacy X11 tools, have an NVIDIA card, or absolutely need polished screen sharing, i3 is the safer pick. If you want crisp scaling on high-DPI screens, better security isolation, or just prefer a modern graphics stack with no tearing by default, Sway deserves a serious look. Many developers use both: i3 on a desktop, Sway on a laptop.

Getting Started Without the Headache

My advice: start with whichever aligns with your hardware. Have AMD or Intel graphics and a 4K laptop? Try Sway first. Running an NVIDIA GPU or need reliable screen sharing tomorrow? Go i3. The configuration skills transfer almost completely, so switching later costs you an afternoon, not a week.

Allocate a weekend to the initial setup. The first boot into a tiling manager feels sparse, but once you add a wallpaper, bar, and a handful of keybindings, it clicks. Expect to keep your old desktop environment installed as a fallback while you build confidence. And when you’re stuck on a missing feature—like volume keys not working—check the Arch Wiki (even if you’re on another distro) and the i3/Sway user guides. The documentation is excellent, and the community configs are full of creative solutions.

The real productivity win comes not from any single feature but from the mindset shift: your window manager is now a tool you shape, not one you simply tolerate. That’s worth a few hours of initial confusion.