3 ms·

This. To add some words why this is important: Given the remote-first container-based world we're heading towards, decoupling UI (terminal emulator) from its "

This. To add some words why this is important: Given the remote-first container-based world we're heading towards, decoupling UI (terminal emulator) from its "backend" (tmux, code-server) is a great design decision, which I think will ultimately define what the "next generation" of terminal emulators is. Imagine being able to open tabs directly on remote host, reconnect without losing state, etc, all while using native UI (so Cmd+T to open new tab, Cmd+F to search, etc). Productivity game changer, which currently only the iTerm2 users can fully enjoy. Ptyxis (putting its backend in running containers), WezTerm (native handling of ssh sessions) and VSCode's terminal (starting a proprietary code-server binary and connecting to its TCP port) have reached some of this functionality, but in their design they need some out-of-band mechanisms to handle the connections, ultimately limiting the scenarios they can handle. Meanwhile tmux -CC [0] and ht [1] are sending both their control channel and data channel over the opened terminal itself (in-band), making them flexible enough to support any configuration. Something complex like `ssh jumpbox -- ssh prod -- podman exec -it prod /bin/bash -- tmux -CC` should just work, as if everything was running on your local machine. [0] https://github.com/tmux/tmux/wiki/Control-Mode https://github.com/tmux/tmux/wiki/Control-Mode [1] https://github.com/andyk/ht https://github.com/andyk/ht

diggan 2y ago
> Given the remote-first container-based world we're heading towards You might want to expand on who "we" are here, because to me it seems to be a very small section of developers who want a "remote-first" experience and most (if not everyone) I speak with want software and tools that work local/offline-first, including our dear development environment. If a tool requires a internet connection to work (so this "remote-first container-based world" you mention), I don't think either me nor many of the developers I know would even give it a try, because we need to be able to use our tools regardless if we have a working internet connection and/or the service-provider has downtime. In fact, the only ones I know who are using a "remote-first" environment are developers who are forced to do so by their employer, and it's not a short-list of complaints about it when we meet over beers.
- pzmarzly 2y ago
  Good point, I also want things to work offline. By "remote" here I was also thinking of scenarios like: - Connecting from Windows/macOS host to a local VM - Connecting to a build server over LAN (I have a beefy PC but prefer to work from my couch) Both work offline just fine, but from tooling perspective you are connecting to remote host over the network
- nine_k 2y ago
  Not very small; most corporate non-Windows development uses containers, I'd bet on the ratio above 90%. Not that developers want remote-first experience, but they face it. Containers in this regard behave like remote systems, even when run locally. A tool that helps juggle multiple remote contexts in a sane way may be very helpful. Say, tmux does a lot to help, but more is of course possible.

diggan 2y ago

> Given the remote-first container-based world we're heading towards You might want to expand on who "we" are here, because to me it seems to be a very small section of developers who want a "remote-first" experience and most (if not everyone) I speak with want software and tools that work local/offline-first, including our dear development environment. If a tool requires a internet connection to work (so this "remote-first container-based world" you mention), I don't think either me nor many of the developers I know would even give it a try, because we need to be able to use our tools regardless if we have a working internet connection and/or the service-provider has downtime. In fact, the only ones I know who are using a "remote-first" environment are developers who are forced to do so by their employer, and it's not a short-list of complaints about it when we meet over beers.

pzmarzly 2y ago
Good point, I also want things to work offline. By "remote" here I was also thinking of scenarios like: - Connecting from Windows/macOS host to a local VM - Connecting to a build server over LAN (I have a beefy PC but prefer to work from my couch) Both work offline just fine, but from tooling perspective you are connecting to remote host over the network
nine_k 2y ago
Not very small; most corporate non-Windows development uses containers, I'd bet on the ratio above 90%. Not that developers want remote-first experience, but they face it. Containers in this regard behave like remote systems, even when run locally. A tool that helps juggle multiple remote contexts in a sane way may be very helpful. Say, tmux does a lot to help, but more is of course possible.