[SchemaLoad]

For some basic stuff like vim it works fine. But for almost everything else I'd rather a regular CLI tool or a web interface. I suspect a lot of the popularity comes from people who want to feel like a hacker using 10 terminal windows, but actually want a GUI like experience.

[ulrikrasmussen]

For me, TUIs compensate for the fact that I can't get good remote GUI rendering on Linux. Yes, X11 tunneling exists, but the experience has always been abysmal for me for anything not hosted on a machine that sits on the same LAN as the client. For Wayland I don't even know if such a thing is possible since I don't think the architecture supports it.

But the terminal is just fundamentally the wrong basic abstraction on which to build a structured GUI, it just happens to require few enough bits to be sent over the wire that it actually works reasonably well over SSH as opposed to pushing graphics.

[seba_dos1]

> For Wayland I don't even know if such a thing is possible since I don't think the architecture supports it.

Not only forwarding is trivial with Wayland, it also tends to provide better experience than X11 does.

[ulrikrasmussen]

I have never tried it until now, and I hadn't looked into it. But I just tried `waypipe ssh` to a remote server I have for doing asynchronous Claude work in VMs, and it actually works pretty great! Maybe I'll switch to that for my emacs/magit setup, the lack of clipboard integration when running emacs in a terminal over ssh is enough of an argument for me.

Edit: yikes, pressing M-w caused emacs-pgtk to crash with a Wayland protocol error, so it isn't trivial and requires some configuring I guess.

Edit 2: Apparently I have to install wl-clipboard and write a bunch of emacs lisp to work around this. I don't think I have the patience for that, and I fear that such problems will be even harder to solve for applications which are not as flexible and programmable as emacs. So far I'll conclude that remote Wayland is not ready and stick to TUI.

Edit 3: No, the problem is probably mismatched waypipe versions on client and server. Still not fun.

[graemep]

> Yes, X11 tunneling exists, but the experience has always been abysmal for me for anything not hosted on a machine that sits on the same LAN as the client.

I have used X11 tunnelling to machines on the other side of Europe and it was OK. I did prefer ssh for responsiveness. What happened to NX? What about other remote desktops?

[mgrandl]

You can use Sunshine streaming on Wayland just fine. I have a headless sever with Sunshine and a Wayland desktop and can stream it remotely with great quality and minimal latency.

That said for most tasks I would still rather SSH in and use CLIs (not TUIs).

[xboxnolifes]

Obviously people want GUIs. That's why TUIs should be compared to GUIs, not to CLIs. TUIs are nice since you get a lot of the benefits of a GUI, without having to leave the context of the terminal.

[yellowapple]

I feel like the better solution here (than trying to shoehorn a GUI into an interface meant for text) is to make terminal windows graphically-aware, like how things work in Plan 9.

[SchemaLoad]

At that point what you want is just a tiling window manager rather than a terminal that supports GUIs.

[yellowapple]

I already do use tiling window managers and they don't really accomplish the “if you launch a graphical app in a terminal window it takes over that terminal window” flow. Closest I've found is Niri's support for tabbed windows, but even that's just sticking the graphical app window on top of the terminal window instead of the terminal window itself becoming the app window.

[calgoo]

Depends, I'm building a markdown down editor that just previews in the web ui. However, I can use the web ui to do tasks like uploading files, view git commits etc. Different interfaces for different purposes. The CLI gives me focused mode, and then visual stuff that steal my time goes in the web

[helterskelter]

I dunno, pre-LLM TUI's at least tended to be okay, and keyboard navigation was a first class citizen. Besides, if you were using a TUI instead of a GUI then you basically always ended up saving memory/battery life, and TUI programs are generally more portable than trying to run some ancient GUI program.

I typically prefer CLI myself but having a TUI to manage torrents for instance was much more ergonomic.

[kajman]

A lot of the complaints in this thread seem like they're aimed more at recent vibecoded UIs than the concept of a TUI.

Like, okay, they are a big step back with accessibility, but they're flickering garbage because they were vibecoded in a weekend and the TS or Python library they're built on was similarly forced upon this world.

[SchemaLoad]

For almost every tui, a webui works better imo. Most torrent clients offer a web management ui and it's always going to be easier and more feature filled using a platform that was actually designed for it rather than hacking a gui in to the terminal.

[sublinear]

Accessibility can also be much better in a web UI because the markup is more rigorously defined.

https://developer.mozilla.org/en-US/docs/Glossary/Accessibil...

[lynx97]

Well, "better" is relative. Web UIs definitely have the advantage you are mentioning. However, they are also much slower to use, so it is a tradeoff.

I am blind and do rely on accessiblity. But I would choose a TUI over a Web UI every day simply because the web is slow as hell. Feels like running away from a "monster" in a dream. You have rich details, but you are being drowned in unnecessary verbosity and an inherently slow stack of tools working together.

The web might be accessible, but it is barely useable in practice.

[sublinear]

That's interesting. Thanks for sharing.

I'm curious which screen reader you're using and what can be configured to fix that experience.

[lynx97]

Its more or less the same with every screen reader and browser I know. If there was a simple fix for this inherent issue, I wouldn't have to talk about it. You might get a bit of stuff out of the way if you configure less verbosity of the screen reader, but it doesn't really help with slow interactions. Problems include:

* Virtual buffer: In most systems, the DOM is rendered to a "virtual buffer" and the screen reader lets you navigate that, because cursor (caret) support was on the map for accessibility, but was never really sufficiently implemented on the browser side. So screen readers had to solve it in a separate step.

* Using the keyboard to do screen reading and navigation on a site conflicts with keyboard shortcuts from that site. So most screen reader have two modes: You switch between entering text in a field and navigating/reading the site. Its basically like vi insert mode, but less simple.

Those are the major issues from my POV. The rest of the slowness likely comes from having to go through the accessibility API of your OS.

[bee_rider]

Vim is special because 99% of what we do is editing text, and it is the text editor—the importance of that task overcomes the poor discoverability of a TUI. Most other programs should be CLI, so they can fit in the conventional command line toolbox.

[zbentley]

This. A lot of folks picked it up for that reason when they were young and now are terminal-all-the-things out of sheer inertia.