What the what now?

You are free to build anything you like, and whatever you build won't affect me at all.

The author starts with a bunch of vibecoded slop apps that show exactly what I hate about 'modern' GUI apps, a lack of options and wasted screen-space. They look hip but are harder to use to me.

And now libghostty has caught up with a full implementation of the protocol in a second terminal emulator. I guess that mitchellh has plans for use in Superlogical... https://hachyderm.io/@mitchellh/117135178412268410

It’s much easier for the clanker to loop on testing / improving the TUI than a real GUI. It also means it can work on the app without an API/REST/HTTP/Java/Script ball of mud in the middle.

>[...]

>But remember: I’m not really building applications for other people to use. I’m building them for me.

Giant caveat to the whole argument and it's buried 80% of the way down. Granted, he alludes to that a little earlier, but if other people using your application are a completely irrelevant outcome, you're an unusual case.

I mean, sure, I make tiny one-offs, but those barely even have something you could call a CLI. I push as much complexity into command-line options and config files as possible.

Does anyone else find that this reflects a really obnoxious attitude, regardless of whether it would work?

Anyway, it seems like the premise is that people would only ever build a TUI because making a GUI was hard, and now it isn't because LLM slop will be good enough. But I'm firmly convinced that fails on both counts.

The primary value statement of TUIs is that they work over SSH with remote systems.

But now, we're hearing rumbles about the limitations of the "modern" terminals with regards to working well with a "rich" TUI. How a raw tty doesn't really cut it since it, at a minimum, can't detect key presses, only actual character/byte patterns. How there needs to be a new protocol, a "better" terminal client.

Of course when you go that route, then the current terminal emulators will need to be updated, or you'll be required to install a different terminal emulator that supports the new protocol. But that kind of defeats the theoretical, historical ubiquity of a TUI. It would not surprise me that many modern TUIs only work with an ANSI terminal.

Back in the day, we had systems like Visual Basic, Power Builder, SQLWindows. GUI/language systems particularly well suited for Client/Server DB development.

For a time, Firefox actually presented itself as a modern incarnation of these tools. Using XUL and JS for UI development, built in utilities to talk back to servers over HTTP. It was a platform for "Rich Internet Applications(tm)".

It didn't really take off, it wasn't documented very well, kind of buggy. It also required Firefox as a client. The potential was there, but not quite realized. Ajax hit the web browser in full force and that pretty much was the last nail. Now, you could use "any" browser for more interactive applications.

Of course, we advance to today, where many sites work in any browser as long as its Chrome. We have advanced applications that are no more than a Canvas element, with everything else being reinvented from scratch. "Have bitblt, will travel."

The browser is the closest thing we have to a universal remote GUI, but we all know the issues with it for many contexts. As an application platform, it may be ubiquitous, but that doesn't mean it's at all lightweight.

We used to have lightweight, remote GUI applications. Rootless X Window applications. Folk don't necessarily want the entire desktop, they just want an app, with some fields and buttons. You could slap them together with TCL/TK. Remember dtksh? We're not talking about trying to write Adobe Premiere or AutoCAD in these things. We just want some simple utilities, fields, icons, maybe a chart. Scrolling tables and a menu.

But we can't do that today, not readily, not easily.

So, we're kicked back to 1978 and the rise of the Smart Terminal, instead of 1984 and the rise of the X Terminal.

If folks are going to write out a custom client for a TUI, then may as well go the extra 10 feet and make it a remote GUI client. Reinvent all of the wheels as they go round, and round again.

TUIs, at least to me and some friends in my circles, do something that native applications don’t: demand focus from the user.

Sure, modern terminals and TTY environments have visual tabs and virtual terminals that let you quickly toggle between multiple apps, and you can of course manually code your screen to split apps across a single “window” if you really want to get into the guts of things.

But for several folks in my close circles (myself included), the fact that each TUI occupies an entire screen by default, forces us to focus on what’s going on and what tasks we’re trying to accomplish in a way native UIs don’t. On the desktop I can flit between Discord and Telegram and multiple games and several Firefox windows full of tabs and the video encode I’m working on and hey did that bank transaction go through let’s check my email except UGH music streaming went off the rails so let me go back to my client and-

You get the idea. For folks who lack the neurotransmitters to maintain consistent focus or wave off distractions, a terminal environment acts as an accessibility device in and of itself. btop on 1, irssi on 2, Hermes (Qwen 35B) on 3, with 4 as my primary workspace and 5 as a fallback. Simple. Clean. Efficient. Lightweight.

I generally concur with the author that we should be “summoning” (I love that word for reasons that deserve their own essay/comment) more native UI apps that are as information-dense as, well, Bloomberg Terminal. There’s no reason we can’t build something as powerful and focused for the everyman for, say, inventory collections, or K8s constructs, or network architecture, all in a native UI. There’s nothing wrong with the GUI, only that at some point we let ourselves get suckered for the narrative that GUIs have to be easy, simple, and opaque, as opposed to transparent and (logically) complex. We can and should build GUIs that flow logically like the commands they’re executing behind the scenes; hell, we should be able to open a console log of every action we took in the GUI and the associated command(s) it executed, so we can better learn to transpose from GUI to CLI ourselves and build more capable or complex automations.

