I used to use volta but then they killed it and told people to switch to mise. The mise setup is just way too complicated. I just am tired of having different config files for different tooling when it should just read whats in the package.json and be done with it.
The problem is you still have to know to look for that setting to enable it. That’s too much work when I can just stick with the older tools that work without touching anything.
This wasn't an option for us because as an org we used their recommended hook (1) to automatically change node versions when switching directories, but it effectively undoes the lazy loading.
With mise you get the behaviour of automatically switching when you change directories effectively for free.
Edit: unless you aliased it to `node` or `npm`, which would be fine I guess but super annoying if you ran node or npm commands often. It is not worth the hassle, no one should use nvm in 2026 imo
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).
Unrelated to Mise but related to zsh, there's also https://github.com/jeffreytse/zsh-vi-mode/issues/316. I noticed this plugin was causing a lot of delay. Learned a decent amount about zsh profiling from that issue.
I wasn't actually aware of the impact. I measured the zsh startup time locally (with mvn active and commented out) and it indeed makes a difference (.39s -> .08s). Not that I would have noticed that without measuring :) - yes I'm an old geezer.
Thank you for the recommendation, I might then also be able to ditch sdkman as well.
With zsh i set up nvm to lazy load, so I don't pay for it when I don't use it (I'm a C++ and Rust dev, but I occasionally need to run js stuff from other team members).
I can strongly recommend lazy loading in zsh in general, I use it for pyenv too (which is also slow to load, but I write Python maybe every other week or so only).
The way to do this is to use the autoload functionality in zsh and have the autoloaded script replace itself with the real shell init code for the tool in question.
How often do you launch a fresh terminal though? I start mine with a script to have favourite tabs ready at boot and then generally not much afterwards.
Constantly. I think we've used the excuse of "well, what if you just launch it less often?" enough to excuse bad performance defaults, especially when alternative solutions fix the issue with very few trade-offs.
This is going to vary wildly by what you do and how much CLI you use.
I’m an SRE and the answer is “constantly”. I get pulled in a lot of directions, it’s way easier to maintain context if I open a new terminal or tab for each thing.
Joe asks about something, I open a terminal. Teammate asks about something, new terminal. Joe replies, I swap back to his terminal to look at the scrollback buffer.
I’m closer to you when doing more dev work. One tab running a watcher for builds and restarting the app, one tab to run tests or whatever, a couple for poking around if I need to grep or curl or whatever.
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.
I open and close terminals _constantly_, but I'm usually pretty weird in my workflow, so no comment on your first question.
I run a scrolling WM and have settled into a habit of opening terminals when I need them, then closing them right after. I'll open a terminal, git pull, close it. Etc. I also use a terminal that launches cold in 10-20 ms, so it's not like a pay a price for it.
This is actually what I thought this post was about! But then I saw the Ghostty reference, which, in my experience, is not very fast to launch at all. I got it opening new windows quickly by running the main process as a systemd service, but Foot launches way faster without all that fuss, and allows you to go the daemon route if you want it _even_ faster.
EDIT: Just want to clarify, no shade on Ghostty. That project is cross platform and uses the 100% defensible decision to use the full GTK stack on linux. Foot is Linux AND Wayland only, and uses that very restrictive environment to optimize the hell out of startup and general performance.
I constantly open and close terminals too. Maybe I'm doing a quick lazygit check on cwd. Maybe I'm opening up an ephemeral claude/codex session for a couple questions about why a test failed. Or quickly editing a file with vim. Or remembering where I put that file with yazi or fzf. -- I don't even know, but all of it is contingent on it being fast to open a new terminal in cwd.
So much so that I vibe-coded my own terminal emulator for vertical tabs on macOS (using libghostty for the terminals) that is faster and less weird than iTerm.
It can affect shell subprocess startup time as well, which, depending on your setup and the tools you use, might be worth optimising for.
I don't remember when I did it, but it looks like I must have gone through this at some point (maybe due to using GNU Make a lot? Or perhaps it was some other tool) - my zsh setup does a bunch of autocomplete setup only in the interactive case, and it seems to help a bit with startup time, at least on macOS:
% for i in {1..5}; do /usr/bin/time zsh -i -c exit; done # zsh in interactive mode
0.05 real 0.03 user 0.02 sys
0.02 real 0.01 user 0.01 sys
0.02 real 0.01 user 0.00 sys
0.02 real 0.01 user 0.00 sys
0.02 real 0.01 user 0.00 sys
% for i in {1..5}; do /usr/bin/time zsh -c exit; done # zsh in non-interactive mode
0.01 real 0.00 user 0.01 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
For the interactive case, I don't really mind (within limits - the worst case, on macOS after a reboot, takes several seconds, and that's tedious). I also start new interactive terminal sessions fairly rarely.
Maybe, but notice that almost all of the article, and its followup posted today, is about the speed of starting a shell not of a terminal emulator window. So if you use interactive sub-shells, anything from shelling out of a vi clone or mailx, through :terminal in NeoVIM, to running tmux/screen or script, then the concerns are relevant.
That said, it is almost totally about the Z shell. So you might still qualify as 'weird' in this case on the alternative grounds of not using the Z shell. (-:
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.
> But if your terminal can't keep up with your typing speed there is something deeply wrong with it.
For the poor sools that had to work in VDI with radio link...
I open terminal far more often than that. But you should also remember that the startup cost is also paid by some subshells, and any shell scripts you run (the actual cost will vary: which init files are sourced varies between interactive and non-interactive shells as well as login shells and non-login shells, but it won't be zero cost).
I only notice how efficient my terminal is if something dumps a ton of logs to stdout. Sure I can pipe to a file and use vim, but it's convenient not to need to do that. And sometimes I have like 8 things going at once.
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).
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!
I'm the creator of Ghostty. This isn't right. It should idle at 0 to 1%, as supported by sibling comments. If you can collect more details about your system please open a discussion on the main Ghostty repo. Same with memory.
In terms of speed, same thing: if you can provide some kind of objectively measurable thing, we can look into it. Everything we've measured so far firmly places Ghostty in the "fast" camp (with friends such as Kitty).
We're sometimes faster, sometimes slower, but in any case not noticeably so. You wouldn't pick Ghostty vs Kitty for example for performance, it'd be something else. But you would pick Ghostty over say... iTerm2 for performance (but you may pick iTerm2 for features, its extremely feature rich!).
I suspect you enabled some weird setting that you've forgotten about. ghostty isn't unimaginably fast but it's faster than iTerm 2 which is plenty. And I'm sitting here with a lengthy Claude Code session open, as well as a couple tabs for my docker container and dev servers, and its idle CPU usage is 0.0%.
WezTerm is great too and, AFAICT, is everything Ghostty wants to be. Kitty is also very good, although WezTerm edges it out for having an integrated muxer.
I can't understand Ghostty either except as some kind of trendy memetic thing, the $GME of the TTY world.
Yup. For a while I was switching between all three to see which I liked most, and I always end up coming back to Wezterm. The only issue I’ve encountered is that releases on various package managers are routinely broken, but building from source solved that.
I know ghostty is designed to be super high performance but I find it both uglier and slower than Iterm2!
I started using it expecting to love it, but in reality it didn't seem to gain me anything but in fact was worse in several major ways. Also less configurable than Iterm2. :/
That happened to me too, turns out my desktop was software accelerated because I had screwed up the GPU config somehow. I asked Claude to fix it and it did.
Not that slow. It's certainly a bit faster than, say, VTE, and maybe even quicker than Wezterm, Kitty just feels faster when rendering editors or TUIs with a lot happening...
$ 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
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!
If you like that, you should check out my project https://beachcomber.sh . Its about time I take it from dogfooding to beta users if you want to give it a go.
Maybe I should remove the following bit of code from my profile?
if [ "$SESSION_TYPE" != 'remote/ssh' ]; then
if [ "${TERM_PROGRAM}" != 'tmux' ]; then
( if [ $[RANDOM % 10] == "0" ]; then fortune -n 40 -s; else echo "Hi, $(whoami)!"; fi ) | cowsay | lolcat && printf '\n'
else
if [ "${TMUX_PANE}" == '%0' ]; then
fortune | cowsay -f small | lolcat && printf '\n'
fi
fi
fi
It's a whole chain of interpreters firing up (sub-shells, Perl for the cow, Ruby for the lol, I think.) :D
But what would life be without a little bit of fun?
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 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
"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
"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
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."
Yes you do. It's the one that your in-kernel terminal emulator talks to in order to splat its bitmap fonts onto the screen. It is whatever wsdisplay has attached to, which can be one of a range of things from genfb through voodoofb and machfb to radeonfb. There was even a vesafb about 20 years ago.
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
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.
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.
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 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.
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!
> 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 what a person does during the day is mainly interacting with text then they need a tool for working well with text. Possibly this is an editor window inside an IDE. Possibly this is a shell in a terminal emulator. However, dismissing GUIs out of hand and asserting superiority of CLI is wrong. Far more disciplines need a GUI to get maximum utility from their computers than can get by with a CLI. Designers, architects, actual engineers, artists, lawyers, etc.
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.
In a Turing machine theory, a GUI application can do all the same things a terminal application can do.
In practical design, GUI applications inevitably deprecate keyboard abstractions in favor of graphical abstractions and graphical abstractions require parsing visual representations and are less conducive to "muscle memory" whenever pointer control is relative rather than absolute (which these days is approximately always [1]).
Keyboard oriented applications feel more like a language and human brains tend to map well to language and touch typing while GUI's rely on something akin (or identical) to hand-eye coordination. Hand-eye coordination is harder than touch typing and every GUI application requires developing a unique mental model.
[1] in the ancient days of digitizing tablets with absolute coordinates, it was possible to "touch mouse." But that's not how we do things today (and it would not work well with infinite scrolling, etc.)
Terminal tools are nice because keyboard shortcuts and text commands are quicker than clicking through menus and pressing buttons. For certain types of work (programming for example) this is much quicker and more comfortable than GUI interfaces.
Of course, other tasks are nicer with a GUI and/or mouse/tablet/touchscreen (art creation for example).
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.
Depends on what you grew up on/learned I think. CLI was the only thing around when I learned so that's still what I prefer. It's one of those things where I think you use the tool that you are proficient with. No right or wrong, just different strokes for different folks.
I think, for folks who grew up in the early 2000’s at least, CLI is the way to go forward. The GUIs at the time were really quite good, it was after the really limited time of the 90’s, but before we started dumbing down GUIs for… I dunno, style I guess.
If you were raised on programs where most of the features were accessible at a button-click, without going through a bunch of hamburgers, modern GUIs won’t feel familiar, CLI will.
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.)
I'm surprised people are still using nvm, considering it's impact on shell startup time.
I can't recommend switching to mise highly enough: https://mise.en.dev/
I used to use volta but then they killed it and told people to switch to mise. The mise setup is just way too complicated. I just am tired of having different config files for different tooling when it should just read whats in the package.json and be done with it.
package.json config is supported https://mise.jdx.dev/lang/node.html#nvmrc-node-version-and-p...
The problem is you still have to know to look for that setting to enable it. That’s too much work when I can just stick with the older tools that work without touching anything.
You can also just replace nvm with fnm (https://github.com/Schniz/fnm). It’s a lot faster and generally works better too.
I use aliases that lazily load nvm when I actually want to use it. This converts the shell startup penalty into a node/npm startup penalty.
This wasn't an option for us because as an org we used their recommended hook (1) to automatically change node versions when switching directories, but it effectively undoes the lazy loading.
With mise you get the behaviour of automatically switching when you change directories effectively for free.
1. https://github.com/nvm-sh/nvm#zsh
Edit: unless you aliased it to `node` or `npm`, which would be fine I guess but super annoying if you ran node or npm commands often. It is not worth the hassle, no one should use nvm in 2026 imo
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).
I had performance issues with Mise which I reported here https://github.com/jdx/mise/discussions/4821.
Unrelated to Mise but related to zsh, there's also https://github.com/jeffreytse/zsh-vi-mode/issues/316. I noticed this plugin was causing a lot of delay. Learned a decent amount about zsh profiling from that issue.
I wasn't actually aware of the impact. I measured the zsh startup time locally (with mvn active and commented out) and it indeed makes a difference (.39s -> .08s). Not that I would have noticed that without measuring :) - yes I'm an old geezer.
Thank you for the recommendation, I might then also be able to ditch sdkman as well.
With zsh i set up nvm to lazy load, so I don't pay for it when I don't use it (I'm a C++ and Rust dev, but I occasionally need to run js stuff from other team members).
I can strongly recommend lazy loading in zsh in general, I use it for pyenv too (which is also slow to load, but I write Python maybe every other week or so only).
The way to do this is to use the autoload functionality in zsh and have the autoloaded script replace itself with the real shell init code for the tool in question.
How often do you launch a fresh terminal though? I start mine with a script to have favourite tabs ready at boot and then generally not much afterwards.
Constantly. I think we've used the excuse of "well, what if you just launch it less often?" enough to excuse bad performance defaults, especially when alternative solutions fix the issue with very few trade-offs.
This is going to vary wildly by what you do and how much CLI you use.
I’m an SRE and the answer is “constantly”. I get pulled in a lot of directions, it’s way easier to maintain context if I open a new terminal or tab for each thing.
Joe asks about something, I open a terminal. Teammate asks about something, new terminal. Joe replies, I swap back to his terminal to look at the scrollback buffer.
I’m closer to you when doing more dev work. One tab running a watcher for builds and restarting the app, one tab to run tests or whatever, a couple for poking around if I need to grep or curl or whatever.
I set the framework key in function row to pop a new terminal. It's amazing.
For every query and commands. I don’t use a DE, so pretty much everything is cli based. I use xterm and it’s bound to mod4+Return for me.
Maybe once a minute, though it's bursty so more like 4 times every 4 minutes, but I still didn't notice the nvm slowdown
Terminal, few times a day. Shells, every few minutes.
Is this poor man's Nix/direnv, or does it do anything else?
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.
I open and close terminals _constantly_, but I'm usually pretty weird in my workflow, so no comment on your first question.
I run a scrolling WM and have settled into a habit of opening terminals when I need them, then closing them right after. I'll open a terminal, git pull, close it. Etc. I also use a terminal that launches cold in 10-20 ms, so it's not like a pay a price for it.
This is actually what I thought this post was about! But then I saw the Ghostty reference, which, in my experience, is not very fast to launch at all. I got it opening new windows quickly by running the main process as a systemd service, but Foot launches way faster without all that fuss, and allows you to go the daemon route if you want it _even_ faster.
EDIT: Just want to clarify, no shade on Ghostty. That project is cross platform and uses the 100% defensible decision to use the full GTK stack on linux. Foot is Linux AND Wayland only, and uses that very restrictive environment to optimize the hell out of startup and general performance.
I constantly open and close terminals too. Maybe I'm doing a quick lazygit check on cwd. Maybe I'm opening up an ephemeral claude/codex session for a couple questions about why a test failed. Or quickly editing a file with vim. Or remembering where I put that file with yazi or fzf. -- I don't even know, but all of it is contingent on it being fast to open a new terminal in cwd.
So much so that I vibe-coded my own terminal emulator for vertical tabs on macOS (using libghostty for the terminals) that is faster and less weird than iTerm.
+1 for Foot, truly a joy to use.
It can affect shell subprocess startup time as well, which, depending on your setup and the tools you use, might be worth optimising for.
I don't remember when I did it, but it looks like I must have gone through this at some point (maybe due to using GNU Make a lot? Or perhaps it was some other tool) - my zsh setup does a bunch of autocomplete setup only in the interactive case, and it seems to help a bit with startup time, at least on macOS:
For the interactive case, I don't really mind (within limits - the worst case, on macOS after a reboot, takes several seconds, and that's tedious). I also start new interactive terminal sessions fairly rarely.Maybe, but notice that almost all of the article, and its followup posted today, is about the speed of starting a shell not of a terminal emulator window. So if you use interactive sub-shells, anything from shelling out of a vi clone or mailx, through :terminal in NeoVIM, to running tmux/screen or script, then the concerns are relevant.
That said, it is almost totally about the Z shell. So you might still qualify as 'weird' in this case on the alternative grounds of not using the Z shell. (-:
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.
> But if your terminal can't keep up with your typing speed there is something deeply wrong with it. For the poor sools that had to work in VDI with radio link...
I open terminal far more often than that. But you should also remember that the startup cost is also paid by some subshells, and any shell scripts you run (the actual cost will vary: which init files are sourced varies between interactive and non-interactive shells as well as login shells and non-login shells, but it won't be zero cost).
I only notice how efficient my terminal is if something dumps a ton of logs to stdout. Sure I can pipe to a file and use vim, but it's convenient not to need to do that. And sometimes I have like 8 things going at once.
I'd say your workflow is pretty typical, from what I am seeing.
Developers that are very heavily invested in terminal and (over) optimize their terminal configuration are a small but very vocal minority.
I do the same, so there's a good chance you're (we're) the weird one
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).
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!
I'm the creator of Ghostty. This isn't right. It should idle at 0 to 1%, as supported by sibling comments. If you can collect more details about your system please open a discussion on the main Ghostty repo. Same with memory.
In terms of speed, same thing: if you can provide some kind of objectively measurable thing, we can look into it. Everything we've measured so far firmly places Ghostty in the "fast" camp (with friends such as Kitty).
We're sometimes faster, sometimes slower, but in any case not noticeably so. You wouldn't pick Ghostty vs Kitty for example for performance, it'd be something else. But you would pick Ghostty over say... iTerm2 for performance (but you may pick iTerm2 for features, its extremely feature rich!).
> Just sitting there idle it’s pulling a constant 40% of my CPU? No thanks!
You need to figure out what is going on because that certainly isn't normal.
Literally seeing 0.0% on Linux
I suspect you enabled some weird setting that you've forgotten about. ghostty isn't unimaginably fast but it's faster than iTerm 2 which is plenty. And I'm sitting here with a lengthy Claude Code session open, as well as a couple tabs for my docker container and dev servers, and its idle CPU usage is 0.0%.
WezTerm is great too and, AFAICT, is everything Ghostty wants to be. Kitty is also very good, although WezTerm edges it out for having an integrated muxer.
I can't understand Ghostty either except as some kind of trendy memetic thing, the $GME of the TTY world.
Yup. For a while I was switching between all three to see which I liked most, and I always end up coming back to Wezterm. The only issue I’ve encountered is that releases on various package managers are routinely broken, but building from source solved that.
My ghostty is using 0.4$ - 2.5%?
I know ghostty is designed to be super high performance but I find it both uglier and slower than Iterm2!
I started using it expecting to love it, but in reality it didn't seem to gain me anything but in fact was worse in several major ways. Also less configurable than Iterm2. :/
That happened to me too, turns out my desktop was software accelerated because I had screwed up the GPU config somehow. I asked Claude to fix it and it did.
This. Ghostty is significantly slower than Kitty on my Arch setup. It's still fast enough I guess, but no reason to switch from Kitty for me.
Software accel?
Not that slow. It's certainly a bit faster than, say, VTE, and maybe even quicker than Wezterm, Kitty just feels faster when rendering editors or TUIs with a lot happening...
Follow up / errata post written by the author today: https://mijndertstuij.nl/posts/what-i-got-wrong-about-fast-t...
30ms is pretty slow
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!
If you like that, you should check out my project https://beachcomber.sh . Its about time I take it from dogfooding to beta users if you want to give it a go.
Life is too short to waste time on things that don't matter.
Maybe I should remove the following bit of code from my profile?
It's a whole chain of interpreters firing up (sub-shells, Perl for the cow, Ruby for the lol, I think.) :DBut what would life be without a little bit of fun?
That's why you should optimize only the things that matter to you.
"I tell you, we are here on Earth to fart around and don't let anybody tell you any different."
— Kurt Vonnegut
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.
foot is great, I have yet to use anything better. I suspect Ghostty is aimed at part-time and full-time Mac users. I don't get the hype.
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.
"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
"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
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."
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
To be clear, I only use the VGA driver,^1 I do not use it to display non-text graphics, e.g., images, and I do not use a framebuffer on NetBSD^2
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 do not use a graphics driver.
Yes you do. It's the one that your in-kernel terminal emulator talks to in order to splat its bitmap fonts onto the screen. It is whatever wsdisplay has attached to, which can be one of a range of things from genfb through voodoofb and machfb to radeonfb. There was even a vesafb about 20 years ago.
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
To be more clear, I use a "graphics driver" but only in textmode. Perhaps a better statement would be "I do not use a graphics mode"
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 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
> Thus I don't use a terminal emulator.
Yes you do. It's the one built into your operating system's kernel. You'll find a lot of, but not all of, its code in /usr/src/sys/dev/wscons .
On NetBSD, I don't use a framebuffer
I use the vga driver which does not do graphics
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.
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.
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.
Life is also too short for the three weeks I then spent configuring it.
Notice a lot of the article was about completions, which fish shell does better than zsh.
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.
Life is too short to use slow and problematic system, Linux forever.
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!
[dead]
[flagged]
> 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 what a person does during the day is mainly interacting with text then they need a tool for working well with text. Possibly this is an editor window inside an IDE. Possibly this is a shell in a terminal emulator. However, dismissing GUIs out of hand and asserting superiority of CLI is wrong. Far more disciplines need a GUI to get maximum utility from their computers than can get by with a CLI. Designers, architects, actual engineers, artists, lawyers, etc.
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.
In a Turing machine theory, a GUI application can do all the same things a terminal application can do.
In practical design, GUI applications inevitably deprecate keyboard abstractions in favor of graphical abstractions and graphical abstractions require parsing visual representations and are less conducive to "muscle memory" whenever pointer control is relative rather than absolute (which these days is approximately always [1]).
Keyboard oriented applications feel more like a language and human brains tend to map well to language and touch typing while GUI's rely on something akin (or identical) to hand-eye coordination. Hand-eye coordination is harder than touch typing and every GUI application requires developing a unique mental model.
[1] in the ancient days of digitizing tablets with absolute coordinates, it was possible to "touch mouse." But that's not how we do things today (and it would not work well with infinite scrolling, etc.)
I happily used a small Wacom graphics tablet as a mouse for a long time. Thanks for the memories, I’d nearly forgotten.
Terminal tools are nice because keyboard shortcuts and text commands are quicker than clicking through menus and pressing buttons. For certain types of work (programming for example) this is much quicker and more comfortable than GUI interfaces.
Of course, other tasks are nicer with a GUI and/or mouse/tablet/touchscreen (art creation for example).
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.
"gui"? what gui?
my take is terminal is just quicker than "gui".
All other things being equal, GUI apps are not usually composable - the unix philosophy lets you do a lot by not solving every problem yourself.
Depends on what you grew up on/learned I think. CLI was the only thing around when I learned so that's still what I prefer. It's one of those things where I think you use the tool that you are proficient with. No right or wrong, just different strokes for different folks.
I think, for folks who grew up in the early 2000’s at least, CLI is the way to go forward. The GUIs at the time were really quite good, it was after the really limited time of the 90’s, but before we started dumbing down GUIs for… I dunno, style I guess.
If you were raised on programs where most of the features were accessible at a button-click, without going through a bunch of hamburgers, modern GUIs won’t feel familiar, CLI will.
a hype that lasts since the 70s can it be called a hype ?
it's common as a junior to think in such a way
echo $bait > /dev/null 2>&1
Meh. I take typing commands in the terminal over clicking stuff with a mouse and learning keyboard shortcuts for every app.
Skill issue.
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.)