For me tmux ended up being the solution for my dev needs. With a little bit of time, I learnt the ropes and became more or less productive with the default setup. Afterwards, I made it my own.

Like you mention, tmux sessions was one of the biggest features that I enjoyed about this tool: it does the job and does it well. Aside from that I love that I can use Vim-bindings with it, that it feels very similar to Neovim for me, so using them together is a no-brainer. Learning a couple of specific keyboard shortcuts is all it takes to make me productive.

I haven't needed to use a remote session yet like you note. While working with tmux locally I have learnt about all of these other features that I will definitely be looking forward to using once the opportunity arises.

I don't doubt that tools like ghostty, Alacritty, or WezTerm are great. I have heard lots about the first two. And I do intend to check them out.

What would you say is your favorite terminal and why as it relates to local development experience use? Are there features that these tools have that tmux lacks?

▲ godelski 6 days ago | parent [-]

  > What would you say is your favorite terminal

So far, ghostty. I do also like Alacritty and WezTerm, and think kitty is overhyped (and Warp is a privacy nightmare). A thing I really like about ghostty is it is incredibly easy to maintain. By far my smallest config file. Basically my theme and a few custom bindings. To be honest, there isn't a huge difference between all of them, with some being better at one thing than another, but I think ghostty gets things good all around.

Btw, vim bindings should already be available in your emulator, without the need for tmux. You can set bash to use them (set -o vi) but I suggest migrating to zsh if you like using the cli. I'll also give you one fun command most people don't know. While holding control, press x then e (if you are already using zsh you might need to add `zle -N edit-command-line` to your rc file but <C-x><C-e> needs no config in bash). I guess I should also mention that in vim you can open a terminal (:help term)

  > why as it relates to local development experience use?

All these emulators can do, locally, everything tmux can do and more. You just have to remember that a session is the same thing as a window. All these emulators have tabs and splits. So there is no real advantage to tmux.

  > Are there features that these tools have that tmux lacks?

First off, switch because your emulator is probably more resource intensive. It may also be missing modern features like being able to view images (see sixel, chafa, or the kitty graphics protocol), ligatures, and a lot of other features.

Second, tmux lacks many of these modern features. Doing a passthrough can help but dealing with images is not a great experience. I have found no configuration where I can reliably view images and never have been able to produce images of the same quality. I always drop out of my session if I am entering a file browser like yazi or fzf (I'll use fzf but it limits the capabilities of previewing).

▲ grep_name 6 days ago | parent | next [-]

I feel compelled to reply, because a lot of this contradicts my experience. I use wezterm + tmux on linux, iterm + tmux on mac. (Already an advantage there, tbh)

> vim bindings should already be available in your emulator, without the need for tmux

They may mean things like the vim-tmux navigator plugin, which makes it so if you hit e.g. the left-most window in vim and hit your go-left keybinding, it will go one tmux pane to the left. It's pretty crazy how seamless it is, and it's made possible by the fact that you can query tmux outside of the process and run commands on your running sessions, which I'm not sure you can do with any of the standalone terminals?

Tmux also doesn't prevent you from using c-x e. I'm aware of the vim terminal, but I'm very picky about my multiplexing and have not been satisfied by any built-in terminal in any editor.

> You just have to remember that a session is the same thing as a window.

A session is certainly NOT a window. It is a buffer. There is a difference, and that difference matters and comes with advantages that are separate from the advantages of windows.

> First off, switch because your emulator is probably more resource intensive

I'm not entirely sure if this is true, but it's utterly uncompelling to me. Holding my binding for 'switch window' will switch through n windows faster than I can mentally digest, and the lag is lighter than any gui app I've used.

> It may also be missing modern features like being able to view images (see sixel, chafa, or the kitty graphics protocol), ligatures, and a lot of other features

I'm not sure why you'd assume this? My setup (wezterm or iterm + tmux + fira code) indeed has ligatures and sharp image viewing passed through the multiplexer

> Second, tmux lacks many of these modern features. Doing a passthrough can help but dealing with images is not a great experience. I have found no configuration where I can reliably view images and never have been able to produce images of the same quality. I always drop out of my session if I am entering a file browser like yazi or fzf

Yazi is exactly what I use, and it works great with iTerm + tmux or wezterm + tmux.

I really don't want my terminal to do that much for me to be honest. I change terminals every couple years, and it's nice to not have to fuss around with them whenever that happens. I haven't changed my tmux config in about 15 years

▲ EPendragon 6 days ago | parent | prev [-]

Appreciate the detailed answer! I will need to take a look at different terminals to see if there is any other one that can better fit my needs.

I prefer the idea of having one tool to manage everything: from local flow to remote sessions. And I usually do not view images in the terminal. But I'm willing to put them to the test and see if I like one of those more.

	▲	godelski 6 days ago \| parent [-]
		`> I prefer the idea of having one tool to manage everything: from local flow to remote sessions.` This is still achieved. But as outlined here and elsewhere, a single extra keypress is not so much a hindrance as it is a reminder of be being local vs remote. I'll add that your muscle memory will adapt to whatever pretty quickly. Like I was switching between a mac and a linux machine with a keyboard frequently and it only took a week to forget where my pinky needed to go to hit ctrl. Same is true even if your bindings for whatever are not identical local or remote (though mine are very similar, just differing in the prefix). So I'd say when testing things make sure you include a burn-in time, otherwise any change is going to make all other options feel worse. `> I usually do not view images in the terminal.` I work in computer vision (ML) so this is a very useful feature. But given that essentially everything else is the same, things don't really feel that different when remote vs local. Just a little purposeful visual indication and a different prefix (which is on purpose).