A viral post set the internet ablaze last week with a straightforward proposition: GUIs ought to be entirely keyboard-driven. After that, everyone chose a side. Terminal loyalists against the point-and-click defenders, shouting over each other as if it were the end of August 2026 and nothing existed beyond that. š„
The war is the wrong war
Here's my take: the TUI vs GUI fight is a distraction. Whether your application presents itself in a terminal window or as an Electron type application that can run on a modern web browser, it doesn't really matter to anyone. What people are actually looking for is a tool that respects their skills. The true offense is not having graphical interfaces, but having graphical interfaces that make you suffer if you try to use the keyboard. You are familiar with those. You enter a search, locate what you need, and then you realize you must grab the mouse to click a button that could have easily been activated by pressing Enter.
The math nobody argues with
This is not about sending good wishes. There's a 46-year-old model that already settled it. The Keystroke-Level Model, built in 1980 by Card, Moran, and Newell at Xerox PARC, put actual numbers on interface friction. This model quantified the costs associated with interactions on an interface. For instance, a keystroke takes about 0.28 seconds. Using a mouse to point takes about 1.1 seconds. And moving your hand between the keyboard and mouse takes another 0.4 seconds. Add it up. Every GUI that takes your hand off the keyboard to make you reach for the mouse is a 1.5-second minimum tax. Homing plus pointing. It may sound insignificant, but when you actually have to do it repeatedly four hundred times in a day, it's not so small a task after all. According to Jakob Nielsen, power users can complete tasks in half the time when using keyboard shortcuts rather than navigating through menus. It's that simple.
ā Keyboard-first isn't nostalgia
ā It's the interface refusing to waste your time
ā The mouse is a great tool, just not for the thing you do 400 times
The best apps already figured this out
Do you notice anything? The tools that people truly enjoy using are designed with the keyboard as the primary focus, but surprisingly, they are not traditional terminals. In 2005, Apple sent out Spotlight with Cmd+Space. Then Slack popularized the in-app command palette after a developer built a quick-switcher by exploiting a Slack XSS vulnerability during a 2014 hack day and passed it around the company. The Cmd+K shortcut is used consistently across various tools and applications such as GitHub, Discord, Figma, Notion, and Spotify. These applications have a graphical user interface but are designed to be efficiently used with the keyboard. Exactly. They are GUIs that no longer punish your hands.
When the app dares you to touch the mouse
Superhuman pushed the boundaries even more, I gotta give them credit for that. The founder, Rahul Vohra, purposely designed the app "to be deliberately a bit annoying to use with the mouse." The mouse friction of the app is a feature and not a bug. It pushes you towards keyboard shortcuts whether you were planning on learning them or not. The May 2026 internal data also shows that users actually respond to 72% more emails within an hour and save over four hours a week. That's an entire movie and a nap! Linear has been doing this since the very beginning. Every action you can take has a keyboard shortcut. Karri Saarinen, Jori Lallo, and Tuomas Artman designed it that way, and they were able to turn a profit in 2021 by creating a tool that developers open almost involuntarily. None of these are TUIs. That's the part the entire debate has been overlooking.
What this actually means for the stuff we build
I develop software with a small group, and this made me reconsider how I perceive our product. We no longer inquired if this should be something terminal. That was irrelevant. The real question became, could a user perform a frequent action without the need to exit the keyboard. In most cases, the answer was no, and it was painful. That's why we first optimized the common paths, introduced a command palette, and kept the uncommon things to the mouse as it should be. Because that's the fair split. Rare actions can hide behind a click. Common actions that have you reaching for your mouse/trackpad every time? That's just a slow tax you're imposing on your power users. š
It's not a religious issue whether or not power users should be respected. It's about ensuring that the users who engage the most with your product don't have to pay a 1.5-second toll repeatedly. The reflexive hostility to the GUI that a lot of them have - sentiment that's often justified, but sometimes it goes too far - comes from repeatedly feeling a hand on their shoulder. Here's something to think about: which app do you use daily, and do you feel like it could be twice as fast if it just allowed you to hit the Enter key?
Top comments (1)
The split you landed on is right, and I think there is a reason so few apps get there.
Keyboard support is a system property, not a component property. You can build every component with correct key handling and still ship an app that fails, because what actually decides it is the sequence. Tab order across two components neither of them knows about. Where focus goes after a dialog closes. Whether a shortcut inside a nested context shadows the global one. None of that lives in any component, so nothing owns it and no component test catches it.
Which is why your examples are the ones they are. Linear, Superhuman, Spotlight. All cases where one team owned the whole surface and could hold the sequence in their head. That is not a coincidence, and it is bad news for anyone assembling an app out of a component library, because every part can pass and the path through them still breaks.
The cheapest thing I know: pick your three most common tasks and do each one start to finish without touching the mouse. Not the components. The path.