For my taste, Wezterm is much more configurable: I can change key bindings, mouse bindings, make custom actions/behaviors, write the config file anyway I want if at the end it generates the needed Lua table,... And it's not gonna stop here. The code is beautifully separated in layers, Rust is used at its best for terminal reading/interpretation..

The codebase is flexible: I could write my own frontend if I wanted or use the termwiz crate (included in the codebase) to build cli apps using the same nice layered architecture..

AFAIK Alacritty is not a multiplexer. Using something like tmux in Alacritty, makes the output slow (because tmux has its own buffer etc). I'm hoping that this doesn't have that issue because it is also a multiplexer.

Another issue I have with Alacritty is that it looks ugly on Wayland (because of lack of user window decoration), I'm not sure if this has somehow solved that issue (building against gnome or something).

I love Alacritty, but for my setup it doesn't work. Looking really hard for a fast and snappy replacement.

Alacritty should support window decorations on wayland. What compositor are you using? Note that alacritty prefers server-side decoration, but some compositors don't implement it like GNOME's mutter[1], in that case it will draw its own decorations.

1: https://gitlab.gnome.org/GNOME/mutter/-/issues/217

I'm using Gnome. And alacritty draws it's own decoration. But they are out of place and more importantly they don't behave like normal windows. For example to maximize a window normally I double click the title-bar but alacritty (I think it's winnit's fault) doesn't react to that. The button placements in the titlebar is also weird and needs me to be really accurate to click the close (x) button.

Yeah, you can blame CSD for that and mutters lack of supporting SSD.

A quick glance at the docs tells me this implements its own multiplexing all the way down, as opposed to integrating with tmux like iterm2 does.

The downside is that this requires installing the multiplexer on the remote machine, whereas iterm works with the much more prevalent tmux install.

Not sure what this means in terms of performance, I've never had any issues running remote tmux in alacritty or in iterm (via `tmux -CC`).

I don't have any use for running tmux locally, but I would sure love to be able to have actual windows for remote sessions (I use i3 and would prefer to manage all windows through that).

FWIW, wezterm is very slowly building support for `tmux -CC` as well: https://github.com/wez/wezterm/issues/336

tmux + alacritty seems perfectly fast for me, tmux's buffering really shouldn't slow anything down

Kitty as well.