5 ms·

Hard disagree. Make more TUIs! TUIs have downsides like accessibility, poor mouse support, but work really well if you focus on keyboard input. It is a better/

Hard disagree. Make more TUIs! TUIs have downsides like accessibility, poor mouse support, but work really well if you focus on keyboard input. It is a better/faster input mode to begin with, especially for power users, but also for average people; you'd be surprised at how much more user-friendly an arrow-keys driven UI can be vs modern web interfaces. I've been building my own TUI framework [1] and getting amazing results. Good TUIs are more of a GUI than a dumb text terminal. If we had a cross-platform usable GUI framework, and more consistency across OSes, the story would be different. [1] https://github.com/ricardobeat/milktea https://github.com/ricardobeat/milktea

a2ff6eeb0 2mo ago
GUI programs can also use the keyboard.
- boredatoms 2mo ago
  A lot of us do the vast majority of our non-browser work on remote systems. GUIs are objectively bad for this
  - rgzz 2mo ago
    Well in plan 9 they work fine remotely so I wouldn't say they're objectively bad.
  - bmitc 2mo ago
    Terminal programs are GUIs. So you are using a GUI to access those remote systems. Thus, there's no reason why another GUI couldn't do the same. Everyone always acts like GUIs couldn't possibly make HTTP requests, interact over TCP or WebSockets, or do other remote communication. But they're actually, more often than not, more well suited for that than browsers for specific use cases, which are the use cases where you'd desire a devoted GUI.
    - wormius 2mo ago
      I'll stick with plain old TTY Consoles, thank you.
      - deleted 2mo ago
        [deleted]
      - bmitc 2mo ago
        Okay?
  - jayd16 2mo ago
    That's an indictment of ssh workflows not GUIs. RDP works fine but it's based on a full desktop experience. Despite having the technology, we don't have the ability to remote in and run a single graphical program in a single window with the same ease. We need something as seamless as Parallels for remote remote apps. But I guess we just settled on web apps.
    - bionade24 2mo ago
      Of course there is, waypipe, ssh -X, wayVNC on a headless cage (or sway with appropriate config) session.
      - jayd16 2mo ago
        Again, we have the technology but it's not how things are done, usually. What do you run like that day to day?
        bionade24 2mo ago
        I use waypipe casually if I have a project on my desktop that I want to work on from my laptop. I even use if I just want to get a Bookmark or Tab from the Desktop PC, since I never bothered to set up any syncing service. Only for nvim I use it's own client/server implementation, it's a bit less latency-affected by the 1%s. Waypipe is production ready & easy to use. If there doesn't exist a program making use of it for the average user, then it's because nobody saw a it as a solution for any occurring problem yet.
    - andrewshadura 2mo ago
      RDP can do a single app.
  - deleted 2mo ago
    [deleted]
  - tbrownaw 2mo ago
    I use an xrdp quite a lot. It works fine.
  - pjmlp 2mo ago
    X Windows was invented on the 1980's and isn't the only way to graphically access remote systems. Modern cloud systems shouldn't even have shell access, immutable containers with telemetry data.
    - misterderpie 2mo ago
      > Modern cloud systems shouldn't even have shell access, immutable containers with telemetry data. Genuine question, what is your alternative suggestion to accessing lower level features then? A hard time I have with GUIs is that their input/output can't be piped. It's much more cumbersome to try to automate a GUI than to automate something in the terminal. Whilst I get that this is about TUIs, I do believe there is a reason for shell access due to automation. Good abstractions can be put into the GUI, but I'd argue that you should first build the abstraction, then put a GUI on top of it. AWS is a prime example, any of their APIs can be used w/out AWS Console.
      - MisterTea 2mo ago
        Look at Plan 9's devdraw. https://man.9front.org/3/draw https://man.9front.org/3/draw devdraw can be thought of as a 2D rendering engine. You load assets like text, bitmaps and so on then issue draw commands to render them. There is no SSH. Instead you connect to a remote machine and export resources served by your local machine including your keyboard, mouse and display, each of which is a network transparent microservice. The window manager, Rio (and others), multiplexes access to these microservices. You can run a graphical program without a window manager, e.g. you can boot right into Doom or the Acme editor. It's seamless and can run over any pipe that can push 9P including ssh. If you look at the Sam and Acme text editors you will find they are true modern TUI programs. Shame we had a cloud ready OS for 35+ years and no one noticed. Instead were living in the 60's with GPU accelerated typewriter emulators.
        pjmlp 2mo ago
        That one was going to be commercial, hence why. However I would rather prefer its successor, with Limbo for userspace, although probably not Tk as the main UI toolkit. The terminal thing emulating typewriter are a UNIX thing, as other graphical OSes, presented a plain REPL, or graphical shell, e.g. Amiga DOS did not emulate any tty. Otherwise I agree with the spirit of the comment.
  - ameliaquining 2mo ago
    The article anticipates and responds to this: https://sockpuppet.org/blog/2026/08/20/stop-making-tuis/#:~:text=Next%3A%20TUIs%20work,LSPs%20and%20Magit. https://sockpuppet.org/blog/2026/08/20/stop-making-tuis/#:~:...
  - a2ff6eeb0 2mo ago
    You can run Wayland that renders into a terminal. https://github.com/cyber-wojtek/waytermirror https://github.com/cyber-wojtek/waytermirror
  - okanat 2mo ago
    No. When the communication side is actually done thoughtfully, GUIs deliver superior experiences even in remote environments. VSCode SSH extension is one of the most widely developer-used proof against this. Windows' RDP is the other one where many engineers and POS personnel have experince using them. Many electrical and mechanical engineers still use Windows RDP at my work to run simulations. The connection is responsive enough to survive their home-to-office VPN connection. I set up complex chemical simulation software that is accessed by clients of a HPC cluster over 1000s of kms away. VScode has a really efficient protocol that communicates only that's required, Windows RDP can declaratively send UI component changes as long as one uses Win32 or WPF. It can also reasonably compress the data to even survive dial-up levels of bad data. We use multi-attendant video conferencing day to day with whiteboarding extensions. If there is will, efficient and amazing remote-GUIs are easy.