GUI isn’t bad. TUI isn’t bad. What’s bad is presuming one or the other is superior to everything (or for everyone) else, or worse, assuming one cannot function in a given way comparable or equivalent to the other.

  cmd+U scroll to beginning 
  cmd+I scroll to end
  cmd+u page up
  cmd+i page down
  cmd+j one line up
  cmd+k one line down
  cmd+- font size decrease
  cmd+= font size increase
  cmd+0 font size reset to default
  cmd+3 default font
  cmd+4 alternative monospace font
  cmd+[ grow left window border
  cmd+] grow right window border
  cmd+{ shrink right window border
  cmd+} shrink left window border
  cmd+9 switch background and foreground color

  - cmd+space to open spotlight search
  - type the name of the app, enter, it opens a new window with clipboard contents, i inspect it with keyboard hotkeys only
  - cmd+q to exit or cmd+tab to switch back to the prev app

You can also just use the system console with tmux or GNU screen if you absolutely don't want any graphics at all.

The TUI programs usually do not consume a lot of resources. They are also very fast and optimized for keyboard-only navigation.

[1] https://en.wikipedia.org/wiki/Text-based_web_browser [2] https://github.com/browsh-org/browsh

People write code using the platform X because they like it. It doesn't make sense to try to stop this

> Meanwhile, if I build a TUI, I can be reasonably sure that Linux users are going to get the same experience I have. That’s not nothing. But remember: I’m not really building applications for other people to use. I’m building them for me. TUI affordances are an awfully big hit to take to get Linux users of programs I don’t even want to publish.

If we're just talking about personal or throw-away apps, yeah I'd probably just go native. But for things that I plan to use across platform, via remote shell, and for many years to come, TUIs has a huge advantage. I also think there's something powerful about the constraints of a terminal and the type of solutions it's led to. Constraints breed creativity, and in the case of terminals they also naturally steer towards high-performance, low-latency, and rapid interaction by experts. The fact that these things were born out of the limitations of early computing doesn't automatically make them outdated, to the contrary, it gives them staying power and portability.

In my mind there are crystal clear advantages to GUIs, TUIs, and raw CLI. I've used all of them extensively over the decades, and I've been impressed with the advancements in each over that entire time. I would never presume to tell somebody how to solve their own problems—if you're excited about something just go build it in whatever way makes sense to you.

My stances:

- Dev tools need a CLI at minimum, TUI for complexity

- User facing needs a GUI, CLI for power users

If you're building a TUI for a user facing thing, then yeah, you're doing it wrong, but if your target audience is devs then yes, PLEASE do a TUI, and make it nice.

I understand the sentiment that TUIs is not as accessible, sucks to use. I still do not like the fact that we should "stop making TUIs" altogether.

Let me give you an example from my carpenter friend in Cananda. He has a saw (TUI) and electric one (GUI).

He uses the saw in diff ways than his electric one. He sometimes extend the saw by attaching it to end of a long stick to cut tree branches he cannot reach. He can do it with the eletric saw but requires much more effort.

But if he needs to cut down the tree, he uses the electric one, and sometimes finish off (trim) with the regular saw (so the tree falls in certain direction).

The gist is, TUIs can be used to do things quick and dirty, and easy/cheap to make/buy. GUI even with AIs, still not as cheap as TUIs to build.

TUIs has a different usage in our field, where it's used more for automation/piping. If you have GUI, it's hard to pull it off unless you build the functionality (which coulda been a command in TUI), and expose it via GUI. the Authros is focused more on consumer side than builder side. With AIs we will all be builders using AIs.

Lastly, shooting down people building TUIs is saying, no more innovations, by building upon other's TUI inspirations.

Let people enjoy things.

- I'm team GUI! The author outline elegantly why. Sometimes I put command-line-like things in the GUI; I generally view it as a superset of CLI, with vastly richer capabilities. This is kind of interesting in the bioinformatics/structural bio space, which I feel is inherently visual, and benefits from 2d layouts. Most of the tools are CLI and based in I/O of stdout and text-based files. I am taking a different direction!

> Back in 1999, Neal Stephenson wrote an essay about command line interfaces that set the field of human-computer interaction back about 20 years. In it, he depicts the priesthood of Unix nerds wielding CLIs as powerful Morlocks, holding the entire computing industry on their shoulders. The Eloi use GUIs like Microsoft Word. Because this is high-test fan-service, “In The Beginning Was The Command Line” has become one of our field’s sacred texts, despite very little of it holding up 25 years later.

