| > Fun to see a contemporary take on something that peaked between 1970s–1980s Maybe that was the peak, but you had some very good TUIs in the early 1990's for DOS apps, where Windows hadn't quite completely taken over yet, but you very likely had a VGA-compatible graphics card and monitor, meaning you had a good, high-resolution, crisp and configurable-font text mode available, and also likely had a mouse. This is the stuff I grew up with: QBASIC and EDIT.COM for example. Bisqwit has a cool video about how some apps from that era could have a proper mouse cursor, even: https://www.youtube.com/watch?v=7nlNQcKsj74 |
| |
| ▲ | gf000 2 hours ago | parent | next [-] | | But why? You easily have 4k pixels, why use a tiny subset of those in a very inefficient way? We have proper hardware to make a bunch of these computations actually fast, and yet we should stuck with drawing relatively expensive text everywhere? If you only care about the UX of TUIs, that I can stand behind (though mostly as a guideline, it doesn't fit every workflow), but you can do that with a proper GUI just as well. | | |
| ▲ | citrin_ru 2 minutes ago | parent | next [-] | | One of TUI advantages over GUIs (including modern web sites) - all text can be selected/copied (you may need to use modifies in some TUI). It's a bit frustrating when GUI shows text but I cannot select and copy it. | |
| ▲ | cfiggers an hour ago | parent | prev | next [-] | | > If you only care about the UX of TUIs, that I can stand behind This is a confusing concession. Of course we love TUIs because of the UX, what other reason is there? Constraint breeds consistency and consistency breeds coherence. Take 1,000 random TUI designers and 1,000 random GUI designers and plot the variations between them (use any method you like)—the TUI designers will be more tightly clustered together because the TUI interface constrains what's reasonable. Yes of course you CAN recreate TUI-like UX in a GUI, that's not the issue. People don't. In a TUI they must. I like that UX and like that if I seek out a TUI for whatever thing I want to do, I'm highly likely to find a UX that I enjoy. Whereas with GUIs it's a crapshoot. That's it. | | |
| ▲ | Someone 10 minutes ago | parent [-] | | > the TUI designers will be more tightly clustered together because the TUI interface constrains what's reasonable. It constrains what’s possible, not what’s reasonable. For example, one could typically fit more text on a screen by compressing it, but most of the time, that’s not the reasonable thing to do. I’m saying most of the time because of the existence of English Braille (https://en.wikipedia.org/wiki/English_Braille#System) which uses a compression scheme to compress frequently used words and character sequences such as ‘and’ and ‘ing’ shows that, if there is enough pressure to keep texts short, humans are willing to learn fairly idiosyncratic text compression schemes. colorforth (https://en.wikipedia.org/wiki/ColorForth) is another, way less popular example. It uses color to shorten program source code. One could also argue Unix, which uses a widely inconsistent ad-hoc compression scheme, writing “move” as “mv”, “copy” as “cp” or “cpy” (as in “strcpy”), etc. also shows that, but I think that would be a weaker argument. |
| |
| ▲ | pwinnski 10 minutes ago | parent | prev | next [-] | | You could double or quadruple the number of pixels, and it wouldn't make any difference in how much information humans comprehend easily. You would be using more computing power and more memory to deliver the same amount of useful information less efficiently. A "proper GUI" is rarely better than a well-designed TUI for communicating textual information, IMO. And the TUI constraints keep the failure-states for badly-designed UI tightly bound, unlike GUI constraints. | |
| ▲ | zahlman an hour ago | parent | prev | next [-] | | The UX is the point. When you are "drawing text everywhere", you end up not having to draw all that much text. 3d models have more and more polygons as graphics cards improve, but the 80x24 standard persists for terminals (and UX is better for it). And I'm not even that convinced of "relatively expensive". Grokking UTF-8 and finding grapheme cluster boundaries has a lot of business logic, but it isn't really that hard. And unless you're dealing with Indic or Arabic scripts that defy a reasonable monospace presentation, you can just cache the composed glyphs. | |
| ▲ | krautsauer an hour ago | parent | prev [-] | | I'm curious: Do you have a nice set of GUI applications that come with the UX you'd expect of TUIs? (I'm not actually sure what the UX of TUIs is I love so much. Relative simplicity / focus on core features? Uff, notepad wins this one on vim. Fast startup times? I use gomuks, that takes a minute for the initial sync. No mouse? Moving around in TUI text editors with hjkl is slow. I either jump where I want to go with search or use the mouse. Lightness over SSH/network is the only thing I can't come up with a counterexample for.) |
| |
| ▲ | user3939382 2 hours ago | parent | prev | next [-] | | I hope it’s inevitable. Most users’ computing workloads by far are text oriented. The terminal is capable of flexbox now. Current GUIs create massive complexity and power draw relative to their value. Over a long enough arc, economic inefficiency is doomed. | | |
| ▲ | zahlman an hour ago | parent [-] | | > The terminal is capable of flexbox now. You mean like https://silvery.dev/examples/layout.html ? This is definitely not a UI development paradigm I would have expected to see. | | |
| ▲ | user3939382 28 minutes ago | parent [-] | | That’s the tip of a conceivable iceberg but exactly. Also look at kitty graphics protocol. Look at the amount of engineering resources we pour into OS GUI toolkits and then browsers. Those layers of complexity aren’t there because we stood back and said, “given what we know in 2026 how should we design a GUI compositor?”. The majority of the stack is written how it is by archeological happenstance. One generation adds on top of the prior since the 60s. I’d say start from the terminal, fix the rendering limitations that drove the split from terminal and then to the browser. If we pin down efficient GUI, we could have machines that cover non graphics workloads which is the vast majority with solar and the equivalent of a 6502. The amount of energy wasted on modern stacks relative to the tasks being delivered is incalculable. |
|
| |
| ▲ | 2 hours ago | parent | prev | next [-] | | [deleted] | |
| ▲ | unleaded an hour ago | parent | prev [-] | | What's behind this new obsession with TUIs/CLIs anyway? You always had people obsessed with i3 and vim etc but this is something different. | | |
| ▲ | clickety_clack 23 minutes ago | parent | next [-] | | It’s functionally focused and because most apps are web based now, and TUIs are generally local, it makes them seem relatively very fast. | |
| ▲ | LeCompteSftware 21 minutes ago | parent | prev [-] | | I think part of it is Visual Studio Code doing most IDE things very well, creating a market niche for terminal tooling that handles the rest. Certainly part of it is also people of my generation being nostalgic for the TUIs of DOS file managers and editors. |
|
|
