Stop Making TUIs

Make me

stop making your blog take 20% width on my 4k monitor

I understand the point the article's making, and in fact, I believe it's a good one. Ultimately I continue to prefer TUIs over GUIs for one reason: Practically nobody will target TUIs for advertisements, doom scroll content, AI slop, any kind of marketing, etc.

I'm currently building a winamp clone that works over ssh, using textual. So I'll have to hard disagree

Accessibility is a giant problem with almost every open source GUI library too.

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.

If your program use slow internet like tui I cant write tui program. no problem.

TUIs are just a kind of GUI. And rarely a particularly good kind

Sorry, we Morlocks actually prefer the CLI to the TUI.

TUIs are popular because Unix didn't have graphics. Plan9 had graphics but didn't catch on. Making us living in an emulated terminal device.

aerc is the best program I've ever used. tmux from anywhere. May TUIs never die.

> 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. You see where I’m going with this.

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.

I've mentioned this before, but the rise of the TUI is the simply the systemic failure of remote GUIs.

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.

So wrong.

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?

Another trend is to bring graphical features into terminal emulators thanks to the initial protocol and implementation work in Kitty with the Kitty Graphics Protocol. https://sw.kovidgoyal.net/kitty/graphics-protocol/

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

Isn’t the GUI version of a TUI just an Electron app?

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

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

Stop telling me what to do.

Or, perhaps, stop making pomodoro apps, todo list apps with budgeting as their 'unique' killer feature, and damned Markdown viewers. Seriously.

I completely disagree. I love using TUIs, the apps are lighter and faster and work great.

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.

Or, you know what, don't listen to strangers on internet telling you what you should do. Do what you want.

Do more TUIs.

People are unable to do good GUIs. The web shows this; completely disregarding any UI guidelines by web people established since 80s is a proof that most people have no idea how to make GUIs.

I don't know how to make a good GUI. That's why I need good templates and strong guidelines, discipline and spend long time on design. Most people don't do that.

TUI is much, much easier. It's also possible to do bad TUIs, but it's easier to do a good TUI than to do an average GUI.

What is the complaint in the article really about?

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

Ah, people who build and enjoy TUIs have never built a GUI. What a wonderful assumption to make about people :)

curses!

Wow that's a lot of snark

This piece is just marketing for all the authors slop coded projects

Have there been any attempts at graphical TUIs?

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

Are there not disparities between running an application in the terminal and running a native GUI? I can only speak for macOS, but my experience with bespoke native GUI applications of my own or other developers (pre-built distributions in GitHub assets) is that I must first pass through the layers of the macOS security model: doing a right-click dance to launch the application, changing permissions in security settings, etc. I assume the experience is different depending on how you set up Xcode to compile, how it's signed, etc (I have zero experience with how this works). That said, I do not recall being subjected to any of this using terminal applications.

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.

No. In fact, I will make another TUI just to spite this article. Maybe two.

TUIs are great as a layer above bunch of commands with too many commandline parameters and flags. For everything else .. no, thank you.

>Finally, I can think of one strong argument for TUIs: they’re cross-platform.

>[...]

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

You can't ssh into a swift app.

Never.

TUI and Rust surged back in popularity when programmers through frameworks became detached from the actual work and needing to differentiate from all others in the even playing field. It's like turntables to Hipsters. Now with LLMs it is only going to get worse.

In the age of graphical user interfaces, direct manipulation, info visualization, WebGPU in the browser, and frontier AI, it seems ridiculous to have a VT100 escape code interpreter between you and your LLM.

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

No

Text is an extremely information dense medium. It makes sense for user interfaces to be centered around text. This keeps the focus on the data and its transformation.

If writing a GUI was as easy and stable as writing a TUI, yeah we should write more GUIs. I can run practically any ancient TUI program on a terminal emulator, but running a GUI program that uses an older version of GTK means going through dependency hell to compile and install all the old library versions. If they even compile with the new GCC... I really wish we had a standard way to spawn a webview (or similar) and connect stdin/out to it.

Going into this article my attitude was "don't tell me what to do!" but I kind of see his point.

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.

> Next: TUIs work over SSH connections. If you need a user interface on prod, it’s going to be a TUI.

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.

nuuu

how about we stop making single window UIs

Make guis where guis make sense. I, for one, like to stay in my tmux session as much as possible.

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

Incoherent and far too long .

Lists a bunch of things .

Fails to make any clear points .

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

I find it hilarious that Claude is still a piece of shit web app. Claude can just make apps! Why not release native ones? At least the TUI is pretty good.

for me : make TUIs and GUIs.

I feel like this is the typical MacOS user stereotype.. Cosmetics over efficiency.

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

I don't like TUIs. And, having built several, and then having the experience of building meaningfully complex native UI for the first time in my career, I couldn't help noticing how much of the tedious work of putting a TUI together, even with a good framework, is already solved (and solved well) by the native framework. TUIs force you to implement things native UI developers aren't supposed to fuck with at all. That was radicalizing for me.

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.

If there's anything that's anachronistic, it's native apps.

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)