- chiph 2mo ago
  Depends on whether the devs included keyboard accelerator mappings. With the rise of "touch focused apps", it's becoming rare.
  - vikramkr 2mo ago
    Sure but in this case we're the devs. We're in charge of that and would include them if we're making a gui instead of a tui and want keyboard accelerator mappings.
leephillips 2mo ago
I’ve been enjoying making TUI programs for my own use. It turns out that the Kitty terminal emulator, with its saveable sessions of arrangements of panels that can communicate with each other, is an interesting framework for TUIs: https://lwn.net/Articles/1080821/ https://lwn.net/Articles/1080821/
hylaride 2mo ago
Yeahs ago I remember when my big bank switched from a TUI front end to a web front end for their front line staff. What originally took a few quick keyboard/tab combinations that was hard wired into employee muscle memory immediately took 2-3 times longer. Fortunately, the need to go into a physical bank doesn’t matter as much, but it’s still a regression…
- chiph 2mo ago
  I saw the same thing at Best Buy. They switched from a traditional cash register to a web application on a PC. And all the clerks carefully (and slowly) navigated their mice to click on everything. What was worse was their mouse platform wasn't level. So every time they let go, it would drift downwards and they'd have to go through the "where's my mouse pointer" wiggle again.
- api 2mo ago
  The truth is that the web is a shit GUI framework. It's slow, clunky, incredibly resource intensive, hard to make uniform, verbose to code. It's terrible. The way the whole industry adopted it is understandable given the install base, but it's also probably a trillion dollar tax. I'd hate to see how much additional energy is used by billions of end-user devices running a rendering layer that is 100X heavier and more CPU intensive than anything native or TUI.
  - em3rgent0rdr 2mo ago
    Not if you just stick to the basic built-in 30-year-old HTML GUI elements (<button>, <select>, <legend>, <form>, <input>, <table> for layout, etc., maybe also some modern standards like flexboxes) which are very fast, lightweight, east to code, and uniform. The problem to me is every website tries to do some custom javascript monstrosity with their own graphics to keep up with the latest fad. When just sticking to the basics, I find the web is a great cross-platform GUI framework.
    - ezekiel68 2mo ago
      Sure. Except that nobody ever does just stick to those elements.
