If you haven't combined terminal tools together then you haven't use the terminal the way it's intended.
If you start 1 command and get 1 output, the terminal isn't particularly powerful.
One you do start combining commands then it's a totally different thing.
If your GUI does everything you need, then a terminal isn't necessarily useful. If your GUI doesn't provide a feature though, you are most likely stuck. You might be able to learn it's own API in a specific language, e.g. Lisp for Gimp, Python for Blender, etc. If though your terminal application doesn't provide what you need you can pipe its output to another terminal application and thus get something that none of those applications individual can. Once you have done it with 2 applications you can do that with 3, 4, etc. You can label those applications and re-use that tomorrow, share with someone else, etc.
The terminal isn't about starting one application.
GUIs are almost entirely non-scriptable. Some exceptions exist, but they're few and extremely limited compared to what you can do with a CLI. (Note I said CLI. A TUI is almost always a GUI made of text, and is just as non-scriptable.)
> Most of the time the GUI experience is the same or better than terminal tools
I started to take your comment seriously until that line. You're avoiding leveling up and learning how to use the CLI. Whatever reason you are avoiding it for, understand that's what is at play here.
If it is a one-off task, it doesn't matter if you use GUI or Terminal commands to do it. But more than once, terminal starts paying off IMO.
Here are some advantages.
- It is repeatable, you can do the same exact thing you did before. With ZSH history + FZF, recalling a command is a breeze.
- Auditability. The command in your shell history is there for you to revisit and servers as a permanent record of something you did (or didn't do).
- A command line doesn't make a mistake at 10th time, due to fatigue, inattention etc.
- Reusability. You may have to repeat the same command for different folders (or remote servers). A slight modification of the previous command will do it for you.
Second this. Just add Starship.rs for prompt and offload tool chain version handling to mise. That covers about 100% of my needs.
If your org doesn’t use mise, just add mise.toml to your global gitignore. Mise tries to be a single tool covering multiple needs, but don’t have to use it that way. I just manage toolchain versions and envvars (replace direnv).
$ for i in {1..5}; do /usr/bin/time zsh -i -c exit; done
0.01 real 0.00 user 0.00 sys
0.01 real 0.00 user 0.00 sys
0.00 real 0.00 user 0.00 sys
0.00 real 0.00 user 0.00 sys
0.00 real 0.00 user 0.00 sys
Speaking of slow, what I absolutely cannot comprehend is why ghostty is so popular. Despite being written in Zig it is very slow and a total CPU and memory hog. Just sitting there idle it’s pulling a constant 40% of my CPU? No thanks!
Am I the weird one? I usually have 3/4 terminals open at a time and rarely open new ones. Terminal startup speed is a non-issue for me.
The only thing I demand to be fast on my terminal is grep reverse search (ctrl+r) and of course typing a character. But if your terminal can't keep up with your typing speed there is something deeply wrong with it.
Same here. Main terminal w/ tmux, editor terminal with tmux (runs nvim so I can jump to it with a key bind), ssh to remote server with remote tmux, scratchpad term with tmux. I try to reuse the same panes a lot, otherwise open a new tmux window temporarily to do something (C-b c). Basically never open a whole new separate terminal instance on top of those.
Great post! There are some neat tricks around completion initing that I'll have to grab. I use fish shell and have done a bunch of optimization around async git statuses too.
I know nobody is missing it, because it is the first bit of the blog post, but the author does have a follow-up where they note corrections based on push-back they received from a reader.
Apparently for some of the simplicity-produces-speed arguments, users have found complex/featurefull. tools that are still quick. I’m not sure how to evaluate this (I like simplicity just because it is easier to fit simple tools in my head) but we should note the counter argument (and applaud the follow-up).
On Cygwin, FWIW, it pays huge dividends to avoid making the shell fork at all costs. Don't use $(sed ...). Use ${variable%foo%bar} or whatever. Cygwin punishes you hard for unnecessary fork().
As it turns out, avoiding unnecessary fork() is good hygiene everywhere.
In my life I can spare 50ms waiting for an terminal. But I have no time to spend 10000000 ms commuting to work, cleaning poop after an animal, or waiting for partner to put their face on!
I read Ghostty runs in a single process, but whenever I tried something like that eg a client/server model in urxvt or foot, I ended up reverting, because eventually some weird state affected the daemon and had to restart it killing all my terminals, so nowdays I just run foot standalone, with sway tabbing and splits are kind of built into the wm anyways. But keep hearing about Ghostty and wondering if I am missing out on something.
"The single biggest win is what's not there: no oh-my-zsh, no prezto or plugin manager. I've honestly never understood the appeal of these frameworks."
"Most of these optimizations are about leaving stuff out. It's about being intentional and only adding things you're going to use."
I don't use X11 or a similar graphics layer, only textmode. Thus I don't use a terminal emulator
I don't use zsh. I use NetBSD sh
Smaller and faster
This is what I am comfortable with
Others may have their own preferences; to each their own
I might not understand others' preferences but that's their business, not mine
I use the term "terminal emulator" in the same sense as in the blog post:
"The terminal itself
Shell startup is only half the story, because the emulator adds its own input latency. I use Ghostty, which is GPU-accelerated and native, and my config is just seven lines long."
Terminal emulators such as Ghostty usually depend on a "desktop" environment such as GNOME, KDE, etc.
I do not use a "desktop" environment
As such, I do not need the dependencies of such terminal emulators, such as "gtk" ("GIMP ToolKit") a widget toolkit for creating GUIs ("Graphical User Interfaces")
As I am only using the command line, not a "desktop", I have no need for a GUI toolkit
"Terminal emulator" as used in the blog post refers to userland software, such as Ghostty, not a terminal emulation module in the operating system kernel
The author of the blog post is using both (a) terminal emulator userland software and (b) kernel module(s) that perform terminal emulation
I only use one. I do not use a userland terminal emulator program
The gem in this post is Pure, which I haven't heard of until now. I also have my prompt show the git status, and for large repos `git status` can take 10+ seconds to load and cache.
I had no idea that you could do that asynchronously, and then have ZSH update the already printed prompt with the status later! That blows my mind!
The problem with this article is that the benchmark method they use is flawed. The documentation of zshbench explains why: https://github.com/romkatv/zsh-bench
Even with a low grade laptop, my zsh config grants me a sub 5ms prompt and a sub 1ms input lag, and that's far more important than the exit time.
./zsh-bench
==> benchmarking login shell of user XYZ ...
creates_tty=0
has_compsys=1
has_syntax_highlighting=0
has_autosuggestions=0
has_git_prompt=1
first_prompt_lag_ms=54.942
first_command_lag_ms=57.069
command_lag_ms=4.275
input_lag_ms=0.669
exit_time_ms=26.522
hyperfine --warmup 3 'zsh -i -c exit'
Benchmark 1: zsh -i -c exit
Time (mean ± σ): 26.5 ms ± 0.5 ms
Range (min … max): 25.5 ms … 27.6 ms
i honestly don't get why people think ghostty is fast. the gpu acceleration slows it down. maybe i push my machines harder than other people but when the machine is under load either gpu or cpu ghostty starts lagging super hard vs iterm. i've never had a problem with iterm render speed, but iterm never starts lagging when my box is fully maxed out and ghostty does regularly. i try it every few years and ive never seen any improvement.
I was so disappointed that Ghostty doesn't properly render Khmer text. Abugidas are important and you have to be able to render the symbols non-linearly. Cosmic term is the only terminal I've seen that actually works. But it's a bit slow on my 14 year old laptop.
Kitty doesn't work, alacrity doesn't work, foot doesn't work, gnome terminal doesn't work, xfce terminal doesn't work, urxvt doesn't work, xterm doesn't work, the list goes on.
I keep reading all these posts about terminal slowness, and here i am just sticking with Konsole + fish + starship.rs. Seems fine and responsive to me.
47 comments
[ 4.7 ms ] story [ 170 ms ] threadmy take is terminal is just quicker than "gui".
If you start 1 command and get 1 output, the terminal isn't particularly powerful.
One you do start combining commands then it's a totally different thing.
If your GUI does everything you need, then a terminal isn't necessarily useful. If your GUI doesn't provide a feature though, you are most likely stuck. You might be able to learn it's own API in a specific language, e.g. Lisp for Gimp, Python for Blender, etc. If though your terminal application doesn't provide what you need you can pipe its output to another terminal application and thus get something that none of those applications individual can. Once you have done it with 2 applications you can do that with 3, 4, etc. You can label those applications and re-use that tomorrow, share with someone else, etc.
The terminal isn't about starting one application.
I started to take your comment seriously until that line. You're avoiding leveling up and learning how to use the CLI. Whatever reason you are avoiding it for, understand that's what is at play here.
Here are some advantages.
I can't recommend switching to mise highly enough: https://mise.en.dev/
If your org doesn’t use mise, just add mise.toml to your global gitignore. Mise tries to be a single tool covering multiple needs, but don’t have to use it that way. I just manage toolchain versions and envvars (replace direnv).
The only thing I demand to be fast on my terminal is grep reverse search (ctrl+r) and of course typing a character. But if your terminal can't keep up with your typing speed there is something deeply wrong with it.
Apparently for some of the simplicity-produces-speed arguments, users have found complex/featurefull. tools that are still quick. I’m not sure how to evaluate this (I like simplicity just because it is easier to fit simple tools in my head) but we should note the counter argument (and applaud the follow-up).
As it turns out, avoiding unnecessary fork() is good hygiene everywhere.
"Most of these optimizations are about leaving stuff out. It's about being intentional and only adding things you're going to use."
I don't use X11 or a similar graphics layer, only textmode. Thus I don't use a terminal emulator
I don't use zsh. I use NetBSD sh
Smaller and faster
This is what I am comfortable with
Others may have their own preferences; to each their own
I might not understand others' preferences but that's their business, not mine
"The terminal itself
Shell startup is only half the story, because the emulator adds its own input latency. I use Ghostty, which is GPU-accelerated and native, and my config is just seven lines long."
I do not use Ghostty or anything similar^1
1. https://en.wikipedia.org/wiki/List_of_terminal_emulators
Further, the terminal emulator cited by the blog author requires a graphics driver
I do not use a graphics driver
Maybe this is not clear. I apologise for any ambiguity
vga(4) can be referred to as a "graphics driver"
For example,
https://man.netbsd.org/vga.4
But it does not support (non-text) graphics
It only supports text
The blog author is using a graphics layer such as X11 or Wayland along with a terminal emulator such as Ghostty on top of it
I do not use those things
https://man.netbsd.org/vga.4
"VGA graphics driver"
"This driver handles VGA graphics..."
I only use VGA textmode
I do not context switch into a graphics mode via 13h. No need
The blog author mentions that his terminal emulator is "GPU-accelerated" ("GPU" stands for "Graphic Processing Unit")
I don't use a terminal emulator that requires a graphics mode or one that uses a GPU
I'm interested in "text processing", displaying text. I like reading
I'm not interested in displaying images
I do not use a "desktop" environment
As such, I do not need the dependencies of such terminal emulators, such as "gtk" ("GIMP ToolKit") a widget toolkit for creating GUIs ("Graphical User Interfaces")
As I am only using the command line, not a "desktop", I have no need for a GUI toolkit
The blog author is using more than the VGA driver to display text, as indicated by the reference to "GPU-accelerated"
1. Some call this a "graphics driver" while others state it "does not do graphics"
2. For example, drivers with names ending in "fb", such as "vesafb"
I use the vga driver which does not do graphics
The author of the blog post is using both (a) terminal emulator userland software and (b) kernel module(s) that perform terminal emulation
I only use one. I do not use a userland terminal emulator program
I had no idea that you could do that asynchronously, and then have ZSH update the already printed prompt with the status later! That blows my mind!
Even with a low grade laptop, my zsh config grants me a sub 5ms prompt and a sub 1ms input lag, and that's far more important than the exit time.
Kitty doesn't work, alacrity doesn't work, foot doesn't work, gnome terminal doesn't work, xfce terminal doesn't work, urxvt doesn't work, xterm doesn't work, the list goes on.