i3 vs Sway: Tiling Window Managers for Developer Productivity

If your editor, terminal and browser keep covering one another, tiling is worth a small experiment. i3 arranges windows on X11, while Sway brings an i3-compatible workflow to Wayland. Many commands carry over, but the display system can change how screen sharing, scaling and automation work. Try the applications you rely on in each session and see whether the arrangement helps; neither project can promise a faster working day.

Start with the applications you cannot lose

List the tools that make up a normal day: editor, terminal, browser, password manager, video calls, screen capture, clipboard history and remote desktop software. Add your monitors and their resolutions. You now have a practical test plan. A small memory saving is easy to give up if the session cannot share the screen you need in a meeting.

i3^[1] runs on X11 and its guide documents the familiar split, workspace, floating and scratchpad operations. Sway's project README^[2] describes it as an i3-compatible Wayland compositor, which manages windows and combines their contents for display. An i3 config is a starting point, not a guarantee that every X11 helper around it will also work. Keep your current desktop session available while you test. You can leave the same applications installed and change sessions at login.

Work through the table using your own applications. Sway’s output manual^[3] recommends integer scales where possible and notes that Xwayland windows can blur at high DPI, even though fractional scaling is available. Check text where you actually read it, then test a call. X11 also needs that capture check: the session alone does not establish what a particular video application can share.

Try i3 without rebuilding your whole desktop

Install i3 from your distribution and choose its session at login. On a first run without a config, i3-config-wizard offers to create one and choose your modifier key. The i3 guide^[1] says its default $mod+Enter opens a terminal, $mod+v selects a vertical split for the next window, and $mod+h a horizontal split. Open two terminals, move one to another workspace with $mod+Shift+<number>, and switch back with $mod+<number>. That is enough to learn whether the layout helps you keep related tasks together.

Copy your configuration before editing it. Change one binding at a time and reload it using the binding in your installed config. The guide's examples use bindsym to bind keys and assign to place matching windows on workspaces. For example, after checking the actual window class with xprop, you could add:

set $ws2 "2:terminal"
assign [class="^Alacritty$"] $ws2
bindsym $mod+Shift+t exec alacritty

This example assumes Alacritty is installed and its class is Alacritty on your system. The i3 assignment section^[1] explains that criteria match window properties and that the first matching assignment wins. If a window goes to the wrong workspace, inspect its class and your rule instead of adding more guesses. Keep a copy of the last working config so one typing error does not turn a small experiment into an evening of repair.

Once windows open where you expect them, settle on two or three useful workspaces and memorable bindings. You can explore bars, launchers and wallpaper afterward. The scratchpad is handy for a temporary terminal if that fits your routine, and easy to leave alone if it does not. For another part of a keyboard-first setup, the Zsh setup notes cover the terminal environment separately.

Once the basic layout works, choose a bar for information you actually look at. The i3 guide^[1] describes i3bar and its status_command: the bar shows workspaces, while a status program supplies the text beside them. Start with the packaged example before adding a custom script. If a command fails, run the status program in a terminal where you can see its error, then return to the bar configuration. If the bar is blank, check the status command before replacing the window manager.

Try Sway with a separate configuration

Install Sway from your distribution and start its session from a display manager or a TTY, the text console. The Sway README^[2] says you can copy the sample file, usually /etc/sway/config, to ~/.config/sway/config; an existing i3 config is another starting point. Save a separate copy before adapting it. Commands that launch X11-only helpers, such as a wallpaper or clipboard program chosen for i3, need a Wayland-aware equivalent or a deliberate Xwayland test.

Find your output names with swaymsg -t get_outputs, then use the Sway output manual^[3] to set one display at a time. For example, on a machine whose internal output really is named eDP-1:

output eDP-1 scale 1.5

The name and value are examples, not settings to paste blindly. Try an integer scale first if it is comfortable; the manual allows fractional values but notes possible blur for Xwayland clients. Test the editor and browser at your normal text size before deciding which setting wins. If an application appears on the wrong display, confirm the output names again after a dock or monitor change.

Sway's tiling commands are familiar to i3 users, but application matching may differ. The Sway command reference^[4] says native Wayland windows use an app_id; Xwayland windows can expose X11-style class properties. Check the window properties in the session before copying an assign [class=...] rule from i3. Put only the rules you have verified into the new config. A shorter file that you can explain is easier to troubleshoot than an imported collection of attractive snippets.

Treat the bar and launcher as separate decisions too. The Sway sample configuration^[5] includes a bar; its documented command syntax is the place to start if you want to keep that default. If you later choose a different bar, remove or disable the old one before diagnosing duplicates. The same applies to screenshot utilities and clipboard watchers: install one working path first, learn how it starts in your session, then add optional features. This gradual setup preserves a usable desktop while you discover which helpers belong to X11 and which belong to Wayland.

Test the part a screenshot cannot prove

Screen sharing is the important practical test for many developers. xdg-desktop-portal-wlr^[6] provides screenshot and screencast portal support for wlroots compositors; its manual^[7] points to PipeWire. Your distribution and application still have to use a compatible portal path. In a Sway session, start a test call, share the actual window or monitor you use for work, and ask another person whether the content is visible and updates. Repeat after docking and undocking if that is part of your day. Record the application version and portal packages when troubleshooting; “screen sharing works on Wayland” is too broad a diagnosis.

Run the corresponding sharing test in i3, using the application and content you need for work. Then try password-manager popups, clipboard behavior, video playback, external displays and suspend/resume in each session. An X11 capture path may suit one application better, while another works comfortably in Sway. Those everyday checks give you a reason to choose between them.

If one configuration fails, isolate the layer. Is the application itself running? Does a normal window open? Does the output appear in the compositor's list? For Sway capture, is the portal service installed and selected for the ScreenCast request? For an i3 workspace rule, does the window class match the rule? A small, reproducible symptom gets you further than replacing your whole config.

Choose the session you can maintain

Choose i3 if the X11 applications and capture path you depend on work reliably there and a Sway trial shows a concrete blocker. Choose Sway if its output handling and the applications you use pass the same tests and you prefer that Wayland environment. You can keep both installed: use the same workspace habits while maintaining separate configuration files for the pieces that differ.

Begin with a terminal, two workspaces and one display, and spend a little time using that setup. When something gets in the way, add a binding, assignment or scaling rule to solve that particular problem. A few familiar moves are easier to maintain than an imported collection of shortcuts, and leave more of the day for the work you opened the windows to do.