hedgehog 2mo ago
It's not hard to make a portable UI framework if you accept similar limitations to the terminal (limited OS integration, accessibility support, etc). You can do anything you want and ship it through RFB.
mawadev 2mo ago
Plus, when you ssh into a server and don't want to or can't rdp it, you at least have more degrees of freedom when you juggle complicated commands, like k9s
01100011 2mo ago
I have old wrists, essential tremor and tics. I try to avoid the mouse where possible. Yes, please make more TUIs!
wowczarek 2mo ago
> If we had a cross-platform usable GUI framework I could swear there once was a (n)curses or otherwise text based GTK+ implementation / backend. It didn't do everything of course, and this was, I don't know, about 2003-2007, but you could compile a GTK application and run it in the console. I tried finding a link, but unfortunately could not, can't even remember the name, I only remember building a piece of software that way that did GUI or TUI depending on how it was linked.
- guessbest 2mo ago
  Could you be thinking of libyui, but it was QT and ncurses based. I think it came from SuSE with YaST. https://github.com/libyui/libyui https://github.com/libyui/libyui https://yast.opensuse.org/ https://yast.opensuse.org/
grepps09 2mo ago
[dead]
63 2mo ago
When you're one of the people who finds TUIs inaccessible, "accessibility" isn't just a downside to be considered, it's table stakes. I think they're fine for one off toys for individuals and small groups, but if you're selling a product to the public, it ought to be accessible first and foremost.
- rererereferred 2mo ago
  That just means you have a potential userbase for an alternative for non-TUI people. If the market is that big, why not take it for yourself?
  - VanTheBrand 2mo ago
    We should get rid of ramps and handicapped parking at grocery stores too. If it’s such a large market someone can start their own accessible grocery store…
0x3444ac53 2mo ago
Yeah TUIs are great. I'm shit at making GUIs but I was able to slap together a relatively simple TUI for some tooling at work, without any AI. Cheaper, faster, cross platform, less intensive. Most TUI frameworks nowadays have mouse support as well etc. So what if it looks just a little dated?
grepps09 2mo ago
I'm very keyboard-driven but I never really got TUIs. A GUI litterly can have just as good keyboard support, but because it doesn't force the user to use it, they rarely take the time to learn it. It's just always tempting to take the path of least resistance. Especially becuase TUIs doesn't really have any of good properties that a CLI offers such as composebility. It's still a fixed UI with panes and menus which has just been squeezed into a character grid, and now forces the user to learn its pre-set keyboard bindings (which surely can be changed, but with every app having it's own config managment). It's kinda the worst of both worlds to me. Either go all in and give me a proper text-based interface like Emacs (where you can globally configure how you wanna deal with lists of text in buffers), or just make a proper GUI with good keyboard support.
- t098i3 2mo ago
  They made a ton of sense back when the cost difference between a basic text-only terminal and a full-color multimedia PC was significant when multiplied over all of your employees.
- samspot 2mo ago
  At least with a TUI you know 100% it works with the keyboard. This is not something you can safely assume about any GUI, on the web or otherwise. Our accessibility team is kept very busy by this fact.
