4 ms·

The next evolution of the terminal (text array of characters with positioning drawing escape codes) was the graphics array of pixels with drawing API calls. Th

The next evolution of the terminal (text array of characters with positioning drawing escape codes) was the graphics array of pixels with drawing API calls. The problem with graphics arrays is when you try to run them over a remote connection. For low bandwidth situations, you end up with hacks like downgrading to 8 bit color or disabling mouse-move events, both of which make some interfaces less usable. Then you also get the problem of scripting, where there isn’t a consistent way to deliver input to the applications. HTML and HTTP can be seen as yet another implementation of portable networkable user interfaces, and they are easier to script than graphical apps, but in the end, writing a web app or client is still a hundred times more effort than printing text on a terminal. Many people have thought of many ideas more advanced than terminals, but the terminals persist due to their superiority at just being simple, flexible, and fast. It is absolutely possible to “make a better terminal” though. But anyone who does has an uphill battle for adoption. (context: I was bound and determined to make a better terminal 20 years ago, but eventually gave up on the idea after getting familiar with existing tech and deciding it was good enough for me. Same with Bash, though I still think it’s a horrible language and should be replaced eventually)

0xCMP 5y ago
What I am mostly suggesting is iterative. We wouldn't switch to shipping graphics because as you say they're bandwidth intensive. RDP is not the right answer however useful it is for some things. But a shell+terminal hybrid focused on running processes, managing outputs, and making it easier for the user to run programs could do a lot of that remotely with a helper program similar to how tmux and git binaries need to be on the remote system. Or how vscode runs a fairly beefy system in order to support remote coding that not only allows editing code remotely with auto complete, but lets you launch multiple terminals to run commands. In a sense I'm really saying: we have like 80-90% of what a "modern" shell could look like in vs code remote... why can't we just make the shell like that? One thing which I do not have a good solution for is input because I don't know exactly how reliably a shell would know it's being asked for input from the application. The other thing being that I think this shell could support a legacy mode which is triggered by those escape codes, but most apps don't do that. As you said they just print text cause it's easy and fast. That's exactly what my python scripts at work do and a better shell that I suggest could handle plain text pretty easily. The issue is things like Vim, Emacs, Tmux, and other curses-like apps. But that could be a fallback rather than the happy path.

0xCMP 5y ago

What I am mostly suggesting is iterative. We wouldn't switch to shipping graphics because as you say they're bandwidth intensive. RDP is not the right answer however useful it is for some things. But a shell+terminal hybrid focused on running processes, managing outputs, and making it easier for the user to run programs could do a lot of that remotely with a helper program similar to how tmux and git binaries need to be on the remote system. Or how vscode runs a fairly beefy system in order to support remote coding that not only allows editing code remotely with auto complete, but lets you launch multiple terminals to run commands. In a sense I'm really saying: we have like 80-90% of what a "modern" shell could look like in vs code remote... why can't we just make the shell like that? One thing which I do not have a good solution for is input because I don't know exactly how reliably a shell would know it's being asked for input from the application. The other thing being that I think this shell could support a legacy mode which is triggered by those escape codes, but most apps don't do that. As you said they just print text cause it's easy and fast. That's exactly what my python scripts at work do and a better shell that I suggest could handle plain text pretty easily. The issue is things like Vim, Emacs, Tmux, and other curses-like apps. But that could be a fallback rather than the happy path.