We should not take Sci-Fi and creative plot devices as predictions for the future. They can be inspirations and motivations for your own creativity, if tempered by realistic expectations and discipline. Neal Stephenson is especially prescient (Certain concepts from Fall; or Dodge in Hell and Anathem are hitting home strongly right now!). He spins vibrant, speculative yarns, mixing concepts, and estimating trajectories. The story referenced he is one that's in particular easy to see what parts did and didn't pan out. (And what Neal's more recent reflections on it say)

I think there is a bit of cultural identity (Which we are genetically inclined to insert in all sorts of places!) going on. There is a certain cyberpunk fun in SSHing a terminal, pipeling stdout/in together, and Viming. I suspect there is a high overlap between people for whom Linux is part of their identity, TUI use is as well. I.e, it's not about a practical weighing of merits; standard identity/tribal-based choices.

FOr use of TUI as a general file browser/command-executor... I've made my own. It's a GUI, and has built-in terminal for executing commands, with a visual file browser. And most importantly: Shortcuts to execute commonly-used workflows, history, bookmarks etc. All of which I feel like are glaring things missing from standard terminals. (PS, Bash etc). And having a terminal as one part of a multi-window program feels like a good use of my screen space!

Its also a bit funny how the author show cases a bunch of apps that only exist on a very specific setup, IOS Mac devices while TUI can exist everywhere a terminal can reach.

The right tool for the right job, noone would srsly use a TUI photoeditor but for many things the simplicity and constraints that a terminal introduces condenses design.

I got this article about UI density open since weeks and meant to read it https://mattstromawn.com/writing/ui-density/ But from what I could interfere so far..more UI frameworks, more white space, more wasted space.

Also..TUIs usually allow me a wide variety of colorschemes out of the box which is nice

1. CPU/memory performance on cheap or throwaway systems has a niche benefit. Mostly poor people. I'm still usually on an ancient Thinkpad with a 2nd gen i7. It runs native apps really fast to this day. Almost all GUI cuz I agree with the OP but my apps are TUI by default to keep them lean and fast.

2. Security. While I don't aim for it these days, it was much easier to make textual apps securely than GUI apps. Secure OS's from the 90's already secured console apps. TX, Nitpicker, and EROS made progress on GUI's but there's high complexity still. I'll note the OP's idea of GUI front ends is basically what we did to isolate the GUI part in a dedicated partition with messages it sends checked by the secure component.

Other than those observations, I'm with OP where I'm tired of TUI's if GUI's are that easy now. I considered trying it with some lightweight, cross-platform frameworks. Anybody tried some with cheap AI's?

EDIT

> CLIs have purposes for which they’re irreplaceable. Building a CLI is almost always a good idea. Building a TUI almost never is.

Oh, right. I can see that, but I go the other way: When I have a CLI, don't give me GUIs; give me files. Actually, just give me files and daemons. I'll do the rest, thank you!

I like chocolate I like vanilla

We run an internal agentic development harness we experimentally built for working on large-ish projects. first version started as a TUI, but it quickly became unusable for the large scale projects it was meant to work on (essentially PRD to PR, with planning loops, task decomposition loops and dependency aware execution / review loops). The TUI was too state-bound for another agent to drive reliably, and too cramped for a human to review at scale. We ended up replacing the TUI with a headless cli, and every interface we've built for the harness has become either a text artifact (mostly for agents to work) or a web view (for humans to drive and review).

With X based apps, you can run GUI apps through SSH. That was all the rage for light remote access to resource hungry desktop app a few decades ago...

But that being said, in my opinion, a few limited TUI apps are useful, but most of them nowadays are young "cool kids" that wants to be cool by using "terminal apps" without really having really embraced the spirit of the terminal and commands.

For them, using GUI apps would look like a basic computer user and not an expert nerd.

The magic of the terminal, is not that you run things in almost black and white with low graphics, but that you were supposed to use "simple" commands that you can scripts and pipe one through each others at will.

Since I wrote my own terminal multiplexer that puts terminals on infinite zoomable canvas [0] and I just can't get enough of putting weird stuff like asciiquarium, cmatrix or tty-clock all around (tried peaclock but it's slightly too fiddly for my taste). There are fun projects just to run in TUIs like astroterm or weathr, but I'd say that the space is still open to terminal toys.

The only problem I have with TUIs is that they're boring after a while but something that can be solved with often theme switching.

[0]: https://race-term.com (commercial)

Well, that's a new one, ha ha (guessing "tripping balls" on GLP-1).

(And here I am too, about to be glipping balls… like everybody else, I suppose.)

For something to become a GUI app (or a web-based UI) the GUI needs to offer something more valuable than a TUI can offer in terms of interaction.

I have one TUI app that wrote a while back to keep track of what I work on. It started off as a "wizard"-style UI. You choose project, then subproject, day, hours, activity and then hours and comment in a sequence of steps.

Arrow keys -> enter -> arrow keys -> enter .... -> comment -> enter

It takes about 2-3 seconds for me to do. And this is a time-sensitive task: if it isn't fast the user will not do it as often. There is a web interface to do the same thing, but the backend is slow. My TUI utility speeds that up by caching (between sessions) the things that the web UI has to look up (slowly) every time.

Then I wrote a more involved UI for it that "looks more like an application". Result? Now we were up to 15-20 seconds of interacting. Oh year it could do more and it certainly looked better, but it was less efficient so I noticed that I would postpone using it to record what I was doing. Because it now had friction. Lots of it. So a couple of weeks later I just did a hard reset and went back to the wizard style, minimalist version.

I would make a web UI, but that would burn 2-3 seconds just to navigate the browser there, juggle tabs (which I have too many of already), find the right browser to open the tab in etc. Once there do I keep it for "faster access" or close the tab? Keeping it is almost always the wrong thing.

There's a reason I have perhaps 15 different tools in my garage that can attach to a given fastener size. And there's a reason for that. Not all 19mm bolts are treated the same way. Some are low torque and live in tiny spaces. Some require precise fastening torque. Some need a lot of force to come loose - some will only come loose with force and I'm okay with destroying them. This is why I have so many tools that all do essentially the same job: apply rotational force to a piece of metal that has a standardized interface.

Similar tasks are not always best solved with the same tool because the context and the details do matter. Same goes for UIs. There are some things TUIs are very good at. Not least portability and remote usability.

There's a shorthand that derives from the Phoenician string instrument : nabla . Latex has it as \nabla

Who said we're building them because we have to? I like TUIs, and often prefer them over GUIs, depending on the case.

You want it graphical: Make a webapp.

You don't: Make a TUI.

What exactly is the use case for native apps? Even lots of legacy code can build to WASM now.