MisterTea 2mo ago
> Hard disagree. Make more TUIs! My big beef is the dichotomy of today's GPU accelerated bit-mapped displays which are burdened with this silly task of running a program that emulates a typewriter. Why TF do we not have a display protocol that can do graphics natively over SSH in 2026? > TUIs have downsides like accessibility, poor mouse support, but work really well if you focus on keyboard input. This assumes a typewriter emulator. Why are we not working on graphical systems where text is a first class primitive allowing us to easily draw text in any color, font, size, formatting and orientation as we please, onto a GPU accelerated display? Keyboard can still reign supreme. No mouse needed but if it is - first class support unlike crappy typewriter emulators.
- utilize1808 2mo ago
  > Why TF do we not have a display protocol that can do graphics natively over SSH in 2026? Did you mean X server?
  - MisterTea 2mo ago
    Plan 9 devdraw which is really nice: https://news.ycombinator.com/item?id=49384210#49404622 https://news.ycombinator.com/item?id=49384210#49404622. X is well past its sell-by date. Plan 9 is text first as it was written by Unix programmers who wanted to build an OS and write programs (Rob wanted a better text editor.) It's the OG TUI. Window managers like Rio can run in Rio. You control things by writing textual messages from the command line, scripts, or code, e.g 'echo 100 >/dev/volume' to set audio volume to 100%. Someone wrote a new WM called Lola so I ran Lola in Rio in Lola in Rio because I can. Sam is very much a keyboard driven modern TUI ed (the standard editor). Acme is a mouse driven TUI editor. Both can be automated by programs and scripts. You can edit text while reading your email and chatting on irc from within Acme. BUT Lots of stuff missing. We don't yet have GPU accel. It's a MSSIVE undertaking. And it has to be carefully designed and would likely be a built around a generalized devcompute kernel device.
- inigyou 2mo ago
  We do it's X11
ordu 2mo ago
I don't use TUI when I can avoid it. I happily use CLI apps, or GUI apps, but TUIs are not here, not there. They lose all the appeal of CLI apps, while getting some weird text interface instead of a polished GUI library and all the possibilities that you can get from rendering pixels, not characters. When I moved from DOS to Linux, I chuck away TUI file managers and switched to pure CLI and never looked back. I could use GUI file manager, there you can really use mouse, without that jumpy-movements it has in TUI apps. But I wouldn't touch Midnight Commander or whatever. I tried to run emacs in a terminal. Emacs' support of GUI toolkits is very cumbersome thing. But guess what forced me to abandon this experiment? Emacs is keyboard-driven, and terminals have issues with some keys, while GUI apps can deal with virtually anything. > If we had a cross-platform usable GUI framework, and more consistency across OSes, the story would be different. Try egui. I really like it. I'm not sure how much it is cross-platform though, hadn't tried it outside of Linux, but it is really nice. Or if you are an elm-purist then iced might be your choice. Iced lacks on widgets, it has just some basic ones, and if you need something to render a 2d-plot, then you are on your own.
inigyou 2mo ago
Nothing stops you making a keyboard-driven X11 app.

a2ff6eeb0 2mo ago

GUI programs can also use the keyboard.

boredatoms 2mo ago
A lot of us do the vast majority of our non-browser work on remote systems. GUIs are objectively bad for this
- rgzz 2mo ago
  Well in plan 9 they work fine remotely so I wouldn't say they're objectively bad.
- bmitc 2mo ago
  Terminal programs are GUIs. So you are using a GUI to access those remote systems. Thus, there's no reason why another GUI couldn't do the same. Everyone always acts like GUIs couldn't possibly make HTTP requests, interact over TCP or WebSockets, or do other remote communication. But they're actually, more often than not, more well suited for that than browsers for specific use cases, which are the use cases where you'd desire a devoted GUI.
  - wormius 2mo ago
    I'll stick with plain old TTY Consoles, thank you.
    - deleted 2mo ago
      [deleted]
    - bmitc 2mo ago
      Okay?
- jayd16 2mo ago
  That's an indictment of ssh workflows not GUIs. RDP works fine but it's based on a full desktop experience. Despite having the technology, we don't have the ability to remote in and run a single graphical program in a single window with the same ease. We need something as seamless as Parallels for remote remote apps. But I guess we just settled on web apps.
  - bionade24 2mo ago
    Of course there is, waypipe, ssh -X, wayVNC on a headless cage (or sway with appropriate config) session.
    - jayd16 2mo ago
      Again, we have the technology but it's not how things are done, usually. What do you run like that day to day?
      - bionade24 2mo ago
        I use waypipe casually if I have a project on my desktop that I want to work on from my laptop. I even use if I just want to get a Bookmark or Tab from the Desktop PC, since I never bothered to set up any syncing service. Only for nvim I use it's own client/server implementation, it's a bit less latency-affected by the 1%s. Waypipe is production ready & easy to use. If there doesn't exist a program making use of it for the average user, then it's because nobody saw a it as a solution for any occurring problem yet.
  - andrewshadura 2mo ago
    RDP can do a single app.
