[safety1st]

The peak of TUIs is now. Take a look at Omarchy, an entire operating system built around terminals and config files, it's nirvana. I can only imagine how much farther down this road things may go as we enter a world where the primary interface is conversation with the machine in text. I'm sure I'll get downvoted for that last part because Reddit -- (cough) I mean Hacker News - hates AI, but I'm genuinely excited for the future.

[Telemakhos]

We had "opinionated" TUIs with emacs, and Omarchy will never surpass emacs' ease, shallow learning curve, and configurability. Emacs is the operating system of the future, and you can already integrate AI with it. It provides everything you need or want or don't know you want except a decent text editor.

[zie]

> It provides everything you need or want or don't know you want except a decent text editor.

That's what evil is for :P

[vinceguidry]

I used emacs for years, switched to neovim last month. It's just too old and crufty for modern use, and modernizing frameworks like Doom / Spacemacs only add to the complexity. Nice modal workflows just go against emacs' nature.

[dwedge]

Apart from being wayland and a more modern look, why are you excited about omarchy and AI and you weren't with i3?

[safety1st]

How did you know that I use i3 on all my non-Omarchy machines? :D

[keybored]

Plain text coupled with non-deterministic interfaces (AI) is not great. It’s like a hybrid: some of the best of old school tech coupled with the most sketchy high tech.

I will now get to have Kafkaesque conversations with computers in MarkDown.

[ambicapter]

Oh, the irony, I go to the website and the only thing it shows is a video to watch.

[TheEaterOfSouls]

I'm imagining a TTY-like interface that you can simultaneously type into, speak and gesture at, and whatever else I'm not thinking of (maybe with the "shell" creating a list of suggestions/ anticipating future tasks in the background based on voice input?) Doubt it would be at all practical, if only because the keyboard as a primary input device might not be as much of a thing when you can generate most code/text, but kinda fun to think about.

[safety1st]

To be fair, ShellGPT does a lot of heavy lifting for me. Weird thing I need to do, ask it a question in my terminal, it suggests a bash one-liner.

I haven't looked into voice/dictation yet. I'm dumber when I talk and smarter when I type so while it's super cool I imagine the net productivity gain may be a little overstated. Probably pretty straightforward with OAI's API.

[gf000]

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.

[cfiggers]

> 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]

> 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.

[tolciho]

Try a 300 baud modem for a few months and good money says something terribly modern like Get-MrParameterCount would get compressed, a lot. Here's Bill Joy on the topic:

> No. It took a long time. It was really hard to do because you've got to remember that I was trying to make it usable over a 300 baud modem. That's also the reason you have all these funny commands. It just barely worked to use a screen editor over a modem. It was just barely fast enough. A 1200 baud modem was an upgrade. 1200 baud now is pretty slow. — "Bill Joy's greatest gift to man – the vi editor". The Register. 2003.

[gf000]

Come on, my previous phone had more bandwidth via a goddamn satellite, sending emergency infos.

[cfiggers]

> It constrains what’s possible, not what’s reasonable.

Why do you say "constrains what’s possible, not what’s reasonable", as though it's one and not the other? Does possibility conflict with reasonability? I would think it's not an either/or, it's a both/and.

The set of reasonable things is bounded by the set of possible things. So if the constraints of TUI design make certain things impossible, surely they make those same things unreasonable at the same time.

[gf000]

> Constraint breeds consistency and consistency breeds coherence.

In principle I would agree, but there are plenty of bad citizens among TUIs, it's absolutely not true that you can just start using one.

The same way there are excellent GUI applications like blender or intellij.

[Tanoc]

I'm sorry, excellent GUI with Blender? With the 2.5 interface things were ass backwards but you had a bunch of stuff you could do with only the mouse. With the 2.8 interface suddenly a bunch of stuff was hidden behind arcane key combinations, options disabled by default, and the loss of important visual data like the bounding box view and having both the UV and cursor coordinates in the same tab in the UV/image editor. No matter what the controls are different with every sub-window type, and interface panels flip from top to bottom and left to right for best readability without thought spared for consistency. There's a reason why someone can learn FL Studio in a few weeks, but take months or even over a year to become competent in Blender. I love it's jank and have been using it for eleven years, but I would never call the UI more than serviceable.

