By having my editor (and the LSP servers, etc.) running on a different machine I can afford to have it be a big, high core count Linux machine maybe with GPUs in it that is arbitrarily hot or loud or heavy. For many languages (C/C++, Haskell, Rust, there are others) either the build or the go-to-definition or some other frequently-done thing are slow on even the best laptop / quiet PC.
By having the client machine be an appliance running a terminal emulator, my colleagues and I can be indifferent to one another’s choices in desktop environment: there can be Mac people and Windows people and desktop Linux people etc. In my case I can have a slim little MacBook Air that can drive a big display, play sound properly out of the box, wake/sleep properly out of the box, and otherwise get out of the way while I work on the “real” computer, which can be anywhere with a manageable ping from here.
There are disadvantages too: mostly that networks go down, GUIs are nice for some things, and others. It’s not a free lunch.
It’s a tradeoff (and I’m aware that it’s surprising to many that regular computers still aren’t fast enough for many hackers), buts it’s not just Luddism.
If all your boxes are reasonably local those can be great options, but they still don’t obsolete tmux and stuff. Nothing obsoletes tmux and stuff.
Whether it’s vi or emacs or tmux or whatever: this field is too competitive to let shitty stuff stick around for decades. People who go all terminal know the alternatives, they’ve tried them, they try the new ones, and they know what the fuck they’re doing.
And if the speed is lower, then typically it also implies a high latency. Then I have found that running a GUI remotely via xpra gives a better experience than running an editor with IDE features under ssh and tmux. I suspect XPRA protocol simply has less round trips than a terminal IO as the latter was never designed for high-latency links.
Because unlike web apps, terminal apps are often fast (and even faster when the terminal has HW acceleration, see for example https://alacritty.org). Unlike native GUIs, they can easily go through a low-bandwidth network connection (e.g. ssh). They are often portable and can be easily made stable without a huge stack of dependencies.
Trying to remember where some option in a cluttered dropdown menu you used 20 minutes ago is working memory, something I'm personally terrible with. It's either whiplash out of a flow state, or risks sidetracking me.
It takes practice to build muscle memory, but it's something that generally stays with you for a long time, so it's an investment.
The point is that you don't think about keyboard shortcuts. You just think about the thing you need to do, and let your hands do it.
This is why old cashier systems are so super fast.
If something can open a shell remotely, it can show a GUI remotely.
Secure servers do not include GUI packages. They are enormous, require elevated privileges, and have a poor security history.
No reasonably quasi-secure server in the last 25 years has included GUI packages, but has allowed and often depended on shell access.
Modern deployment regimes which include ephemeral instances sometimes do not permit shell access.
These are not the same things!
I spend a lot of time ssh’ed into other computers where there is no gui.
I often tell new devs that there are different formats for computer programs, just like with media.
1. One dimensional, text only
2. Two dimensional desktop
3. Three dimensional VR / AR, etc
Just like audio, video and physical immersive art, having one that exists doesn’t make the others invalid, bad, or useless. You need to pick the right format for the job.
If you’re doing “low level” things one dimensional is often the most useful - which, I think, is why the hacker community prefers terminal based.
(not to mention you can often view lower dimensional things in higher dimensions, but not the other way around (something like running a terminal in VR vs VR in a terminal))