- deleted 2mo ago
  [deleted]
- tbrownaw 2mo ago
  I use an xrdp quite a lot. It works fine.
- pjmlp 2mo ago
  X Windows was invented on the 1980's and isn't the only way to graphically access remote systems. Modern cloud systems shouldn't even have shell access, immutable containers with telemetry data.
  - misterderpie 2mo ago
    > Modern cloud systems shouldn't even have shell access, immutable containers with telemetry data. Genuine question, what is your alternative suggestion to accessing lower level features then? A hard time I have with GUIs is that their input/output can't be piped. It's much more cumbersome to try to automate a GUI than to automate something in the terminal. Whilst I get that this is about TUIs, I do believe there is a reason for shell access due to automation. Good abstractions can be put into the GUI, but I'd argue that you should first build the abstraction, then put a GUI on top of it. AWS is a prime example, any of their APIs can be used w/out AWS Console.
    - MisterTea 2mo ago
      Look at Plan 9's devdraw. https://man.9front.org/3/draw https://man.9front.org/3/draw devdraw can be thought of as a 2D rendering engine. You load assets like text, bitmaps and so on then issue draw commands to render them. There is no SSH. Instead you connect to a remote machine and export resources served by your local machine including your keyboard, mouse and display, each of which is a network transparent microservice. The window manager, Rio (and others), multiplexes access to these microservices. You can run a graphical program without a window manager, e.g. you can boot right into Doom or the Acme editor. It's seamless and can run over any pipe that can push 9P including ssh. If you look at the Sam and Acme text editors you will find they are true modern TUI programs. Shame we had a cloud ready OS for 35+ years and no one noticed. Instead were living in the 60's with GPU accelerated typewriter emulators.
      - pjmlp 2mo ago
        That one was going to be commercial, hence why. However I would rather prefer its successor, with Limbo for userspace, although probably not Tk as the main UI toolkit. The terminal thing emulating typewriter are a UNIX thing, as other graphical OSes, presented a plain REPL, or graphical shell, e.g. Amiga DOS did not emulate any tty. Otherwise I agree with the spirit of the comment.
- ameliaquining 2mo ago
  The article anticipates and responds to this: https://sockpuppet.org/blog/2026/08/20/stop-making-tuis/#:~:text=Next%3A%20TUIs%20work,LSPs%20and%20Magit. https://sockpuppet.org/blog/2026/08/20/stop-making-tuis/#:~:...
- a2ff6eeb0 2mo ago
  You can run Wayland that renders into a terminal. https://github.com/cyber-wojtek/waytermirror https://github.com/cyber-wojtek/waytermirror
- okanat 2mo ago
  No. When the communication side is actually done thoughtfully, GUIs deliver superior experiences even in remote environments. VSCode SSH extension is one of the most widely developer-used proof against this. Windows' RDP is the other one where many engineers and POS personnel have experince using them. Many electrical and mechanical engineers still use Windows RDP at my work to run simulations. The connection is responsive enough to survive their home-to-office VPN connection. I set up complex chemical simulation software that is accessed by clients of a HPC cluster over 1000s of kms away. VScode has a really efficient protocol that communicates only that's required, Windows RDP can declaratively send UI component changes as long as one uses Win32 or WPF. It can also reasonably compress the data to even survive dial-up levels of bad data. We use multi-attendant video conferencing day to day with whiteboarding extensions. If there is will, efficient and amazing remote-GUIs are easy.
chiph 2mo ago
Depends on whether the devs included keyboard accelerator mappings. With the rise of "touch focused apps", it's becoming rare.
- vikramkr 2mo ago
  Sure but in this case we're the devs. We're in charge of that and would include them if we're making a gui instead of a tui and want keyboard accelerator mappings.

