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

91–100 of 262 posts

Re: Building a TUI is easy now

#91

Post by danudey »

dale_glass wrote: post #58
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 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…

The difference there, in Debian's case at least, is that there is a distinction between the frontend and the configuration backend; you're probably most familiar with the `newt` frontend, but there's also `text` (for textual entry without using curses or anything), `noninteractive` (for just use the defaults), gnome, kde, teletype, or even 'web' which does not seem to work effectively but is a neat idea regardless.

TUIs which are just TUI views of data you can get otherwise are fine; TUIs which are the only way to interact with something... less so.

Re: Building a TUI is easy now

#92

Post by HarHarVeryFunny »

fragmede wrote: post #61
willm wrote: post #29

Earlier quoted context omitted.

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.

A terminal emulator in a GUI environment such as Linux is expected to play nice with the GUI and support mouse-based select, copy and paste, as well as being a terminal emulator, and this means that the terminal itself is consuming mouse events to support text selection.

If you wanted to write a shell that has mouse support you could certainly do so, and this would be based on sending escape codes to the terminal to tell it to return mouse events as input rather than let the terminal consume them itself. The shell could then itself support the clipboard if it wanted to, as well as support mouse editing.

I just googled it, and apparently "fish shell" does exactly this, but your hypothetical user is more likely to stumble upon a bash shell which is letting the terminal emulator consume the mouse events and support copy and paste.

Re: Building a TUI is easy now

#93

Post by coldtea »

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 think TUIs-that-want-to-be-GUIs (as opposed to terminal commands just outputting plain text) are sad.

You'd think that, but you'd be wrong. Case in point from Emacs/Vim and the Borland IDEs to Claude, plus all kinds of handy utils from mc and htop to mutt.

>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

That's not necessarily bad. Not everything has to be open ended.

Re: Building a TUI is easy now

#94

Post by coldtea »

logicprog wrote: post #67
elevation wrote: post #25

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.

>would be still more performant than TUI's, which are bound by the limitations of emulating terminals.

That's what makes them great. As opposed to modern "minimal" waste of space UIs or the Electron crappage.

Re: Building a TUI is easy now

#96

Post by coldtea »

mseepgood wrote: post #30
elevation wrote: post #25

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…

The question is how many decades each user of your software would have to use it in order to offset, through the optimisation it provides, the energy consumption you burned through with LLMs.

Would it be that many? Asked AI to do some rough calculation, and it spit that:

Making 50 SOTA AI requests per day ≈ running a 10W LED bulb for about 2.5 hours per day

Given I usually have 2-3 lights on all day in the house, that's like 1500 LLM requests per day (which sounds quite more than I do).

So even a month worth of requests for building some software doesn't sound that much. Having a local beefy traditional build server compling or running tests for 4 hours a day would be like ~7,600 requests/day

Re: Building a TUI is easy now

#97

Post by khannn »

mrandish wrote: post #60

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…

Notice how many times Claude Code was mentioned in this blog post nee advertisement?

Re: Building a TUI is easy now

#98

Post by utilize1808 »

coldtea wrote: post #93
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 think TUIs-that-want-to-be-GUIs (as opposed to terminal commands just outputting plain text) are sad. You'd think that, but you'd be wrong. Case in point from Emacs/Vim and the Borland IDEs to Claude, plus all kinds of handy utils from mc and htop to mutt. > 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…

How many developers are using VSCode? How does that number compare with Emacs/Vim?

In many ways, GUI was developed as the natural evolution of TUI. X server, with its client-server architecture, is meant to allow you to interact with remote sessions via "casted" GUI rather than a terminal.

Countless engineers spent many man-hours to develop theories and frameworks for creating GUI for a reason.

TUI just got the nostalgia "coolness".

Re: Building a TUI is easy now

#99

Post by normie3000 »

sunshowers wrote: post #77
logicprog wrote: post #67

Earlier quoted context omitted.

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.

A very important thing about constraints is that they also liberate. TUIs automatically work over ssh, can be suspended with ctrl-z and such, and the keyboard focus has resulted in helpful conventions like ctrl-R that tend to not be as prominent in GUIs.

What does ctrl-R do?

Re: Building a TUI is easy now

#100

Post by coldtea »

utilize1808 wrote: post #98
coldtea wrote: post #93

Earlier quoted context omitted.

> I think TUIs-that-want-to-be-GUIs (as opposed to terminal commands just outputting plain text) are sad. You'd think that, but you'd be wrong. Case in point from Emacs/Vim and the Borland IDEs to Claude, plus all kinds of handy utils from mc and htop to mutt. > 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…

How many developers are using VSCode? How does that number compare with Emacs/Vim? In many ways, GUI was developed as the natural evolution of TUI. X server, with its client-server architecture, is meant to allow you to interact with remote sessions via "casted" GUI rather than a terminal. Countless engineers spent many man-hours to develop theories and frameworks for creating GUI for a reason. TUI just got the nosta…

>How many developers are using VSCode? How does that number compare with Emacs/Vim?

How many people eat microwave meals? How many eat gourmet Michelin star dishes?

I don't care "how many use VSCode". My argument Emacs/Vim have great, well loved TUIs. And they are used by a huge number of the most respected coders in the industry. Whether a million React jockeys use VSCode doesn't negate this.

>Countless engineers spent many man-hours to develop theories and frameworks for creating GUI for a reason.

Yes, it sells to the masses. Countless food industry scientists aspend many man-hours to develop detrimental ultra-processed crap for a reason too.

Post reply on HN