Live data from Hacker News

Building a TUI is easy now

hatchet.run

61–70 of 262 posts

Re: Building a TUI is easy now

#61
post #29

The problem with TUI's, that we have all Stockholm syndrom'd ourselves, is that I can't use the mouse cursor to click to the position on the screen and edit the command line.

It is possible. Terminals have supported mouse interactions for a long time.

possible isn't the same as supported and working. A non-terminal hunt-and-peck typer sits down and is presented with a terminal, what's the second that happens when they're typing? they make a mistake and try to click on the word they misspelled, and it doesn't work.

Re: Building a TUI is easy now

#62
post #22

I think mc (Midnight Commander) is still one of the best TUIs available - it's very close in capability to the GUI versions (like Double Commander) and it has the benefits of tuis - like that you can run it on a remote system. It looks outdated, but I'm actually now working on a new skin that will hopefully be included in the next release of mc.

Kudos to all mc developers!

Re: Building a TUI is easy now

#63

As LLMs consume all our compute resources and drive up prices for the compute hardware on which we run applications, the silver lining is that LLMs are helpful in implementing tooling without a heavy stack so it will run quickly on a lower-spec computer. I've achieved 3 and 4 orders of magnitude CPU performance boosts and 50% RAM reductions using C in places I wouldn't normally and by selecting/designing efficient da…

They’re also great for reducing dependencies. What used to be a new dependency and 100 sub-dependencies from npm can now be 200 lines of 0-import JS.

Re: Building a TUI is easy now

#64

Alex, It's somewhat ironic that a web page about performant terminal user interfaces uses gratuitously complex CSS mask compositing and cubic gradients which reduce smooth scrolling on my 1 year-old, high-end Dell XPS laptop (>$3k) to Commodore 64 level (on default 'Balanced' battery mode). While it's pretty , it's also just a very subtle, non-critical background animation effect. Not being a CSS guru myself, here's…

You're right - I'll remove that now until we can get it more performant or drop it altogether. This wasn't something we caught during testing. I appreciate the feedback!

Re: Building a TUI is easy now

#65
TUIs are great fun and Claude can make beautiful ones with a little ratatui action super fast. However, the downside of these are that you can't use them with Claude Code so while I have a few I prefer to also have a prompt-response CLI function since that's better for lots of things.

Re: Building a TUI is easy now

#66
post #48

I think TUIs-that-want-to-be-GUIs (as opposed to terminal commands just outputting plain text) are sad. Mainly because they’re largely inaccessible. They flatten the structure of a UI under a character stream. You’re forced to use it exactly the way it was designed and no different. Modern GUIs, even web pages too, expose enough structure to the OS to let you use it more freely. I get why people build TUIs, but it’s…

I disagree, I think TUIs are a great fit in some problem domains. Think for instance the Debian package configuration dialogs -- they're far more comfortable than the same questions without a TUI, and still work over a serial console if you have to use one. For tools like various kinds of "top", there's many potential tools you can use to the same end and intentionally using one that draws CPU graphs over one that ju…

Sure, I said I understand why people build them. I’ve used a lot of them. And yes with the tools we have you’re right, but I’m more lamenting the wonky, kind of archaic, unintegrated, only-semi-composable toolset that we have. No fundamental reason why you couldn’t deliver more structured UIs directly over SSH or a serial console, it’s just that in this timeline that didn’t happen yet (apart from X forwarding, which isn’t quite what I’m on about).

Re: Building a TUI is easy now

#67

As LLMs consume all our compute resources and drive up prices for the compute hardware on which we run applications, the silver lining is that LLMs are helpful in implementing tooling without a heavy stack so it will run quickly on a lower-spec computer. I've achieved 3 and 4 orders of magnitude CPU performance boosts and 50% RAM reductions using C in places I wouldn't normally and by selecting/designing efficient da…

I suspect that a native GUI, or even something like GPUI or Flutter would be still more performant than TUI's, which are bound by the limitations of emulating terminals.

Re: Building a TUI is easy now

#69
post #65

TUIs are great fun and Claude can make beautiful ones with a little ratatui action super fast. However, the downside of these are that you can't use them with Claude Code so while I have a few I prefer to also have a prompt-response CLI function since that's better for lots of things.

Not sure if this satisfies your requirements, but I've gotten Claude Code to run commands in tmux and view their output (including debugging my NeoVim config), so I think that a TUI is at least accessible, even though it would likely bloat the context window far more than a simple CLI.

Re: Building a TUI is easy now

#70
post #48

I think TUIs-that-want-to-be-GUIs (as opposed to terminal commands just outputting plain text) are sad. Mainly because they’re largely inaccessible. They flatten the structure of a UI under a character stream. You’re forced to use it exactly the way it was designed and no different. Modern GUIs, even web pages too, expose enough structure to the OS to let you use it more freely. I get why people build TUIs, but it’s…

Yes, but this kind of dashboard was never going to be accessible anyway. It's a dense visual representation of vast system state with constant real-time fluctuation. Even in a browser, it would be hell to navigate the constantly changing state with a screen reader. And visually increasing the scale and contrast defeats the purpose of the density of the original display. If you need to support screen readers, your UI…

I’m not just talking about screen readers, though they are important. I mean “accessible” more generally. Yes you could build a specific UI for each kind of user, but that seems far less likely to cover as many uses as building one UI that is structured, programmatically navigable, etc.
Post reply on HN