Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • "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.

  • This is covered towards the end of the article.
  • > 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.

  • > It's portable

    Not really?

    > it's fast

    It's not - most terminals are ridiculously slow, and each TUI framework requires its own hacks to do partial "repaints" using ANSI escapes, because clearing and redrawing the entire screen (yes, just a screen of monospace text!) is unworkable.

    > it's discoverable

    With no ergonomic way to build a menu bar, display hints/tooltips, or even support modified keyboard shortcuts well across platforms? I don’t think it is.

    > it's as secure as my shell

    Extraordinarily insecure, in other words.

    > it's efficient

    As above.

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

  • Maybe you should re-examine your priors, because reality is sending you a lot of data that refutes them. If it were feasible to do this, I think it would be done by now. There are a lot of reasons it is very difficult, and while there may be no reason it is impossible, something can become practically impossible when you pile constraint after constraint on it.

    One example - wxWidgets exist, and wxDart exist, but getting to something half as usable as Flutter from there is almost impossible. I defy you to even build a layout engine that works on all three platforms. After that, you still have to find answers for theming, spacing, responsive behavior, component composition, inspection/debugging, hot reload, accessibility conventions and on and on.

  • "a really good UI framework that is cross platform."

    Just curious re: the obvious example of "The Web" - do you consider it "not good" or "not really a cross-platform UI framework" as such?

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

  • TUIs also live where the rest of the interesting stuff happens, in the terninal. They don't force you to move to a different env
  • > They don't need GPUs to render, megabytes of RAM to run

    They do these days, because you still need a terminal emulator and those are then basically GUIs in themselves. Ain't the 80s anymore :^)

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

  • Use Qt or Flutter
  • 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.

  • I have mixed feelings in this debate, too. The big issue with GUIs is that they’ve become so bloated, especially as the default framework is now often electron apps. Web based frameworks tend to start keeling when large amounts of data need to be handled in the DOM, etc. When I use slack and discord, I sigh when I start seeing UI rendering lag when I switch channels and projects.

    Though there’s been some recent progress in alternative models, the fact is native frameworks have some catching up to do. Some in particular (SwiftUI) are downright awful

  • Sounds like you ought to try Claude Desktop.
  • I had the same feeling. I've since been using Claude Desktop and I have the convenience of the UI with Claude Code built right in. It even supports the same commands.
  • I have to agree with this. Ever since Claude Code released I always asked why it had to be a TUI but the sentiment I saw was that it was more powerful for some reason. I never bought that argument.

    Now I use Codex UI which is miles better than any other tool I used.

  • I honestly get better results out of claude at the command line than inside a GUI. Maybe I am just imagining things. But a lot of times GUIs are just graphical abstractions of TUIs. It is cruft that makes things visually easier and more appealing. That does not stop people from mastering TUIs and unlocking extra potential as they typically offer much deeper customization.

    Once you go down this path, it is hard to go back. Very few tasks, apart from things like Photoshop and Revit, really require me to be at a GUI these days. And with MCP a lot of that is going away.

  • Claude Code should be heavily sandboxed to be used safely. Are you advocating requiring a gfx stack in the sandbox just to use Claude Code?
  • > The people that keep arguing for TUIs… Every time I use Claude Code

    As far as I can tell, practically everyone arguing for TUIs thinks Claude Code is a horrible example.

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

    We are users.

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

    Isn't that the case for most TUI apps? They tend to serve quite specific purposes. Nobody writes a WYSIWYG word processor in a TUI. Because you can't and even if you could somehow with sixels it would work horribly bad.

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

  • I like TUIs for largely the same reasons as you, but I don't think this is actually a valid criticism of the article. It specifically addresses this by pointing out that you can make your GUI keyboard driven if you want to, so this isn't really an advantage of TUIs per se. It just happens that TUIs tend to be keyboard focussed while GUIs tend to be mouse focussed. But that's a design choice rather than an inherent property of TUIs vs GUIs.

    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.

  • What you're comparing is really "keyboard-driven" via "mouse-drive".

    A GUI can be keyboard-driven and as fast as a TUI. The sad truth is that the status quo for GUIs is absolutely terrible, and most were rushed out and not properly tested to check if they're really usable without a mouse.

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

  • That’s interesting. The browser is also a host of multi-instance applications which makes it a good platform for this. The ChatGPT web app works better with multiple tabs than selecting its in-app sessions in a single tab. Good observation.
  • Only if the program is designed to be safe to run in parallel. Which can be done with desktop apps too - and they'll run more efficiently as well, as the windows share memory.
  • The other thing is, I've had "computer use" on my LLMs since way before they had vision and macos integration. Since in TUIs both control and data is text, they can simply send text to a pty.

    There is an opencode plugin for this opencode-pty.

    Terminals + browsers is all I want for most apps.

    Native GTK/QT is really good, but I only want it for "system" things like a clipboard manager or file manager settings app and things like that.

  • On the contrary, multiple windows is normal and the default but tabbed interfaces became popular due to bloated GUI design. This is all down to design and not due to it being a GUI, though.
  • Why would this be true? The way "single instance mode" usually works is by taking a global mutex or making a lock file. What makes this not possible for TUI apps? Isn't it just culture?