Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building a TUI is easy now

hatchet.run

Post reply on HN
Print view View original

221–230 of 262 posts

Re: Building a TUI is easy now

#221

Post by [deleted] »

Marazan wrote: post #174
bob1029 wrote: post #157

I genuinely don't understand the TUI obsession for LLM applications. Go watch copilot drive VS2026 if you've never seen it in action. There is no way you are going to be able to communicate this same amount of information via plain text in the same amount of time. I can catch a lot of bad stuff mid-flight because I can actually multitask my UI and click into diffs as files are edited in real time.

It's LARPing. Everyone knows all the best programmers are using the command line firing off one line Awk scripts that look like runic incantations occasionally opening vim to do stuff at blazing warp speed. So the AI tools people build want to take on those trappings to convince people they are serious tools for grown ups. Ignore that they are basically a full web stack React/CSS conglomeration - feel the L33t hacker…

[deleted]

Re: Building a TUI is easy now

#222

Post by PantaloonFlames »

nozzlegear wrote: post #203
oblio wrote: post #200

Earlier quoted context omitted.

It's a clearly marked quote that adds more details. It's perfectly fine.

It's not adding more details in this case, it's adding incorrect information. CSS gradients are rasterized once during paint into a bitmap by the browser. Theres no recalculation going on per scroll unless something invalidates the gradient bitmap, and it doesn't matter how many steps the gradient has or how complicated it is. The real issue is something was causing the container with the gradient to repaint on every…

That’s helpful information but it doesn’t mean the use of Gemini is unwelcome. A human could have rendered the initial analysis too, and then you could have just replied to the human, correcting him or her. Why is the source of the analysis such an issue?

Re: Building a TUI is easy now

#223

Post by wredcoll »

1718627440 wrote: post #180
fyredge wrote: post #179

Earlier quoted context omitted.

I don't quite agree with this. Feature discovery is much easier in GUI when most commonly used features are either in the first layer of menu or in standard hotkeys. In the worst case, you would do a search in GUIs that provide them. In CLI / TUI, no such function is present and you would basically have to man and scroll through all possible commands to find it, though I guess grep helps.

You accept search in GUI, but don't in man pages? Scrolling through actions in a tree-like menu structure is ok, but through a tree-like structure in the --help output is not? Feels inconsistent. The whole benefit of text-based interface is that search, filter and transformation is always available and completely independent of the running program. I can see the visual discoverability aspect for GUIs, but for the vis…

>The whole benefit of text-based interface is that search, filter and transformation is always available

That's the point about TUIs, they remove this benefit. You can't (practically) grep the output of btop or vim or whatever.

Re: Building a TUI is easy now

#224

Post by anthk »

Marazan wrote: post #174
bob1029 wrote: post #157

I genuinely don't understand the TUI obsession for LLM applications. Go watch copilot drive VS2026 if you've never seen it in action. There is no way you are going to be able to communicate this same amount of information via plain text in the same amount of time. I can catch a lot of bad stuff mid-flight because I can actually multitask my UI and click into diffs as files are edited in real time.

It's LARPing. Everyone knows all the best programmers are using the command line firing off one line Awk scripts that look like runic incantations occasionally opening vim to do stuff at blazing warp speed. So the AI tools people build want to take on those trappings to convince people they are serious tools for grown ups. Ignore that they are basically a full web stack React/CSS conglomeration - feel the L33t hacker…

Actual hackers will use AWK and anything else... over Acme under 9front which is pretty much graphical, and current Emacs users will use a graphical setup with tons of keybindings, commands and Elisp functions. The best of both worlds. You have both the scriptability, keyboard shortcuts and mouse for selection and quick pointng.

Re: Building a TUI is easy now

#225

Post by jxdxbx »

quotemstr wrote: post #210
jxdxbx wrote: post #195

Earlier quoted context omitted.

A TUI app feels like a native terminal app like I have used for my entire computing life, in DOS and then Linux. Electron apps feel like web apps no matter how good they are. I stopped using 1Password when it became an Electron app and became super janky. Discord, Slack, VS Code, the Signal desktop app, all suck UI-wise compared to actual native Mac apps, which even with Liquid Ass, are still better than using web te…

Again this word "feels". Is it not just nostalgia?

