I was using iTerm up until about a week ago when I unboxed a new Mac and decided to test out alternatives while setting it up. Ghostty wasn't out yet so I started with Wezterm, and was shocked to find how much it's speed improved my terminal experience. Typing latency is much better in nvim, and scrolling is vastly improved in nvim and tmux.
Ghostty feels like a Mac app like iTerm2 while being fast and having fewer features. Wezterm feels more like an app ported from Linux, but has a much richer config system and features like build-in multiplexing which means it's replaced tmux for me - while keeping all my tmux keybinds.
Is iTerm2 noticeably slow? I just use the built in Terminal app and I can’t imagine “speed” being a reason to switch away from it. (There is no lack of speed.)
The reason I switched from iTerm2 is it took multiple seconds to resize a window on macOS. I use Rectangle to resize windows, and by default my shortcut for "put this window on the left half" cycles through window sizes when the window is already on the left. So a common workflow is to tap Hyper-J to move a window to the left half, then make it the left third, then the left two thirds of the screen. This is fine for any text editor or browser, but iTerm2 would beachball while I waited multiple seconds for it to resize the window.
No, iTerm is not slow. Ghostty is not noticeably faster in any of my workflows. I am sure Ghostty is faster in some use case, but it's nothing I regularly do or have noticed.
Same, I use it all the time and never perceived it as slow. I am not a tmux user, maybe the speed is noticeable when using more complex terminal apps like that?
Do you have a lot of triggers set up in iTerm 2? IMO that’s what kills performance.
I can understand being frustrated about latency on older Macs — I used to run Alacritty for certain tasks on my Intel Macs for that reason. But on newer Macs like a new M4 Pro I’m back to 100% iTerm 2 again. I can’t fathom having latency problems with iTerm 2 on a new Mac you just unboxed.
> It's one of those things that you don't realize how poor the performance is until you experience something better.
No, it’s one of those things I’ve tested myself extensively and arrived at my own conclusion. Which I already mentioned in the comment you responded to.
The performance talk is about ghostty, which you did not mention trying. You mention alacritty, which is GPU based and offers good performance, but you're quick to rebuttal on unrelated projects.
I'm still using the built in MacOS terminal. What am I missing? I mostly do webdev - maybe terminal features are more important for other types of programming?
Apple Terminal has a lot of problems. As others have mentioned, it lacks support for 24 bit color, enforces minimum contrast ratios without any ability to disable them (meaning you cannot set arbitrary color themes), is hopelessly bad at Unicode rendering (particularly with multi-codepoint graphemes, see [1]), and in general misbehaves in other myriad ways [2][3][4].
With both Ghostty and iTerm2 now freely available, there's really no reason to use Terminal.app.
Personally, my main reason to prefer Kitty over Terminal.app are (I believe Ghostty support all of them as well, so looking forward to try it out):
- “Kitty Keyboard Protocol” means that a TUI app can detect all keybindings. For example, if you install kkp.el in Emacs, then Emacs running in a terminal will pick up ctrl+shift keys, super keys, etc. on par with a GUI app. I believe NeoVim supports this out of the box now as well, so if you ever felt like binding Cmd+S to :w<cr> you now can.
- “Kitty Graphics Protocol” means that I can let e.g. Matplotlib show images inside a terminal, even over SSH connections. If you’re annoyed at pop-up GUI windows, or struggling with viewing remote images often, this is a nice workaround. There are even attempts at making terminal PDF viewers (like termpdf.py); IMO that’s a game changer, even though the app itself is still in a “proof of concept” stage IMO.
- Terminal splits. If you work a lot in a terminal, it’s nice to be able to full-screen a terminal and view many different shells or processes side-by-side. Last I checked, Terminal.app just doesn’t have this feature. Sure, you could use multiple windows or a multiplexer like tmux, but that comes with different trade-offs; for example, a native terminal offers smooth scrolling with a trackpad whereas tmux doesn’t. Personally, I use tmux remotely, but stopped using it locally.
- I see a lot of people mention 24-bit colors as a main reason to not use Terminal.app. For me, I’m actually pretending that I have a 16-color terminal, because I’m tired of having to theme every command-line utility individually, I’d rather they all just respect my 16 chosen colors instead. The only exception is my editor, just because there are unfortunately few good 16-color themes these days, so I instead change my terminal program to be consistent with my editor theme and then let every other TUI utility believe the terminal only supports 16 colors to match.
I appreciate you making an effort to visually display things, but FWIW I don't think that (or sibling) really gets to the root issue, which is less of capability then practical convenience and compatibility. Mac native Terminal perfectly well supports 256 colors (or arbitrary 16 colors with themes), which I've used, so you could absolutely make both sides look identical there. Unless someone is regularly viewing photos inside their terminal (which some do support and can actually sometimes be handy!) then it might not be immediately clear what 24-bit would bring to the table over 8-bit, regardless of editor or shell themes.
But in practice 24-bit was an easy lift for terminals under active development ages ago, and in turn made it trivial to have everyone across any platform specify exact colors more easily without any end user customization or arguments about "not quite what I wanted" in an 8-bit palette or whatever. Thus a lot of the ecosystem now makes use of it. Being able to replicate anything yourself, or get close enough, in a smaller colorspace is still extra grunt work for no particularly valuable reason, and could actually add up to be fairly significant work if one has a lot of more complex code coloring themes and such.
My example is precisely about practical convenience. If I try to do something very normal in Terminal.app, namely use a text editor with a theme, it will look like garbage.
You wouldn’t realize because 24-bit colors are silently dropped. You don’t get the full experience but you also won’t “run into any issues”, unless you start using something that relies on 24-bit color coding for core functionality, like my own log viewer.
