TUI is a kind of self defense. big corps create and kill gui frameworks faster that one can learn them. Browser based ui is a real waste of resources (and also evolve in a absurd pace). The Console is a last resort to write small (understandable) gui that work on many platforms.

No. I like them.

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 .

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

You know what's awesome about TUIs? They live in a tab in my terminal. 95% of the time, my system has three windows open: terminal, browser, Signal.

Please, make more TUIs and web apps, so they can live in my terminal or my browser.

I am team TUI for the matter.

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

Hot take: Too many people are building GUIs for what should just be a TUI, and vice versa

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.

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

One of the biggest upsides of TUIs over GUIs is that I can run any number of TUI instances.

Meanwhile a GUI's developer has to decide to grace me with the ability to even open more than one window. "A tabbed interface will be sufficient!" -- yay, I'll never be able to view two screens of info at the same time.

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.

Counterpoint: Build more TUIs in Rust using Ratatui: https://ratatui.rs/

Why? Because just look at the examples on that page.

I'm a fan of a TUI, I think because they are usually pretty intuitive out of necessity. I can usually feel the developer's skill level in the user experience.

Haha, no. For a while, many years ago, it seemed TUIs were indeed on the way out, but then they were relived by the awesome work of people who wrote GPU-accelerated terminals, widget libraries, who extended terminals with more colors and the ability to show Unicode and graphics.

I salute you, heros.

TUIs are just an accessibility nightmare without any of the advantages of a CLI like scriptability. Truly, Truly horrible

I absolutely love TUIs, they can live in a pane in my terminal, run via SSH on remote machines, use hardly any resources and are very flexible.

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

Make more TUIs ....

The main thing I like is that TUIs are guaranteed to be navigable by keyboard. So many non-TUI apps don't include shortcuts at all for critical actions. It makes the first week of using the app more efficient and the entire rest of your life less so. Add on to that, I can probably run a TUI on my server. Or my cloud instance. And in my sandbox. Over SSH.

So: do make TUIs and bind their keys to Vi-like shortcuts as much as possible and I will use your app every time over a GUI app.

Pro tip for Mac users - install Karabiner and bind right-Alt + jklm to cursor movements. Immediate VIM navigation through the whole OS.

Making TUIs isn't the issue. Making them with JS/TS, and in general an ecosystem designed for the web, is the problem. I've used some really good TUI apps in the past, but all these new ones mostly based on web tech are just... sloppily bad. Probably because the dev would rather be in the web browser where it's naturally colorful and scripts can run wild, but mostly-static terminal is where things are currently at. And they're using LLMs, which don't have sufficient data on web-tech-in-terminal since it wasn't really a thing until now, which also ensures they will likely never gain enough data on decent patterns since almost nobody will be engineering said patterns, creating a permanently slop-ridden cycle as future models only have slop projects to learn from.

Yesterday I was flipping between some TUIs, native apps, web apps and an electron app. I think it was only because I was trying to do a lot in each of them I became really aware of the latency lag in some of these.

There are real advantages of TUIs: less CPU; sometimes I want to be using a personal TUI on a personal dev server quickly from a work laptop at lunchtime and an ssh + tmux + TUI is perfect; most modern TUI libraries are significantly less painful to work with than most modern web app frontend libraries; I can change the font size of my terminal easily if I need to, more easily than native (but not web app). But by far the biggest, is they just generally tend to be very fast and responsive compared to everything else.

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.

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?

As someone who works on a very GUI-centric OS (i.e. Mac), TUIs just don't integrate very well with the rest of the non-Terminal ecosystem.

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

Question about Markdown, I'm intrigued by this. I recently bought FS Notes but it has some bizarre bugs on startup. I might consider some other tool, perhaps also something with better MD support. Is this library you mentioned truly fast? https://github.com/gonzalezreal/swift-markdown-ui

Do more TUIs. Please.

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

Clickbaity title. Boring show off of vibe coded apps that only make sense to the author, disguised as think piece. This post has it all.

"I built my first serious Mac application"

I will just stop here. No hates for macs, but your typical cli/tui software devoper is concerned about making their software run on almost anything with an actual os. As soon as I see references to specific operating systems or platform specific libraries my bullshit meter goes off.

I was expecting an article about methology and tooling to develop guis, got an apple fan telling stories about ai use.

To me TUI have a better user experience than graphical applications. And considering the amount of companies that are still using decades old AS/400 systems instead of new ERP system I'm probably not the only one to think it like this.

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.

I like to have my freedom in choosing what software I want to make/use, without anyone dictating what is better for me.

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.