leephillips 2mo ago

I’ve been enjoying making TUI programs for my own use. It turns out that the Kitty terminal emulator, with its saveable sessions of arrangements of panels that can communicate with each other, is an interesting framework for TUIs: https://lwn.net/Articles/1080821/ https://lwn.net/Articles/1080821/

hylaride 2mo ago

Yeahs ago I remember when my big bank switched from a TUI front end to a web front end for their front line staff. What originally took a few quick keyboard/tab combinations that was hard wired into employee muscle memory immediately took 2-3 times longer. Fortunately, the need to go into a physical bank doesn’t matter as much, but it’s still a regression…

chiph 2mo ago
I saw the same thing at Best Buy. They switched from a traditional cash register to a web application on a PC. And all the clerks carefully (and slowly) navigated their mice to click on everything. What was worse was their mouse platform wasn't level. So every time they let go, it would drift downwards and they'd have to go through the "where's my mouse pointer" wiggle again.
api 2mo ago
The truth is that the web is a shit GUI framework. It's slow, clunky, incredibly resource intensive, hard to make uniform, verbose to code. It's terrible. The way the whole industry adopted it is understandable given the install base, but it's also probably a trillion dollar tax. I'd hate to see how much additional energy is used by billions of end-user devices running a rendering layer that is 100X heavier and more CPU intensive than anything native or TUI.
- em3rgent0rdr 2mo ago
  Not if you just stick to the basic built-in 30-year-old HTML GUI elements (<button>, <select>, <legend>, <form>, <input>, <table> for layout, etc., maybe also some modern standards like flexboxes) which are very fast, lightweight, east to code, and uniform. The problem to me is every website tries to do some custom javascript monstrosity with their own graphics to keep up with the latest fad. When just sticking to the basics, I find the web is a great cross-platform GUI framework.
  - ezekiel68 2mo ago
    Sure. Except that nobody ever does just stick to those elements.

hedgehog 2mo ago

It's not hard to make a portable UI framework if you accept similar limitations to the terminal (limited OS integration, accessibility support, etc). You can do anything you want and ship it through RFB.

mawadev 2mo ago

Plus, when you ssh into a server and don't want to or can't rdp it, you at least have more degrees of freedom when you juggle complicated commands, like k9s

01100011 2mo ago

I have old wrists, essential tremor and tics. I try to avoid the mouse where possible. Yes, please make more TUIs!

wowczarek 2mo ago

> If we had a cross-platform usable GUI framework I could swear there once was a (n)curses or otherwise text based GTK+ implementation / backend. It didn't do everything of course, and this was, I don't know, about 2003-2007, but you could compile a GTK application and run it in the console. I tried finding a link, but unfortunately could not, can't even remember the name, I only remember building a piece of software that way that did GUI or TUI depending on how it was linked.

guessbest 2mo ago
Could you be thinking of libyui, but it was QT and ncurses based. I think it came from SuSE with YaST. https://github.com/libyui/libyui https://github.com/libyui/libyui https://yast.opensuse.org/ https://yast.opensuse.org/

grepps09 2mo ago

[dead]

63 2mo ago

When you're one of the people who finds TUIs inaccessible, "accessibility" isn't just a downside to be considered, it's table stakes. I think they're fine for one off toys for individuals and small groups, but if you're selling a product to the public, it ought to be accessible first and foremost.

rererereferred 2mo ago
That just means you have a potential userbase for an alternative for non-TUI people. If the market is that big, why not take it for yourself?
- VanTheBrand 2mo ago
  We should get rid of ramps and handicapped parking at grocery stores too. If it’s such a large market someone can start their own accessible grocery store…

0x3444ac53 2mo ago

Yeah TUIs are great. I'm shit at making GUIs but I was able to slap together a relatively simple TUI for some tooling at work, without any AI. Cheaper, faster, cross platform, less intensive. Most TUI frameworks nowadays have mouse support as well etc. So what if it looks just a little dated?

grepps09 2mo ago

