Hacker News new | ask | show | jobs
by helterskelter 45 days ago
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.
2 comments
kajman 45 days ago
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.

link
SchemaLoad 45 days ago
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.
link
sublinear 45 days ago
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...

link
lynx97 45 days ago
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.

link
sublinear 45 days ago
That's interesting. Thanks for sharing.

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

link
lynx97 44 days ago
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.

link