It’s a matter of preference: Everything OP says about GUI development getting easier is also true about TUI development getting easier.

I think it depends on how you work and what the application does. When I'm in a flow state I need things that are fast. GUIs, even on my relatively fast mac are not terribly fast. They take more time to start. They require more screen real-estate, and more management of same.

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.

I like TUIs a lot and I use a TUI instead of a GUI as long as there is one available, but please note the main point of the post, the very last sentence

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

If you want to live only in the terminal, you can also use one of the text-based browsers [1] instead of Chrome, Firefox, etc. browsh [2] can also play YouTube videos if you'd like.

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

I like TUIs, and I chose to build e.g. https://taskusanakirja.com/ as a TUI for a couple of reasons, some of which are in this article and some not. Cross platform compatibility was a big one since at the time I started building it I didn't actually have a Windows or Mac machine handy to test this out.

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.

The LLM fetishists really do themselves a disservice with these wild, over-the-top statements about AI capabilities. I’d be willing to bet money that giving Claude a screenshot of part of this blog post would not producing “something useful” for any reasonable interpretation of useful. This reminds me of a line from Peter Diamandis’ Abundance (basically the only thing I remember) that described Google using a “stroke of HTML” to organize the worlds information.

The CLI/TUI split in the article is right, but to me the more interesting boundary now is human-facing vs agent-facing interfaces. For most things TUIs lose on both sides.

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

Yeah, I think I agree with this. I think making GUIs and reverse engineering proprietary APIs are two things that frontier models make really pleasant - e.g. I made a menu-bar app (very similar to your temperatures dropdown, similar graph, SwiftUI) which connects via bluetooth to my Inkbird CO2 sensor, graphs the CO2 level over time, and looks fabulous.

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.

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)

> But there’s one of the problems with TUIs: even with a good framework, like Ratatui, Textual, or Bubbletea, you’re fighting the terminal to come asymptotically close to what every native framework does well out of the box. Scrolling and scroll targets are an obvious example.

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

"Stop liking things I don't like!!"

"I’m glipping balls like everybody else."

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

As a ratatui library maintainer, NO - please don't stop making TUIs ;)

As a developer outside of that, I love the scratch the itch apps stuff mentioned in here. I have a vibe coded SwiftUI chess repertoire builder app that fits in that same sort of space that I'm currently working on, where I'd probably not have chosen to explore the idea if not for coding agents.

I agree with the article that the terminal is an odd shape which you're fighting against historical specs, etc. The key observation I have though is that the mismatch of terminal apps and libraries to deal with this are all fundamentally built around character cells and cursor movement plus various CSI/OSC/ASC/DEC/xterm/... protocols which are complex and have varying support and interact in weird ways.

To get a good terminal UX, I think the answer to this is probably to throw all that compatibility mess away and redesign a modern terminal protocol that bakes in accessibility, regions, scrolling, selection, proper keyboard, etc.

I know Mitchell Hashimoto has a bit of a different perspective on this, which seems like it's to define some more protocol stuff and continue to build up on things. I think that probably gets to 95% pretty well. But a 100% good is a full replacement.

    TUI that runs on any OS |----------------| TUI without any compatibility mess

No.

No.

Agree with the rest of the comments here: keep making TUIs. Fully keyboard-driven, compact interfaces that live in my terminal with the rest of my CLI devtools are the best!

  - yazi as a file explorer
  - lazygit for git
  - tmux/zellij as multiplexers
  - fzf left and right for a bunch of utils (terminal history, switching between projects in zellij/tmux when working in multi-project workspaces, etc)
  - neovim as a text editor
  - glow for markdown reading
  - currently on pi for my home harness, CC at work

Tabs vs spaces.

I’ve always appreciated the positive side of TUIs and appreciated less the positive side of GUIs. I didn’t grow up with a computer at all and in one of my first adult jobs I had to use a TUI at Papa John’s for punching in orders, it was 20x faster than anything I used after it at other restaurants that were GUI driven (keyboard speed wins for me, fit my brain perfectly). I think I learned it in 5 minutes. I was just a normy trying to pay bills.

I dunno why we gotta be insulting to people’s preferences, the article is genuinely bad about this.

Old man yells at terminal.

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.

The nice thing about TUIs is: they are platform independent. Whereas with SwiftUI apps you are bound to macOS.

You can't ssh into a swift app.

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

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

"Q: Son, what is window manager needed for? A: Running multiple terminals on one display."

I agree with the author, as long as you keep the good bits of TUIs, i.e. keyboard driven and fast. There is absolutely no reason why a GUI shouldn't be strictly better than a TUI.

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.

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.

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