(yes, I'm exaggerating a bit, but not much)

https://github.com/tqbf/casette

I'd take TUI apps over electron apps everytime as long as the UX is good.

TUIs are a creative constraint.

TUIs are an invitation for programmers.

TUIs are doing "less" to render.

TUIs don't need to be "responsive".

Hello World is TUI.

Making GUI apps has been way too hard on all platforms since forever. Frankly I think it's gotten worse for 20 years. People started fleeing to web wrappers like Electron to escape the horrors of native UI development.

So if that was the reason why you made a TUI, take heed. LLM's can chew through UI frameworks for you.

But I solidly believe TUIs are often better than GUIs even if they were equally easy to make. They liberate your app from having to follow the fracture and fashions of GUI's - Liquid glass, Windows 8, SwiftUI, WinUI3, QT, GTK or whatever. A TUI allows muscle memory that you learned on Solaris in the 90s to work fine in windows 11 in 2026.

Easier to test too. Try testing your beautiful claude design React app end to end

People don't expect to be primarily typing into a GUI; they expect to occasionally click something interesting; have things pop into view as they happen, etc.

A TUI's advantage comes partly from imposing a constraint: how can we make close to all the user does in this thing and make it doable by typing at this cursor?

As always it's horses for courses.

UIs are also useful for information that is best represented in a UI. keep using those too.

You can bend each to be more similar to the other, and that's good too! Sometimes there is a good use case for that.

I'll just copy a comment I made about this in another thread:

TUIs are just GUIs that use a grid of characters instead of pixels. They are strictly worse than true GUIs, by definition. The only thing I liked TUIs for is running over SSH, but can any of these newer ones really run over SSH with any kind of decent performance anyway?

I think people are confused and think they like TUIs because they like them being keyboard driven etc. But this could all be done with a GUI.

The other factor is probably just fashion. Similar to how some kids are now listening to music on cassette tapes, which are objectively worse than other media in almost all respects. The less cynical take is it's like vinyl: it does come with compromises but gives us back some of the things we lost over the years.

The actual interesting text-based interface is the CLI. I've seen a few examples of TUIs that really should be a CLI and would be much more useful as such.

On the other hand, they are easier to build in a cross platform manner.

Linux is probably the most difficult platform to build GUI for, because of all the fragmentation, X11, Wayland, all the different flavors of GUI toolkits, driver issues, window managers issues, font issues etc.

TUI are a bit like web apps in that regard, using the terminal instead of a browser to abstract the platform.

maybe the answer is... you just don't need features like scrolling? this guy is trying to fit a square peg into a circle hole

Terminal, coding, and even prompt writing skills are language skills.

If you cannot use a terminal properly you are basically an appliance user. Like a toaster operator.

TUIs are not for everyone by design.

I’m with Tom on a lot of what he says. This is a nice reminder to take another shot at this.

https://cushychicken.github.io/python-guis-for-heretics/

It's inherently cross-platform (msys under windows). It allows to copy any part of UI. It doesn't require dependencies other than curses.

Back in the late 1980s, there was no question—the Mac changed everything, and everyone agreed that graphical was the superior interface. But we in the Unix world were slow to convert fully, because of a couple of problems:

* designing GUIs is hard, especially for programmers;

* writing GUI code is hard (and often tedious).

So good GUI apps really came from teams of elite designers and developers. The best ones all worked for Apple. There was an acceptable second tier that all came from major companies. If you wanted to write a custom one-off tool for yourself, however, you'd be in for some pain and the result would be jank.

But LLMs solve both problems. Point Claude at a description and some mockups of an app, and it will give you that app, or at least a slick-looking prototype that is suitable for your use if not the wider market's. So we no longer have an excuse. ALL our apps should be graphical, because creating graphical apps is now easy.

As in, using graphics, vectors, but with a fully text-based UI?

Like Brooke Shields, I'd rather nothing comes between me and my LLMs.

Sure it looks pretty but it’s impossible to drive from the keyboard without mutant hands and savant level of memory for arcade combos. That means the entire OS relies on being able to drive the UI from a positioning device and thus you have to have the coordination to piss on an ant off a moving train. Which is terrible when the input devices are a touchpad, which varies so utterly frustratingly depending on whether it’s in the laptop or over Bluetooth. That and a mouse which is designed by a complete psychopath. That leaves you with third party options which require apps to not suck and they still suck. Scrolling on Logitech options anyone? Even LinearMouse can’t fix that shit.

Compare windows which works absolutely fine from any keyboard or any mouse and is discoverable and consistent. Also no mutant hands required.

TUIs are closer to windows than macOS. And that’s a good thing.

I did the last ten years on a mac and decided I was just hurting myself. Give me windows or a TUI. I notice Linux desktop environments tend to copy windows with respect to keyboard and discoverability too.

Lists a bunch of things .

Fails to make any clear points .

Fails to give real reasons for the few claims it makes .

i.e. ignorance is bliss in the world of typography.

And sure, for programs for one go ham on the ui.

No, for the love of god never stop making TUI's.

Who tf cares about what the author who appears to be new to building native desktop apps (and vibe codes them) says about terminal apps?

I am not writing my code 3 times for each native platform even for agents and then dealing with signing keys just for it to break on a OS update. Terminal apps for developers survive all of this.

The entire article is just a massive rant with woefully weak points. I guess agents really does amplifies both Gell-Mann Amnesia and Dunning-Kruger in others.

So one reason to write this post is just to send a bulletin to developers like me, for whom it wouldn't have even occurred to build native UI before. Native UI is now a thoroughly solved problem. All "off the rack" user interface is solved now.

But that's not the biggest thing happening here.

What's really going to destabilize us is what this says about computer usage and computer programming. When I was a little kid, in the mid-1980s, I imagined all sorts of new different things I could do with a computer, if we ever got one besides the ZX81 clone that plugged into our TV.

I had to grow up to become a computer programmer to learn that one doesn't simply tell a computer to do new things, that there's an elaborate ritual to build anything useful, and it takes years to get comfortable with those rituals. And like most other programmers, and really craftspeople of all stripes, I came to appreciate the rituals and the specialized knowledge. They're part of my identity, so I tend not to question them.

But there's always been this dividing line between computer users and computer programmers. It's rarely disrupted. It happened once with spreadsheets (our profession has a sort of Kubler-Ross thing going on with the fact that Excel formulae are the world's most important programming language), and maybe just a little bit with HTML in the early web. Other than that, we've all been pretty siloed.

That's obviously about to change, in a more significant way than it ever has before. Computers are going to work the way I assumed they did when I was 7. The line between programmer and power user is going to dissolve.

I'm not interested in what that does to our profession or the question of whether or not there will always be a need for serious software craft or engineering or whatnot. Totally valid question, but not where I'm coming from.

I'm interested in what systems look like in this new world we're heading into. What is an operating system in a world where most applications are summoned by the person who's going to use them? What even is an application at that point? What are the interface idioms when we're truly no longer constrained by text inputs to compilers and program building tools? Does everything look more like Smalltalk? Like a Lisp Machine? Or like something weirder? It's gotta be something. It can't possibly be the case that the shape of computing we all count on today is going to survive the next 15 years; it'd be like driving steam-powered automobiles.

That's the fun question.

> Our field has a weird relationship with terminal and command line interfaces. The time has come to re-evaluate it.

Why? Why is infatuation weird? Why should we reevaluate it? The whole premise sounds like a "give me a hot take on XYZ".

(I built itter.sh so I'm biased)

/s

AI slop spam.

I don't want to use those AI sloppers. They often are not based on any intelligent design.

A good counter example is, in my opinion, htop. Many people use it, despite its ncurses-nature. It simply does what it wants to do well: give an overview over resource usage.

Yes, AI slop can spam-generate a clone, but why would I want to use that over the real thing? It makes no sense.

> I’m not packaging this application up. If you want it, just screenshot this section of the post and give it to Claude. It’ll build something useful.

I don't want this spam slop anyway, but notice that the author became super-lazy. Rather than providing source code, he tells you to copy/clone it via Claude spam. So this human is now too lazy to do anything useful. Skynet won. He has been AI slop spam absorbed, without even noticing. Just like in the movie Invasion of the body snatcher (great movie, both the original and the first remake, though I liked the remake more, because Sutherland was in his prime back then).

The author continues to show more AI slop spam created useless things. None of which is interesting. I am surprised people now blog about boring AI created software and call it engineering. So, nah, don't stop making TUIs. Instead, design them better.

Having said that, I think ncurses is the wrong tool in general. We need to be able to design both TUIs and GUIs in one go without barriers. Every time I have to use ncurses, I do indeed curse.

Sure I can. That's not to say that it's completely useless and not worthy of any attention at all, just that it is far removed from the primary considerations of software design -- it absolutely is an aesthetic matter that is not an important consideration until functional design is settled.

Of course, I didn't mean to imply that there's a dichotomy between personality and clarity. There's a dichotomy between ordinary LLM writing and personality.

I'm currently trying to create a GUI version (immediate mode library) of a CLI tool of mine and it's mostly a shit show and three times the work of a data-in-data-out CLI tool. Good learning experience, though. I should note that I don't care whether the GUI version has a "native feel" or not (if you have the time to do so, be my guest), only whether it's functional and reasonably fast, since otherwise that's even more work for an open-source tool. Though, when I undoubtedly make the more interactive TUI version later on (ratatui just seems too nice not to try! :-)) it will probably bring a similar complexity development wise.

Then again I'm not into agentic coding at all so maybe the joke's on me. On the other hand, at the moment I need to learn about the data I'm processing, the GUI library/framework I use, and being able to help the people I work with troubleshoot the equipment that collects said data. I'd miss out on most of that if I coded by prompt. Perhaps I'll try later, perhaps not.

Keep making TUIs, or GUIs for that matter.

Sometimes I can use `du` to check what uses so much space, but sometimes ncdu is better for me.

And the best part - I can use both when I ssh to another machine, using the same command line, without thought. While GUIs need added thought, to switch from CLI to GUI on the remote one would need to use a different interface, or have X11 forwarding on (which is also a good option) and x11 libs on the other side.

Or use some other connectivity. ssh is simple, works on most servers I have access to.

> I barely think about these things as “apps” (I have no intention to distribute them). They’re artifacts of me making my computer do stuff for me, the way I want it to. As a Unix nerd, I’ve always been able to do this, in the language of the command line. Now, it’s just as easy to do that kind of work with graphical interfaces.

And so the author (second sentence of the post)

> I built my first serious Mac application a few months ago, and since then I’ve built more native UI thingies than in my entire career prior to that.

I still build my personal stuff either for the command line (not even TUIs) or in a HTML page but I can see the point of creating a native app. Unfortunately there are some drawbacks: I would have to create the app for GNOME Debian and for Android, while a web app runs on both, and I would have to go all in on vibe coding because my last serious GUI programming has been in the 90s with Motif. The latter point is more or less the point of the author (the LLM does it for you) but it means that programming personal stuff will cost money paid to the LLMs companies. More and more money at each price hike and the multi thousand dollars box to run local models only makes the expense happen immediately instead of diluting over a long period.

You can use them remotely over SSH connections, and they can survive disconects (within tmux). No VNC, or X11 forwarding needed.

They take less memory. compare vscode vs nvim.

Super fast to launch.

They can integrate with other TUIs and shell apps, shell-scripts, pipes

and lastly they do not contain Ads. lol

First, a TUI is usable with only the keyboard. Moving the mouse is a waste of time, and if you are using an application multiple hours a day, it can lead to being more productive.

Second, a TUI has no useless animations, elements, etc. It's not pretty, you have on the screen only the stuff you need to do your job, and you are not distracted by useless elements.

Third, a TUI works beautifully in a client/server world, where you have one central computer and dumb clients that connects to it, and the connection can be a simple serial connection as well as a network connection. It can be rendered even with an ESP32, making it suitable for embedded HMIs and all kind of computing scenarios.

Lastly, the user can choose the font, the colors, the size of the font that are best for him, usually a monospace font that it's surely better to read information multiple hours a day.

To me it's the opposite, GUI interfaces were born to make it intuitive to use a computer, but are not as efficient as TUI in terms of productivity.

Intentional or not, the rhetorical style of the title, plus the subtitle opening on the word "weird" before it's defined, has an ostracizing effect on me. I guess that it could have an ostracizing effect on others, though I can only speak for myself.

They don't support standard GUI shortcuts. They don't support drag-and-drop. I can't double-click a file and have it open in a TUI. They don't integrate with spotlight metadata. They don't ship document icons. They have terrible support for accessibility APIs. And so on...

Then why isn't it done more often? I suspect part of the reason is that most gui frameworks are not really designed for making dense economical interfaces.

> you probably don’t need a user interface on prod. You need a command line interface on prod that

I don't need one, but I often want one. Being able to run vim, htop, etc. on servers is quite useful. Also, it isn't just prod servers. It's also nice to run tuis on VMs and containers that don't have access to graphics.

> I’m not really building applications for other people to use. I’m building them for me. TUI affordances are an awfully big hit to take to get Linux users of programs I don’t even want to publish.

Ok. That's fine. But then why are you trying to convince other people not to make TUIs? If I make an app you find useful, wouldn't you prefer me to make a TUI you can run on your Mac to a linux-only GUI?

Put differently, a GUI application seems to subject you far more to the whims of Apple or Windows than a TUI and perhaps even a different run context. Maybe the permissions fiddling for this is insignificant. Is there a clear user contract from Apple or Microsoft about this?

Naturally, this is a non-issue in Linux.

Me: you exist so I can launch iTerm2, Chrome, and VS Code

MacOS: oh, my god

I can't ever imagine using walled garden graphics api in 2026. Particularly for work tooling

They're fast, efficient, work across SSH, in a tmux, and survive the almost daily browser upgrades.

And they are easy to run as separate users without VNC or sandbox hell.

Like do you want to think about X/Wayland isolation, or do you just want to get shit done?

I was alive back then already, and was a relief to finally be able to afford GUI powered computers.

One thing I think which is overlooked is the raw feeling of speed a good TUI can give you. The lowest grade consumer laptop could probably download my little dictionary program and still get true search-on-keystroke performance, because there is virtually nothing slowing down that path, no animations, no nothing. Now most of that comes down to the data structures involved and making sure nothing ever has to go over a network, but I still appreciate the sheer simplicity of the approach.

It's also nice to know that I can probably recompile this same exact code 50 years from now and still get it to run exactly as intended, since GUI frameworks have waxed and wanted in popularity, but terminals truly don't seem to be going anywhere.

- A lot of TUIs that run on your own machine and have a mature GUI alternative are indeed not necessary. I once tried to replace Spotify with ncspot, which was exactly falling into the "TUI is more advanced" trap.

- The real target of this article is people who treat TUI as a kind of identity, not people who have to work in a terminal because of their job and therefore have plenty of good reasons to use TUIs.

But the title and the general tone are still too clickbaity, which is kind of annoying. In reality, apart from a small portion of TUIs that were created just to follow the trend and clearly have better GUI alternatives, most TUIs are really just side tools that grow out of one premise that we have to work in the terminal.

And even those flashy TUI tools still make life easier for people who work in a terminal. If you prefer GUIs, fine, you don't have to use them, but that doesn't mean they have no users or no value.

You like GUIs and want to build/use ones that works in MacOS, that's perfect go ahead and build as much GUIs as you want. However, this wouldn't work for me as I know how bad developing native cross-platform GUI applications is.

The skills are useful, thanks for linking them! They'll be useful for my future projects like this. FWIW I've had good luck with using Claude Design first to do mocks.

At the same time, I think there's still the "is this worth doing a hyper-customized version of this software, if I'm also then responsible for fixing the bugs?". But I think increasingly as we improve our agentic workflows and make them more self-contained loops driving the result to completion, this becomes kind of a non-issue.

In general, I do think LLMs are bringing about a new age of hyper-customization, which I welcome.

The whole point of a TUI is that it can operate under no-GUI constraints.

I can SSH to any server and use a TUI because SSH can handle that. Running an entire GUI and setting up VNC/RDP would be horrendous by comparison.

Alternatively, a TUI can be a part of an interactive CLI command where it maintains context to your CLI session. For example, I have a tool that helps wrangle AWS accounts and regions where the CLI momentarily drops into a TUI to help pick between regions and accounts if not already specified in environment variables. If I had to type all that out every time it would be very annoying. Hitting some arrow keys or searching with a few letters beats the CLI experience, and a GUI experience is not possible.

It seems like an absolute slam dunk for AI. Create an integrated AI screen reader app that observes the screen and talks to you. It wouldn't even need to be a huge model. It could be a small local model that can just read and interpret UI elements and feed the results as tool use calls into an accessibility layer. It'd probably be a custom trained accessibility model, could probably be based on an existing small computer use model fine tuned for the purpose.

This seems like the "accessibility solution to end all accessibility solutions" that totally takes the burden out of the code and puts it in one place that can be uniformly improved.

This is the way. It just wasn't possible 5 years ago.

The low bandwidth / high latency lossy link problem is still a major issue. Cell phone service is sufficiently shitty in the area I live in that I have to use mosh to get a usable remote connection many times a year. Mosh is also quite useful while travelling! Got a crappy connection on a train or airplane? No problem. I have so much muscle memory with the mutt email client that nothing else has ever come close. Where's the equivalent of mutt's limit command in Thunderbird?

Try getting a usable VNC session when your cell phone hot spot is hitting 2-30 second ping times (yes -- thirty seconds) with only a handful of packets getting through.

Version 2 of the Amiga's operating system did a great thing in version 2 of AmigaOS which explicitly spelled out what conventions to apply (see Amiga User Interface Style Guide at https://archive.org/details/amiga-user-interface-style-guide). Modern GUIs that have weird meaningless buttons are infuriating. Even moreso when they lack obvious keyboard shortcuts.

So even professional tools all follow industry design and product trends which are too simplistic, don’t give you the info you need, and are optimized for abstract brand design or chasing metrics for the company, and not optimized for “how do I let my user accomplish their task as fast as possible”

It is, of course, completely subjective, but I know there are a fair number of people out there who agree with that statement.

If you want to automate from the perspective of what's on screen, tuis have no metadata. A button in a gui does have metadata associated with it, so you could automate 'click button x' where as in a TUI you'd be limited to clicking 'position x,y'

I agree that I found the article to be poorly written. Mainly because it takes a long time to make its point. I didn't really need to see a million examples of the author's vibe coded slop before getting to the topic which the title suggested the article would be about.

And if you meant "virtual machine" or "cloud" by saying "container", `waypipe ssh myhost`.

Good luck exhausting Claude. As long as you keep feeding in quarters, it will keep hacking Qt.

But a TUI needs dedicated understanding of terminal toolkits. That's not easy. A GUI is much more easy mode with electron, a bit of javascript and a GUI toolkit to design the UI, easy peasy. To me the TUI is the hard option.

I really enjoy TUIs though. I wish there was something like vscode in TUI. I like the responsiveness and the no-nonsense. No logos and other commercial bullshit, no huge amounts of whitespace that UX designers consider "best practice", just highly dense data.

Also, I've worked with some of these designers and their holy best industry practices have nothing to do with anything that benefits the user. They're all like: "Is the logo clear enough", "Does the user get drawn to the parts that make us the most money (like ads or premium articles)", "Is the user finding the thing we want to promote".

To me all websites should look like Hacker News does. Not like a "modern" newspaper site does.

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.

https://en.wikipedia.org/wiki/IBM_Common_User_Access

I think the real problem is as computers have become more mainstream, they've become more subject to whims of fashion. Consumer-focused companies don't want to be seen wearing last season's UI paradigm. Just watch Apple change things around...

Emacs Server and tmux would both like a word. Make the current tty show the app output.

Isn't it against both? Maybe I'm reading it wrong then, because things like these certainly seem against CLIs:

> Back in 1999, Neal Stephenson wrote an essay about command line interfaces that set the field of human-computer interaction back about 20 years. In it, he depicts the priesthood of Unix nerds wielding CLIs as powerful Morlocks, holding the entire computing industry on their shoulders.

> If you haven’t tried your hand at turning one of your 500 throwaway CLIs into a native app, you’re doing yourself a disservice.

Maybe I'm missed something else, but I certainly got the impression the author isn't very impressed by CLIs.

That's awesome, I have one too and I fell in love with it. I fixed up the old gif320 program to run properly on modern machines a while ago and made a C# port too:

https://github.com/ldyeax/gif320

https://github.com/ldyeax/Gif320Sharp/

How do you deal with modern programs not respecting TERM/LANG capabilities? I found even using man pages on my machine would sometimes result in the terminal getting caught up on some invalid byte sequence emitted from some unicode that snuck its way through or such.

I ended up writing a program I called VT320 Translator, or vt320t for the name of the binary, which in broad strokes runs your target program in a background terminal and sends curated updates to the VT320 while passing through keyboard input. (You can kind of approximate this with just screen and some other things but it doesn't end up being very good IME) This lets me do some neat things like translate unicode characters into DRCS (Dynamically Redefined Character Set) sequences that you can actually see on the VT320, use optimized heuristics for screen updates tuned to the exact hardware, etc.

At the core is a vtparse-based VT320 emulator that strives to be as accurate as possible with an accompanying diff generator from one emulator state to another. If you're interested I could get into more of what I've done here and even get the code onto my github - it's been private for a while because it's being used in an upcoming game demo but I could easily separate out the non-game-related parts that make up vt320t.

From what I undestand, the terminal is essentially a concatenative text buffer extended with control commands allowing you to move the cursor (pen) to draw more sophisticated stuff, and update UIs.

The logical way to extend this would be to allow genericdrawing commands over the protocol, at which point the whole thing starts sounding like X11.

I'm sure the Unix people at MIT in the 80s saw this as the natural evolution from text terminals to graphics based ones.

Not saying this is a bad idea, but sounds suspiciously like a retread of history.

Or you might want to stop before that, as you suggested, at targeting fixed size cells for rendering, and keeping the console-like UX throughout. I'm sure there's a sensible intermediate step, but if you want to do things like displaying graphs or images (turning the terminal into something that's halfway between a terminal emulator and a Jupyter notebook), it'd be awkward to respect the character grid and the non-square characters themselves.

I'm curious what you think about how far this new protocol should go, and in what direction. You mention 'semantics', as describing behavior, not just what gets drawn to the screen, which neither X11 nor tty does.

Except for, you know, every serious professional application ever.

Not so. GUIs absolutely should be keyboard-drivable, if they're written to the human interface specs of whichever platform they're hosted on. That doesn't mean they don't support being mouse-driven or even that mouse isn't the default, but in my experience if the developer has taken any sort of care with the interface then keyboard interaction will be at least as good, if not better, with the keyboard.

> And TUIs are only keyboard driven.

Not true either. There's a line in my .vimrc saying "set mouse-=a" specifically because I want to turn off the mouse in that particular TUI app. If a TUI app doesn't support the mouse they've just not added that support, it's not that it's not possible.

FWIW, most of Windows XP's utilities and included software was perfectly usable with a keyboard alone.

Plenty of TUIs support mouse to various extents too. Claude Code is an obvious example (try the scroll wheel for example).

I agree with you that TUIs are keyboard driven first though - and so you can be certain it will work well.

The problem is discoverability. You need to go out of your way to learn shortcuts.

Absolutely not.

There should be public browsers and public search engines. The private incentives are too much and software built for public needs can be extremely cheaper than their private counterparts once you remove the need to support advertising services.

y'all are slow learners if that's an issue for you, but React doing major breaking changes at least once a year is totally fine.

Cheers!

https://www.electronjs.org/docs/latest/api/app#apprequestsin...

and handle this event:

https://www.electronjs.org/docs/latest/api/app#event-second-...

I believe macos is the only OS that enforces single instance by default. If you start xterm five times on linux, you get five independent xterm processes.

It looks like macOS Finder tries to make it difficult to run two copies of a .app simultaneously, so I imagine many programs don't check for this case, but this is Hacker News, so we can use our hacker skills to try and do what they don't want us to: find the exe inside the bundle and run it directly from Finder, or run it from the terminal using its path. (This works for me with Ptacek's mdv app. Two copies of it end up in the dock.)

vscode, electron app, no problem opening multiple windows. Geany, gtk app, no problem opening multiple windows.

Can you give an example where this doesn't work?

You're wrong about GTK, Qt, WinUI and Electron though. They default to "do nothing" which eliminates the ability to even know that another instance exists. You have to manually program that.

TUI apps are multi-instance by default since the user can invoke the program in different pty sessions. The developer would have to actively fight that.

GUI SDKs generally require the developer to pick a solution. And it's easier to default to the simpler solution where you have one instance, one data model, one window.

Whether things might change in the future isn't relevant because we're talking about how things are today, not speculating about the future. And the time to change one's opinion is when reality changes, not ahead of time based on how you think things hopefully will be.

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.

Modern cloud systems shouldn't even have shell access, immutable containers with telemetry data.

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.

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.

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.

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.

Have you tried to write a GUI program lately? I suspect things may have changed. I can write one using Qt, EGUI, etc (Or many other options), and it will just work on Windows, Mac, Linux/Wayland, and Linux/X.

Basically, you write your application on top of a GUI framework that smooths over OS differences for you.

> TUIs run on any OS with minor patches to support quirks

So, which one is it?

I expanded on this point nearby: https://news.ycombinator.com/item?id=49400697

I think this is slightly wrong in two ways.

i) If you want platform native then reimplement the gui on every target platform. It’s as ”simple” as that.

If you need to ship to multiple platforms then preferably you need lots of plarform specific engineering in any case.

”I just want my hobby tool” scenario likely does not require cross platform support unless there is market for it. I mean rather than offering the tool on multiple platforms it should be offered on multiple languages first, perhaps. As soon as you are not writing the tool for yourself we are talking markets and distribution. Likely most people can chill out and just implement the gui for themselves (and not even publish it in githubb).

ii) cross platform quick-and-dirty way. Without screenreader support, multiple language and glyph support etc. Game ui:s look the same on all platforms. Websites look the same on all platforms.

There is place and time for deep ui engineering that respects the _critical_ cross platform issues like accessibility (screen readers etc) and different languages and scripts.

And then there is the situation where you want just few images to click. The latter is vastly simpler, fast and fun. But harder to convert to a professional quality gui experience. For small tools and MVPs this sounds like a fair tradeoff.

TUIs look bad everywhere, so that's strictly worse

So because TUIs look universally bad, they're better than cross-platform GUI?

I thought Claude could do anything nowadays.

https://ratatui.rs/concepts/backends/mouse-capture/

sounds like your terminal emulator is just crap, terminal and iterm on mac just work

If you mean what Claude Code does when you paste longer text, you can just press Cmd-V again to show the full text.