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

Why TUIs are back

wiki.alcidesfonseca.com

Post reply on HN
Print view View original

321–330 of 443 posts

Re: Why TUIs are back

#321

Post by tptacek »

dlivingston wrote: post #303
tptacek wrote: post #94

Earlier quoted context omitted.

What does it matter how fragmented the platforms are? I feel like this isn't sinking in with people. I was chatting with a friend last night about a SwiftUI app that I'd built and he'd pitched in on. He then reimplemented --- didn't port it, reimplemented it , for WinUI, that night, with just a couple prompts. I am, in a proverbial sense, buying puts on Electron.

Sure, for small projects. Otherwise, you'd better have a solid plan in place for keeping your business logic in a common core, otherwise you'll just be writing N separate implementations where N = number of target platforms. Even in a world of agents, less code = better code.

Sure, I hear this (with current models). But consider the UX complexity of a typical TUI. Even with a TUI framework, you end up with serious coding lifts just to get things that the all the current native UI frameworks give you for free.

Re: Why TUIs are back

#322

Post by alex_young »

CLI. Wtf is a TUI? LLMs say it has some to do with interactivity in a menu or something, but believe me, we had this all in the 80’s. Nothing new here, but the truth is the CLI is better faster and cheaper. Pick all three.

Re: Why TUIs are back

#323

Post by danny_codes »

mgaunard wrote: post #293
Ferret7446 wrote: post #192

Earlier quoted context omitted.

TUIs are much closer to GUIs than CLIs. As a CLI enjoyer, I was resigned to the small win that at least many people distinguish TUI and CLI now but then I saw your comment. There are quite a few GUIs that can be navigated with keyboard, e.g. menu bars can usually be activated with alt or win and single key presses

As I said, the advantage of the TUI is that they avoid context-switching.

Except the part where you switch into the TUI from a normal bash prompt, and your normal bash invocations get eaten by the parser..

Which is essentially exactly the same thing, except your UI is trash relative to a normal GUI

Re: Why TUIs are back

#324

Post by billforsternz »

skydhash wrote: post #242
maccard wrote: post #178

Earlier quoted context omitted.

I’ve been using vim bindings for a decade and never knew this…

It's about the ascii code and terminal code. (Almost?) Every non-printing character can be entered with Ctrl+ . With Control pressed, D is eot (end of transmission), G is bell, H is backspace, I is line feed (next line), L is form feed (new page), M is carriage return (start of line), Z is substitute, and [ is escape.

I is tab ('\x09' or '\t') and J is new line ('\x0a' or '\n'). These Ctrl combinations follow a predictable linear mapping to the control character section of the ASCII table. Basically Ctrl subtracts 0x40, so I is 0x49, Ctrl I is 0x09.

Re: Why TUIs are back

#325

Post by cameldrv »

One thing I like about TUIs is that they can usually be completely operated from the keyboard. Most GUI apps have flows that you need the mouse for, and they’re slow if have to do that often.

Re: Why TUIs are back

#326

Post by keithnz »

mr_mitm wrote: post #46
cassepipe wrote: post #37

> The hardcore, moved to vim or emacs, trading immediate feedback and higher usability for the steepest learning curve I’ve seen The only hard part about vim is to be forced to strecth the finger up to Escape for what is essentially the most essential function in a modal editor: Going back to command mode. The ideal workflow is do a quick edit and go back to command ("normal") mode instantly. The fact that Escape is…

Unfortunately, remapping escape to caps lock can lead to serious friction if you have to work with different laptops a lot, like I do. The muscle memory gets in the way a lot.

I map it on all my computers, works well, if I end up in an environment where I don't have the mapping I just use Ctrl-[ or stretch.

When I end up helping other devs and use their non vim setups...now that really trips me up. Capitals everywhere, random hjkls ... I have to really slow myself down when using a "normal" editor.

Re: Why TUIs are back

#328

Post by d3Xt3r »

nickjj wrote: post #11

I do like CLI tools and TUIs but in the article it mentions Gnome style apps don't fit the look. That sounds like a limitation of Omarchy. It's not too bad to theme GTK apps and have them all look a consistent way. For example I use Tokyonight Moon and Gruvbox and they both have GTK themes that look great for Firefox, Thunar, GIMP, LibreOffice and more. I don't use Omarchy but here's a few screenshots https://x.com/n…

Those apps you mentioned are not your typical modern GTK4/libadwaita apps, so naturally you can theme them. It's the GTK4 apps - and ones which use libadwaita specifically - that cause grief.

- Firefox: Uses its own custom rendering engine but interfaces with GTK3. It respects standard GTK3 themes.

- Thunar: Uses GTK3

- GIMP: Since v3.0, they now use GTK3

- LibreOffice: Uses its own visual framework (VCL) but has a GTK3 plugin to draw its window frame and menus, and it also respects the system theme.

None of these use libadwaita, let alone GTK4, so they're not good examples unfortunately.

Re: Why TUIs are back

#329

Post by d3Xt3r »

dlivingston wrote: post #48
Ekaros wrote: post #42

Earlier quoted context omitted.

Why not instead have Linux just run Win32 applications?

That's really not a solution. You're not targeting the host OS for that, which instantly kills that approach for everything other than "we need this to run on Linux and don't care how." You're shipping all of WINE with it. You're sticking out like a sore thumb with Win32 widgets next to the rest of your GTK apps. Etc etc etc.

- You don't have to ship Wine with it, you can just make it a runtime/package dependency. Most distros have Wine in their repos anyways, so there's no need to bundle it. I don't see this conceptually being any different than shipping a Python app for instance.

- You can make Wine apps inherit the system theme, well, at least the colors. Although it will still look out of place, but it's not much different to the issues with running a Qt app in GNOME, or a GTK app in KDE. Wine in this case can be considered as just another UI toolkit that has the same problem that all UI toolkits have in Linux.

- Finally, the resource overhead of Wine is far, far lesser compared to Electron, which is a basically packing in a full-fledged browser.

Re: Why TUIs are back

#330

Post by paradox460 »

orbital-decay wrote: post #203
agumonkey wrote: post #187

Earlier quoted context omitted.

Claude code amplified the trend hundred fold but there was already a significant increase of TUI since the days of go fzf, rust ratatui and python rich. My bet would be a desire to do away with heavy browser based UI and the curiosity of trying to test the limits of terminal based rendering.

TUI is popular because a) there are no native GUI frameworks for simple tools that are easy, fast, and simple to develop in at the same time, and b) low fidelity lets you pretend being a UI/UX developer without really being one. The rest is abysmal. It's not automatable at all (the article is wrong on that point), less readable (monospace/no images), very limited (try making a DAW in it...), relies on a ton of ancien…

>try making a DAW in it

The very early DAWs kind of had TUIs, to be fair. Things like the Fairlight CMI

https://adamstrange.itch.io/qasarbeach

Post reply on HN