Keep making TUIs. Keep making whatever you want. These "terminals weren't made for that" kind of comments are a bit tiresome. I can run TUIs on machines I only have ssh access to and they are often leaner than the corresponding GUI variant - though perhaps less so with today's fancier TUIs. 'top' has a TUI and isn't exactly new, some interactivity - yes, even in a terminal - can be nice.

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.

Maybe on macOS you have great APIs, libraries and toolkits for making high quality GUIs, but if you're wanting to write open source software or target open source platforms, your options are limited and poor.

On the Linux/BSD side, most toolkits are of not great quality, you'll inherit all sorts of subtle bugs and quirky behaviours. Most of the software that's of _great_ quality doesn't use the toolkit, but interfaces with the compositor directly. The effort for developing GUIs under such circumstances is dramatically higher than a TUI, and a TUI is usually "good enough".

I really would prefer GUIs for a lot of things. But when a TUI takes a few weeks to make, the equivalent GUI would take a few months to make.

It's funny I'm currently creating a TUI. A mutt like mail client. I didn't have any second though to consider GUI for the project because it's so ridiculous.

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

The typical TUI fan is a nerd with no clue about typography so therefore they don't notice any problem with being shown elements that have no reason to be monospaced in monospace.

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

Stop telling people what to do :/

Let people enjoy things.

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

A wiki that's somehow not in a browser, a tv remote replacement without obvious keyboard shortcuts, a jupyter lookalike with no editing (as far as I can tell), and two chat interfaces with skills. Good for you, but not like how I use computers.

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

I like chocolate I like vanilla

I think OP is missing the point of TUIs: They kinda work everywhere. While I need to fuck around with a operation systems native UI libraries like WinUI, SwiftUI, GTK, etc. I can just build an app in the terminal and be fine with it running on almost all platforms.

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

It's interesting going to order auto parts or construction materials. All old tui like console programs if you look at what they use. They are good and quick at them too.

TUIs are really the worst of both worlds IMHO.

The one advantage that a terminal has, is that commands can be concise and scriptable. But that only really applies to CLI.

A TUI is just a poor man emulation of a GUI, without any advantages.

Stop making TUIs, stop making GUIs, and make more CLIs. Claude can read the help text and efficiently drive it directly, without needing a vision model in the loop. Then I can go outside and do more something more interesting while Claude plays computers without me.

> Nothing is stopping you from designing a dense and economical GUI.

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?

The aggressive headline is a hook which is what bloggers have to do I guess, but it doesn't need to be polarizing. The argument boils down to "If you made a TUI only because making a native app is hard, then LLM's fix that for you now".

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.

Have there been any attempts at graphical TUIs?

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

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

Tbh in a time where more and more applications are shipped as vibecoded electron based bloated bug-collections that are slow and take stupid amounts of resources i'd rather have even more TUI's than less.....

TUIs are by definition keyboard first.

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.

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.

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.

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

No, thanks. I don't want a mere "user" interface, I want a programmer's interface. I don't like the command line because I'm a "unix nerd", I like it because it lets me rapidly cook up little programs and execute them.

Here's an example I just pulled out of my shell history:

  c=3afba1a; reset; laptop "virtdev ssh liblinux -- git -C liblinux format-patch -1 ${c} --stdout" | tee /dev/tty | termux-clipboard-set

This huge oneliner clears the screen, logs into my laptop via ssh, then logs into my development virtual machine, then generates a patch from the specified commit, and this data gets piped into my Termux terminal and my phone's clipboard. Then I paste it into the ChatGPT app for code review.

I didn't need to think to write this, I just wrote it right there in the terminal using the shell's line editor, just because I needed it, and it completely solved my problem. It's as easy as pressing up on keyboard now, and I can easily turn it into a script if needed. Nobody had to bend over backwards to add monstruous features to the apps to accomodate me. I knew what my computer needed to do, and I made it do it.

In my opinion we need more of this, not less. More unix and less iphones.

    lsblk -l | grep -i part | cut -d " " -f 1 | xargs -I{} sudo mount -m /dev/{} /mnt/{} # automount_all

More TUIs, and with eye candies too! :)

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)

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

Benefit of TUIs is that sometimes they are extension of CLI.

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.

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.

Just adding in my perspective:

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.

You can't tell someone who doesn't like the command line why it's so awesome.

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!

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

TUIs are good for users, because they don't require using mouse as much - I didn't see this argument covered.

this blog post is mostly shadowboxing and showing off their llm-made software; kind of disappointing