[majormajor]

The gap between vi and emacs is larger than that of any GUI program I use as regularly as I use either of those.

[pwinnski]

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.

[gf000]

What about a map, or an image? We can surely agree that humans can take in a lot more information than a readable letter-grid allows, depending on the type of information.

[pwinnski]

Sure, of course sometimes an image conveys things better than a thousand words. But a very large percentage of what most people do with computers is primarily text, with more images in ads than useful content. By and large GUIs don't use images to convey information better, they just make text worse.

Modern terminal software supports displaying images, for what it's worth.

[gf000]

> Modern terminal software supports displaying images, for what it's worth.

In a worse, and dramatically overcomplicated way. Like it's kind of funny that largely the same people that is all for this supposed ultra minimalism would be celebrating a Rube Goldberg way of doing graphical interfaces? (Because in the end it is a graphical interface).

[pwinnski]

Sorry for the late response; it's been a busy week.

As a user, I don't care how complicated is the means of displaying images in a terminal session. I would only want to do so when I'm deep in a text-oriented context and there is a suddenly a need for an image. Not a chart or a graph, but an actual image. As a user, whatever contortions are necessary at that point are fine, because it's an unusual circumstance.

I hope that makes sense.

[citrin_ru]

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.

[gf000]

Is that always beneficial? Do you ever want to select the text of a confirm button?

What if it just popped on top in a dialog to the content you were about to select?

[citrin_ru]

It's not only about buttons. A web-app of trading platform I use doesn't allow to copy-paste a fund name (both in web and in the mobile app). I don't think they disallow this intentionally, likely an artefact of GUI framework they use.

[cfiggers]

That's a very good point. I hadn't thought about that aspect before.

[zahlman]

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]

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.)

[gf000]

Blender? There you have to use a mouse because you have a much much bigger state space to control.

Also, Intellij is perhaps a better example. You can fully control it via only the keyboard, yet no amount of plugins would turn (neo)vim into something as capable as it is. And it makes good use of the extra pixels - human can take in much more information than a text grid.

[saadn92]

Not just TUIs the whole stack is converging back to text. I run ~15 personal tools and every one that survived past the first month stores data as JSON/markdown in git repos.

Text in git gives you versioning, sync, grep, and you can hand the whole thing to an LLM with zero serialization. It's perfect for me.

[user3939382]

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]

> 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]

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.

[kode-targz]

I 100% agree, and this isna big reason why I find the current state of education so suboptimal. Everyone just goes on to do webdev, completely ignoring the lower levels and taking it all for granted. The thing is, there's no real innovation to be done that high up the stack. When you're that high you mostly just write glue code to stick parts someone else wrote together. Real innovation comes from quite a few levels down the stack, starting at the native code level downwards.

Like you pointed out, the current stack is heavily unoptimized and has a terrible architecture; it's only the way it is because of happenstance and tides of the market (companies always reaching for faster over better). An actual "nirvana" in computing like the other guy said would require bulldozing a good chunk of our current stack, keeping only kernels and core utilities, if even.

I really wish we had a bigger focus on getting good foundation instead of making yet another JS framework and SaaS, but then again, who's paying developers to actually do something of quality nowadays?

[lioeters]

Comments like this is proof that the old-school hacker spirit is alive and kicking. This kind of pride in efficient and artful use of computers is needed more than ever.

[rubslopes]

I was confused about why your comment was being downvoted; it sounded like an honest opinion... Until I got to the last sentence. You wrote a self-fulfilling prophecy.

[unleaded]

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]

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]

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.

[otabdeveloper4]

Get used to it, because with LLMs they're here to stay forever. (Bash will possibly be fossilized forever now, like the Latin alphabet.)

[vinceguidry]

Nah. Folks will be building their own shells, I'm already half the way there.