The Terminal.app dilemma


macOS is a great operating system, but some of its default applications could benefit from modernization. This is the first in a series of posts that will explore some of these default applications and discuss alternative options that enhance the user experience.

Note: This post is coming from a macOS developer’s perspective. While I am familiar with both Windows and Linux, this post is specifically coming from a macOS perspective. I am aware that the default terminal on Linux is dependant on the desktop environment, and therefore this post is not a comparison between the default terminal on Linux and macOS, or how the terminal applications mentioned here work on various Linux distributions. This is only about how these applications work on macOS.

Terminal

The default terminal emulator on macOS is Terminal.app. While it is a functional terminal emulator, it is not a great experience when it comes to users (read developers) trying to optimize their workflow. Most articles on the internet will not mention the why behind “why Terminal.app is a horrible experience”, and well, that’s what this post is about.

Experience

The Terminal.app just works. It’s a terminal emulator, and it’s a functional terminal emulator. However, if you are like me and you thought that the hype of modernizing the terminal emulator was a “fad” and that the default terminal was a good enough terminal emulator, then this is for you:

Try out alternative terminal applications.

Thats all I can say. Try it.

I was of the opinion that the default terminal was good enough, and I was content with it. But, now that I’ve tried some alternative terminal applications, I can’t go back.

The Terminal.app just feels slow. Not that it is slow, but it just feels slow. Changing the feel of the terminal to make it seem faster is a great experience. This leads to one of my personal mantras:

The experience is everything.

Performance is important, but the experience is everything. So, changing the application to make it feel faster is a great net positive for your experience, and therefore your workflow. If you feel like you’re not limited by the tools you’re using, then you will be more productive.

Alternatives

There are a lot of alternatives to Terminal.app that are worth trying out. Some of them have nifty features (like GPU accelerated rendering), while others are leaning towards the “lets put AI into everything” approach. While I prefer my terminal to not be sending my logs to the cloud, I can see the appeal of some of the features that some of these terminal applications have to offer.

The following are some of the terminal applications that I have tried out, and the pros and cons of each one that I have tried.

Alacritty

Alacritty is a terminal application that is built on the idea of being a modern terminal emulator. It is built on the Rust programming language, and it is a terminal emulator that is built for the modern age.

The experience of Alacritty is great. It is fast, it is customizable, and it is a great terminal emulator. The only downside is that it does not support tabs, and I have found that to be a bit of a pain. I use tabs to differentiate between tasks, and I while I do use tmux to manage multiple sessions, those (in my workflow) are generally used for doing different sessions within a project, rather than to switch between different projects. I am very well aware that this is a first-world problem, but it’s a problem that I have and it’s a problem that affects my workflow.

The configuration of Alacritty is also another thing that I liked. Digging through menus is not something that I enjoy doing, and Alacritty has a configuration file that is easy to understand and modify, and most importantly can be thrown into a github repository to version manage. I do put my dotfiles in a github repository, and I do not like having to dig through menus to change settings and reproduce my terminal environment on a new machine.

Overall, if the requirement of tabs was not a problem for me, then I would probably use Alacritty as my default terminal application.

Kitty

Kitty is yet another GPU accelerated terminal emulator. It’s different from Alacritty in that it extended on the basic terminal protocol. Two of the ones that I have ended up regularly using is the Terminal graphics protocol and Kittens.

The Terminal graphics protocol allows you to send graphics to the terminal, and kittens provide an extension of basica commands using the terminal itself. I have found myself using the Transfer File kitten to transfer files between local and remote machines a lot, and it has saved a lot of headaches.

Similar to Alacritty, Kitty’s configuration is also a configuration file. While the default configuration file can be a bit daunting to look at with over 2000 lines, it is very easy to understand and modify.

Kitty has a step up from Alacritty in that it supports tabs, and between the tab presence and kittens, I have found myself defaulting to Kitty as my terminal application. That doesn’t necessarily mean that this is the best terminal application for me, it’s just that it’s the one that I’ve found myself using the most.

Warp

Warp is a terminal application that is built on the idea of “AI Everywhere”. When I tried Warp, one thing that I immediately hated was the requirement to sign up for an account. As a person that tries to keep my data private, I don’t like the idea of having to sign up for an account to use a terminal application. That requirement immediately made me not want to try it out, and it was an uphill battle for Warp to get me to try it out.

There were some features that I liked about Warp, like the Warp Drive which allows you to share data in a manner similar to a Jupyter notebook, and Workflows which allows you to create custom “workflows” that are “parameterized commands for reuse” that can be searched with Ctrl-R keybinding.

However, the experience of Warp just felt slow. It felt like it was trying to be too much, and it was not a good experience. The additional reservations of not knowing if the data that I was sharing was being sent to the cloud was enough to make me not want to either put any sort of passwords in the terminal (which is a challenge when remoting into a server) or even use any commands that used my SSH keys (think git signing commits and ssh authentication).

It’s an interesting application, and I’m sure that it will get better over time, but I just don’t think that it’s a good fit for me.

Where does that leave me?

I have found myself defaulting to Kitty as my terminal application. This experience has made me rethink my workflow, and consider using something like Aerospace to manage projects instead of terminal tabs. That is a topic for another post, and something that I am currently exploring.

There are other terminal applciations that I’ve been meaning to try out, like WezTerm and Ghostty.

I’ll be sure to update this post with my thoughts on those applications once I’ve had the opportunity to rigorously test them out.

Copied to clipboard!