TUIs allow you to have infinitely many running in tmux and also work over ssh so there is that.

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

built my first serious Mac application This the first thing if they stop making tuis we linhx users will get slow electron apps I prefer a tui over an eletron app or even worse not getting any apps at all

Wow that's a lot of snark

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

Unfortunately we seem to live in an era where your mainstream choices for a cross platform app are "Electron taking 1GB when idle" and TUI.

> shorthand inputs that make common operations (like “take the gradient of this expression”) quick to type

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

> Stop Making TUIs

No, I don't think I will :)

It's great for admin tools, alongside CLIs.

It's portable, it's fast, it's discoverable, it has zero bullshit effects, it's as secure as my shell, it's efficient.

And what is this point about agents making it easy to generate GUIs ? They are equally good (if not better) at generating TUIs using any of the great frameworks for this.

> Which is why I would never hand-write this program. Instead, I summoned it.

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.

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

This pretense that the entire value of source code is the "spec" / "requirement" is alarming.

The value of the code is how well-formed the spec is + how well tested it is in the real world. So prompt / mockup cannot replace code.

>> Because I assume that agents work better with a filesystem to grovel

What the what now?

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

Make me

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.

No

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

Counter proposal: stop making gui, ONLY make TUI.

+ seamless cli integration + network portable + graphics (!!) with modern emulators + always themable + scriptable + works with any navigation modality + you can copy & paste entire segments of your window easily + easy to consistently theme + did i mention entirely network/os transparent? + blazing fast

tongue-in-cheeck mostly, but i assure tfa, the tui serves useful functions. i spend >80% of my time in terminal, and having a pane to do some task a gui would otherwise be needed for is a sheer blessing. being able to essentially move my session to a laptop is wonderful. no mucking with screen sizes or weird X11 wonkery (if you still use x11). what would blow my socks clean off is a tui/gui+gui/tui backend pair so we can have our tui and you can gui it tooie.

Sorry, no.

I don't want to forward a whole desktop environment just because I want to use a small application I have written for myself.

TUIs are much more portable, easier on eyes, can be information dense, and resistant to lassiez-faire UI library changes on platforms. They don't need GPUs to render, megabytes of RAM to run, great amounts of bandwidth to access from afar.

I'll write a library for the functionality, and will slap a TUI on top. You want a GUI, write it yourself. Everything is GPLv3 licensed. You can do whatever you want as long as you respect the license.

I wonder if devs are flocking to TUIs to gatekeep against normies building apps

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.

I think I'll keep making TUIs but thanks.

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

Just like MCP is for Desktop users and useless otherwise -- GUIs are a solution to a created problem.. of users not being able to read and write very well because they don't practice.

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.

From tui i can copy (all) text and run it over ssh, only a good image protocol is missing for me

Three broad notes:

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

for me : make TUIs and GUIs.

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.

Bit of an overstatement, but I agree with part of it:

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

Never.

TUIs, work on several operating systems. I use same set of apps across Mac, windows and Linux.

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

user interfaces are for users. people who deal with words may prefer an advanced TUI. Others may find graphical interfaces more useful. describe, don't prescribe. let a thousand flowers bloom.

Stop telling me what to do.

Oh dear, the comments here are a bit disturbing and hilarious. The "Linux" mindset simply does not comprehend that proper UI's can still be made. Maybe that also includes the Windows mindset these days. Most of us macOS users never rejected TUI's, but we always had world class GUI's.

Yes, stop making TUIs. Make GUIs in Terminals!

It’s ridiculous how far we have fallen behind the Terminal GUIs from the early 90ies. Look at the Turbo Pascal IDE and business apps built with it. Windows, window management, scrolling in windows, rich dialogs. Everything there. While many modern TUIs are just lists with numbers you can select. Everything is pretty rudimentary

I was missing a real terminal GUI library for some software I built. The rudimentary libraries did not work for me.

That‘s why I took Free Vision (the Turbo Vision derivative for Free Pascal) and ported it with the help of Claude Code over to modern Delphi, then modernised the object system and added lots of features and from there we ported it to go.

There are still lots of bugs and oversights (some caused by me not really knowing how original TV worked) that I fix as I go along using it for real projects.

https://github.com/oldwired/fv-delphi-modern https://github.com/oldwired/fv-go

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

TUIs work where I do. I don't want to juggle another window unless I need to. Tmux gives me better ways of organizing my work than most display managers. Most of the useful things I do end up calling other shell commands, and it's nice having terminal right there. Ctrl-t / fg are also uniquely powerful.

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.

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.

The site layout is great for reading, so props to the author.

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.