No. Good TUI apps are predictable and fast, like good native GUI apps. They follow set patterns. Familiarity and following standard conventions is not just "nostalgia" -- maybe a little is in there -- but it makes apps more usable. And, for cross-platform apps, it's a cross-platform standard. I'd rather have a TUI app following TUI conventions than a cross-platform app that is just a freeform mish-mash. Like, this week I've been making a TUI replacement for Plexamp which has great features but its Mac app is just like a scrolling webpage. If I am going to have a GUI app that is more than a tiny toy or utility I want it to follow each platform's native conventions and use its native GUI components or to not even bother. I will grant that Electron has made strides in terms of properly integrating into each host OS (using the full Mac menu bar, the correct keyboard shortcuts, accessibility features and so on) so the situation is not as bad as it once was. And also, plenty of people use and have used terminal editors and other tools by choice, for years, and not just because they are connecting to remote servers. A keyboard-first interface can be quite fast and they are more natural in TUIs.

Re: Building a TUI is easy now

#226

Post by CoolCold »

nout wrote: 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.

I had bad feelings on MC, as it's flaky.

Far Manager or Dos Navigator are much better IMO.

Re: Building a TUI is easy now

#227

Post by einpoklum »

simgt wrote: post #173
dwb wrote: 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…

What is great about them is the constraints they impose on the UI designer. I spend so much time finding actions in apps like Zed, Obsidian or Slack because menus and rows of buttons are not cool anymore. I'd really want explicit UIs from 2000, but in the mean time TUIs feel like an improvement.

> because menus and rows of buttons are not cool anymore.

They are, which is why most desktop applications use them.

(And please help remind the GNOME people of this fact.)

Re: Building a TUI is easy now

#228

Post by einpoklum »

9dev wrote: post #150
jazzyb wrote: post #101

Earlier quoted context omitted.

> How many developers are using VSCode? How does that number compare with Emacs/Vim? Perhaps I'm in some sort of "TUI bubble", but I'd bet good money that Emacs/Vim users outnumber VSCode users by an order of magnitude. But maybe I'm just surrounded by *nix devs.

No need to guess, the SO survey is probably still representative of the state of development environments: https://survey.stackoverflow.co/2025/technology#1-dev-id-es Note that respondents may use multiple tools, but around 76% answered VSCode, whereas 24% answered Vim. So, I’d wager you’re indeed in a *nix bubble.

The SO survey was skewed to begin with, and by 2025 it covers a much reduced fraction of past users. See:

https://meta.stackoverflow.com/q/437921/1593077

Not that your conclusion is necessarily wrong of course.

Re: Building a TUI is easy now

#229

Post by dwb »

basilikum wrote: post #214
dwb wrote: 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 like that they are integrated into the terminal and stay in the terminal. For most things my terminal multiplexer is essentially my tiling window manager and everything that breaks out of that via its own window is very unergonomic and breaks the structured logic of my workflow. Technically just having a full GUI inside the boundaries of a terminal would be fine for a lot of things. But it's also one of these thing…

Yeah, I sympathise. This is another angle on the sorry state of affairs we find ourselves in.

Re: Building a TUI is easy now

#230

Post by nozzlegear »

PantaloonFlames wrote: post #222
nozzlegear wrote: post #203

Earlier quoted context omitted.

It's not adding more details in this case, it's adding incorrect information. CSS gradients are rasterized once during paint into a bitmap by the browser. Theres no recalculation going on per scroll unless something invalidates the gradient bitmap, and it doesn't matter how many steps the gradient has or how complicated it is. The real issue is something was causing the container with the gradient to repaint on every…

That’s helpful information but it doesn’t mean the use of Gemini is unwelcome. A human could have rendered the initial analysis too, and then you could have just replied to the human, correcting him or her. Why is the source of the analysis such an issue?

IMO it's because people have learned not to trust LLMs. It's like using AI code generators – they're a useful tool if you know what you're doing, but you need to review the material it produces and verify that it works (in this case, verify that what it says is correct). When they're used as a source in conversations, we never know if the "dev" has "reviewed the code," so to speak, or just copy and pasted.

As for why people don't like LLMs being wrong versus a human being wrong, I think it's twofold:

1. LLMs have a nasty penchant for sounding overly confident and "bullshitting" their way to an answer in a way that most humans don't. Where we'd say "I'm not sure," an LLM will say "It's obviously this."

2. This is speculation, but at least when a human is wrong you can say "hey you're wrong because of [fact]," and they'll usually learn from that. We can't do that with an LLM because they don't learn (in the way humans do), and in this situation they're a degree removed from the conversation anyway.

Post reply on HN