I'm very keyboard-driven but I never really got TUIs. A GUI litterly can have just as good keyboard support, but because it doesn't force the user to use it, they rarely take the time to learn it. It's just always tempting to take the path of least resistance. Especially becuase TUIs doesn't really have any of good properties that a CLI offers such as composebility. It's still a fixed UI with panes and menus which has just been squeezed into a character grid, and now forces the user to learn its pre-set keyboard bindings (which surely can be changed, but with every app having it's own config managment). It's kinda the worst of both worlds to me. Either go all in and give me a proper text-based interface like Emacs (where you can globally configure how you wanna deal with lists of text in buffers), or just make a proper GUI with good keyboard support.

t098i3 2mo ago
They made a ton of sense back when the cost difference between a basic text-only terminal and a full-color multimedia PC was significant when multiplied over all of your employees.
samspot 2mo ago
At least with a TUI you know 100% it works with the keyboard. This is not something you can safely assume about any GUI, on the web or otherwise. Our accessibility team is kept very busy by this fact.

MisterTea 2mo ago

> Hard disagree. Make more TUIs! My big beef is the dichotomy of today's GPU accelerated bit-mapped displays which are burdened with this silly task of running a program that emulates a typewriter. Why TF do we not have a display protocol that can do graphics natively over SSH in 2026? > TUIs have downsides like accessibility, poor mouse support, but work really well if you focus on keyboard input. This assumes a typewriter emulator. Why are we not working on graphical systems where text is a first class primitive allowing us to easily draw text in any color, font, size, formatting and orientation as we please, onto a GPU accelerated display? Keyboard can still reign supreme. No mouse needed but if it is - first class support unlike crappy typewriter emulators.

utilize1808 2mo ago
> Why TF do we not have a display protocol that can do graphics natively over SSH in 2026? Did you mean X server?
- MisterTea 2mo ago
  Plan 9 devdraw which is really nice: https://news.ycombinator.com/item?id=49384210#49404622 https://news.ycombinator.com/item?id=49384210#49404622. X is well past its sell-by date. Plan 9 is text first as it was written by Unix programmers who wanted to build an OS and write programs (Rob wanted a better text editor.) It's the OG TUI. Window managers like Rio can run in Rio. You control things by writing textual messages from the command line, scripts, or code, e.g 'echo 100 >/dev/volume' to set audio volume to 100%. Someone wrote a new WM called Lola so I ran Lola in Rio in Lola in Rio because I can. Sam is very much a keyboard driven modern TUI ed (the standard editor). Acme is a mouse driven TUI editor. Both can be automated by programs and scripts. You can edit text while reading your email and chatting on irc from within Acme. BUT Lots of stuff missing. We don't yet have GPU accel. It's a MSSIVE undertaking. And it has to be carefully designed and would likely be a built around a generalized devcompute kernel device.
inigyou 2mo ago
We do it's X11

ordu 2mo ago

I don't use TUI when I can avoid it. I happily use CLI apps, or GUI apps, but TUIs are not here, not there. They lose all the appeal of CLI apps, while getting some weird text interface instead of a polished GUI library and all the possibilities that you can get from rendering pixels, not characters. When I moved from DOS to Linux, I chuck away TUI file managers and switched to pure CLI and never looked back. I could use GUI file manager, there you can really use mouse, without that jumpy-movements it has in TUI apps. But I wouldn't touch Midnight Commander or whatever. I tried to run emacs in a terminal. Emacs' support of GUI toolkits is very cumbersome thing. But guess what forced me to abandon this experiment? Emacs is keyboard-driven, and terminals have issues with some keys, while GUI apps can deal with virtually anything. > If we had a cross-platform usable GUI framework, and more consistency across OSes, the story would be different. Try egui. I really like it. I'm not sure how much it is cross-platform though, hadn't tried it outside of Linux, but it is really nice. Or if you are an elm-purist then iced might be your choice. Iced lacks on widgets, it has just some basic ones, and if you need something to render a 2d-plot, then you are on your own.

inigyou 2mo ago

Nothing stops you making a keyboard-driven X11 app.