And the very first app example is a Mac-only markdown viewer. If only it was a TUI; then I could try it out and partake in this conversation!

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

Some folks love to live in the golden age of CP/M, MS-DOS, and timesharing green and amber terminals, for whatever reason.

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

The day we get a truly good, native binding, resource efficient, cross platform UI framework, then I will agree wholeheartedly.

I love a GUI in many cases! But if I'm building something, I personally want it across Linux and MacOS at least (personal and work, respectively). TUI answers that problem quickly, easily, effectively, and efficiently.

I'm actually amazed that we have never gotten to a really good UI framework that is cross platform. I really just want something like SwiftUI that's truly cross platform, personally. There are a million arguments to say that we do have cross platform GUIs, but all of them lack in some major way.

Sometimes I wonder if people are just writing these for the sake of having written something.

One point for TUIs I haven't seen mentioned: they're faster for coding agents to iterate on. No need for screenshots or computer use. Agents have made GUIs cheap, but have made TUIs even cheaper, both to build and verify.

Personally, I don't like being told what to do in a title. And personally, my hackles raise when that's combined with in-group jargon.

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.

TUI are often inferior to GUI from a user perspective, but not necessarily by much.

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.

But TUIs make me feel smart, and my work feel important and esoteric.

how about we stop making single window UIs

Hard disagree. Make more TUIs!

TUIs have downsides like accessibility, poor mouse support, but work really well if you focus on keyboard input. It is a better/faster input mode to begin with, especially for power users, but also for average people; you'd be surprised at how much more user-friendly an arrow-keys driven UI can be vs modern web interfaces.

I've been building my own TUI framework [1] and getting amazing results. Good TUIs are more of a GUI than a dumb text terminal.

If we had a cross-platform usable GUI framework, and more consistency across OSes, the story would be different.

[1] https://github.com/ricardobeat/milktea

Honestly I would stop making TUIs if we had a better alternative to Electron/Tauri for multi-platform apps that run natively. I will keep building TUIs because they are the easiest way to reach support all OSes.

The people that keep arguing for TUIs for everything seem like religious fundamentalists that can't be convinced with any argument that user interfaces should be about the user, and need to adapt to the task at hand.

Every time I use Claude Code, I'm wondering why the hell I'm regressing to the level of a machine. I paste an image that I want fixed, and I don't see the preview of it. I can't cut or edit text somewhere in the middle of a long sentence like in a normal user interface. I can't visualize any helpful graphics, not even Latex. I'm forced to interface like a machine when I'm a human being.

Why can't developers understanding that GUIs and TUIs both have their usage, it just depends on the task?

I'm fine to use vim over ssh into a server, just don't force me to edit fine typography with it.

MacOS: what is my purpose

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

nuuu

Funnily enough I wrote a similar blog about this in the era preceding LLM assistance.

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/

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.

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

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.

You can shit on TUIs but macOS isn’t the panacea of GUIs. This really compromises the argument. In fact I’d argue it’s one of the worst platforms for GUIs.

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.

How about build whatever interface makes sense for the user? Doesn't matter if it's a TUI, GUI, speech interface, or some physically actuated / haptic feedback based system. Do what makes intuitive sense to the user and provides enough expressive power to get their job done without overwhelming them.

This reeks of AI slop.

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

Found this article to be a bit of a slog, burying the lede until after you’ve sifted through a rambling list of irrelevant vibe coded apps by OP. The actual argument came across in places but I am unpersuaded. Unsure if that’s due to the article structure or the argument’s own merits.

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.

LLM agent harnesses make it possible to do: CLI, TUI, REST API, web front end + Electron, native (I do macOS first, which then makes iOS/iPadOS almost trivial, followed by Android), and if I’m feeling ambitious, Windows (native) and Linux (usually Qt).

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.

The article is interesting even if you disagree with the headline conclusion -- don't skip it on that basis.

curses!

One big benefit of TUIs is that they lower the bar for customer adoption. Before Claude Code, it was unthinkable to come up with a mass-market TUI because most users would not use it simply because it's a terminal. Now, it can even be an advantage. Even inexperienced users are no longer afraid of the terminal.

Contentious topic but I have hard time comprehending line height scroll instead of smooth Web like experience and everything rendered in the same font size. I guess it’s a habit for people who started early and never got to use web applications enough to develop distaste to TUI scrolling patterns.

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.

Stop telling people what to do (or not).

While GUIs have some legitimate use cases, I prefer TUIs if I can get away with it. Its just text, ssh friendly, constraint in a beautiful way that still allows endless possibilities.