But Why Tho?

Why indeed? In today’s modern era of GUI-driven applications, why would anyone want to restrict themselves entirely to terminal-based applications? UI frameworks are getting easier to learn and becoming more and more cross-platform, a la tools like Electron where everything is a browser. At the same time, GUIs are pretty and easy on the eyes, which while not directly a requirement for code work is still definitely a plus - if you’re going to stare at a screen most of the day, it may as well look aesthetically-pleasing. It’s not even like GUIs are inherently slow, though there are plenty of examples of slow UI everywhere, even in professional tooling; even the most bare-bones laptops can manage to draw a simple UI to the screen with relatively minimal difficulty. Heck, most cell phones can do it just fine, to the point of Samsung trying to gently nudge users towards using their cell phone or tablet as their primary computing device with features like DeX.

So why, given all this, would anyone bother to forego GUI applications?

Working at the Speed of Text

Many terminal applications are faster than their GUI counterpart. Rendering all those visuals may be fast, but it’ll probably never be faster than rendering text-based UIs or, in some cases, rendering nothing at all (except maybe some text output). This isn’t the real speed gain that I’m talking about, though; that speed gain stems from keyboard-centricity. There’s a massive difference between programs that support keyboard navigation and those that are built primarily/solely for keyboarding through. I challenge anyone to find a UI that can compete with the insane speed of Neovim’s text navigation. The learning curve for text-only navigation may be steep, but it’s a price worth paying to never have to move your hands off the home row. I’d be lying if I said this was my primary motivation for trying out a terminal-centric approach, but it turned out to be the feature that really kept me here. Think about it; even if it only takes a second to move your hand from the keyboard to the mouse, another second or two to move the mouse to what you need to clock, and a second to move back, that’s still three or four seconds spent. Now multiply that by dozens or hundreds of times a day that you do it, and that becomes a lot of wasted time (and repetitive motion) that can be saved by using the keyboard to do everything that a mouse would otherwise be used for.

The Ethos of Terminal Tooling

Speaking of keyboard-centricity, terminal-centricity is it’s own benefit. Just like how most UNIX tools all have similar keybinds, most terminal-centric TUIs and other tools share some very similar option flags and keyboard shortcuts, which makes muscle memory transferrable between many terminal applications. The ability to stay within the confines of a terminal is also a boon unto itself; it means that you can use other terminal tricks with your tools, like pipes and redirects, grepping and regex, etc.

Scripting tools also work best with terminal tools and commands, and in fact many of the fancy UI-driven tools are really just calling commands (or some command equivalent) under the hood anyway, which means you can have the same functionality, but with added customizability via the magic of bash/zsh/python/etc. There’s something extremely satisfying about seamlessly connecting all your tools through scripts to the point that you can practically glide beginning to end of a complex task just by scripting all the common steps so thoroughly that it becomes effortless.

The Terminal Works Everywhere

This is what actually first drew me to terminal tooling. The first time I looked into using Neovim as an IDE, it was so that I could work on some passion projects over lunch breaks without having to copy personal code to a company computer. Instead, I wanted to be able to SSH into my own homelab, work on the code remotely, perhaps even leave tasks running in the background, and then disconnect and pick up where I left off when I got home. This was, I think, before JetBrains Rider (my IDE of choice at the time) offered remote development options, though nowadays most IDEs have some form of this baked in.

The premise still holds, however - if you have terminal tooling, those tools work basically anywhere with a network connection. Granted, trying to use a TUI on a phone screen isn’t going to be an optimal experience, but you can do it, which is more than can be said for a GUI-based program.

…idk it’s just cool, man

To be frank…this might be the most obvious and least compelling reason, but I think terminal tools are just neat. Sometimes its easy to get bogged down with standardization - in tools, in code style and format, in the business processes that comprise professional software development - and end up losing that sort of distinctive tech personality that most developers have. This happens to be my way of reclaiming that unique identity in a small way; I’m the terminal tool guy.

After reading all this, maybe I’ve at least piqued your interest in going GUI-less, or at least in giving terminal tools a try. To continue down this route, I’m going to split my current setup into a couple of sections:

• TUI substitutes - These are the easy ones, the tools you can give a try most easily. They’re largely substitutes for existing programs that supplement your dev environment, like Posting as a substitute for Postman/Insomnia, or Sqlit as a substitute for MySQL Workbench (or whatever SQL tool you use for quick queries).
• Command Tools - Presumably, as a dev, you probably use the terminal sometimes, just not all the time. These are tools you might integrate into your daily life to make using the terminal nicer and more convenient.
• Neovim - Finally, the big one. Neovim is a big enough topic to cover that it needs its own article (and probably more than one, frankly). I’ll also provide my current config for it, so if you like what you see you can grab it for yourself.