10 ms·

I feel the opposite, these kinds of projects imho are just moving terminals away from their key benefits, being simple, predictable, brutally functional with no

by zokier 4y ago

I feel the opposite, these kinds of projects imho are just moving terminals away from their key benefits, being simple, predictable, brutally functional with no gratuitous animations or flourishes, allowing no-hassle adaptation to any colortheme and font. Indeed, if all the features of modern graphical/web applications are dragged into terminals, then what is the point of using terminal anymore instead of native graphics/web? Furthermore the CLI proponent in me is saddened seeing this being largely another step away from CLI tools, although strictly speaking its true that the technology doesn't really define the interaction model.

leejoramo 4y ago
As someone who started out using pre-PC micro-computers (TRS-80, Apple ][, CP/M), I often would like to have access to a good suite of what we now call TUI programs. Having a common TUI would be a bonus, which briefly existed back in Borland’s heyday.
suction 4y ago
I agree. I immediately associate this with "show-off computing", which would probably look good on brain-dead TV shows about l33t haXors or "Anonymous" documentaries..but what's the point of slowing down your terminal even if it's just by 0.000001 seconds per keystroke only to look at Emojis? Will get old very fast.
happymellon 4y ago
Aren't these all just the next evolution of ncurses? That's not exactly new, and has been around long enough that I dont think these other project are moving the cli any further away.
agumonkey 4y ago
Most tui these days are not that functional. Compared to some as400 days apps or some old repls. Maybe recent projects are too frivolous but it's cool to see energy flowing there. More appealing than the heavy web imo.
clemens3 4y ago
Yes, and some are even intended only for the X terminal, not the real TTY. What is missing is a nice library for high level languages, as ncurses is famous and all that, but who, unless they are coding in C, can interface with it and even understand the documentation.
jonpalmisc 4y ago
I agree. Seeing the next generation of terminal apps that often seem to use "pretty" and "fancy" output formatting (read: "non-parseable" and "overly-decorated") makes me sad. Plain, simple, human-readable, and machine-parseable output can't be beat in my mind.
- touisteur 4y ago
  I'll take two examples of interesting TUIs I've enjoyed over the years: - clonezilla boots by default to a very simple tui, in the vein of make menuconfig on Linux. You can forward, backward, see all options, expert or simple, and check or uncheck them, and get some contextual help. Once you've set up everything, you can start cloning (or restoring) and it gives you simple progress bars. But before you start it gives you the command-line you can just run next time you want to do the exact same operation, which is quite handy... - AFL (the fuzzing tool) renewed the interest (to me at least) in 'progress TUIs'. Fuzzing can be very long and there are many things that usually flby2go well at first, so you want a dashboard and AFL provides one. Bonus: it's quite fun to look at and you end up trying to optimize some metrics (like the number of fuzzing cases per second...) since the TUI taunts you. For long-term monitoring AFL also maintains TSV files, with gnuplot scripts, but the UI makes the tool fun to use (doesn't hurt that AFL was so easy to use and landed crashes real quick). Praised be Michał Zalewski, aka lcamtuf. Both have an optional TUI that make the user experience so much more powerful (sorry I know we're nitpicking the word today...).
- dymk 4y ago
  Human-readable and machine-readable: not the same thing in the general case. Hence -porcelain and friends.
- bigyikes 4y ago
  I think there’s room for two categories of terminal apps. “Library” apps, and “User” apps. Library apps are intended to be consumed by other terminal apps, or by advanced users. User apps are strictly intended for humans. Take ffmpeg as an example. This is an excellent “library” app, so much that there are many actual libraries that are thin wrappers around it. It’s incredibly versatile. Do I want to interact with ffmpeg, though? For one-off tasks, no, I’ll just fire up VLC or some other tool instead of reading the ffmpeg man pages. Friendly, stylized, non-parseable, “user” terminal apps are a comfortable middle ground between hard-core “library” apps and full-on GUI apps.
gjulianm 4y ago
> Indeed, if all the features of modern graphical/web applications are dragged into terminals, then what is the point of using terminal anymore instead of native graphics/web? It's not "all the features", but just being able to build a basic interface without too much trouble is a blessing. Several use cases: - The most important: you don't have access to native graphics/web. A lot of people still need to work with remote servers where installing X is not viable and you can't access web ports. - Simplicity. For simple interfaces, it's far easier to just use the terminal with an extra Python dependency, than it is to create a regular UI that will require a graphical server, graphics libraries and such. A web interface would be even harder to do. - Easy adding interfaces to existing scripts. In fact I used textualize precisely for this, a script that launched some long running tasks, and I wanted to check the progress and be able to stop/throttle them. Launching a simple interface was easy enough, the rest of the script is still a regular Python script, but for that situation it just pops up a TUI. Also, it's not like TUI apps are new. A lot of terminal applications will launch a TUI sometimes because it's just easier. See for example some configuration dialogs for APT.
- mark_l_watson 4y ago
  Well said! I do a lot of my work over SSH or Mosh with tmux to remote servers. Projects like Textualize fulfill a real need here. Another cool hack: using a terminal backend for matplotlib to get inline plots while working via SSH/Mosh.
  - shabble 4y ago
    is there a backend in particular you've found to work? I've looked periodically for something in this vein, but the only one I can see right now is https://pypi.org/project/matplotlib-terminal/ https://pypi.org/project/matplotlib-terminal/ which I haven't had much luck getting running.
- tcoff91 4y ago
  Another great thing is that they are keyboard driven. Keyboard driven computing is far more powerful than using a mouse for many things.
BiteCode_dev 4y ago
Ah but that's the best part about TUI, you can fall back on the cli when you don't want the whole burrito.
- spicybright 4y ago
  Well, sticking with the analogy you're falling back to a taco made from different ingredients rather than just a part of the burrito. That can be intrusive if they decide to put chicken instead of ground beef in it. More concretely, it's using a totally different tool to get a subset of functionality you want vs other solutions. Personally I don't see a reason why one would do that, but more power to you if you do. If anything, ordering the taco sometimes is going to give you a more refined palette than if you got the same burrito each time (i.e. more experience in the problem space you're working in). (I'm getting hungry now...)
- stjohnswarts 4y ago
  .... if the tui app includes the functionality.
wiseowise 4y ago
Nobody forces you to use them.
woodrowbarlow 4y ago
in practice, i rarely see a tool that only offers a tui. most tui tools i encounter will respond helpfully to a `--help` flag and let me do anything i need from a script. any tool that doesn't is nearly useless - i don't think this is lost on most cli app developers, and i don't think it's at odds with the quest for 'pretty' UIs in interactive mode.
zozbot234 4y ago
> I feel the opposite, these kinds of projects imho are just moving terminals away from their key benefits, being simple, predictable, brutally functional with no gratuitous animations or flourishes This stuff is not "new" at all. It's just the latest twist on the ANSI art of old, and the use case is similar.
icedchai 4y ago
I feel the same. Simple ANSI color is enough. Call me old school, I don't want emojis in my terminal.
- cauefcr 4y ago
  With emojis you usually also get unicode, which is great for all the non-ascii-languages out there.
  - lmm 4y ago
    Except Japanese, where unicode is a big regression.
  - icedchai 4y ago
    Non-ASCII language support is good. Poop emojis and smileys? No thanks.
smolder 4y ago
I still use IRSSI as an IRC client, running in a screen session, through SSH, from multiple machines or even from my phone. The TUI in gnu screen over SSH setup is really handy for securely accessing a continuously-running application from anywhere you happen to be. I could use irccloud or some other web based thing, sure, but I like hosting my own services and having auth and device whitelisting uniformly handled the SSH way. Yet a chat client doesn't work well as a set of CLI commands as opposed to a TUI. Email from TUI might not be too bad either. There are lots of cases where I think it'd fit.
- nobleach 4y ago
  I got pretty used to using Mutt back in the day. I was pulling my email from my ISP via IMAP, running Procmail on it and putting it into maildirs. Somewhere along the lines I got really lazy and Gmail became "good enough". I will admit that it's much nicer for viewing and sending rich content.
windexh8er 4y ago
> Indeed, if all the features of modern graphical/web applications are dragged into terminals, then what is the point of using terminal anymore instead of native graphics/web? This isn't it at all. Great example: k9s [0]. Sure, you can manage k8s via kubectl. Or you can manage it via some web UI. And both of those options are a pain in the ass compared to what you can do in k9s in a few keystrokes. The TUI is the perfect combination, when done well, between a GUI and CLI apps. The interface can get out of the way and the usage can be driven by keyboard input vs the duality of click 'n type, or memorizing commands with a myriad of nested subcommands / flags. [0] https://k9scli.io/ https://k9scli.io/
thrown_22 4y ago
Dealing with the DOM is so bad in browsers webdevs want to escape it at any cost. What they don't realize is that the reason the DOM is bad is because of webdevs like them. So we will end up with a DOM in the terminal and the locust plague of JS developers will move somewhere else.

by zokier 4y ago

leejoramo 4y ago

As someone who started out using pre-PC micro-computers (TRS-80, Apple ][, CP/M), I often would like to have access to a good suite of what we now call TUI programs. Having a common TUI would be a bonus, which briefly existed back in Borland’s heyday.

suction 4y ago

I agree. I immediately associate this with "show-off computing", which would probably look good on brain-dead TV shows about l33t haXors or "Anonymous" documentaries..but what's the point of slowing down your terminal even if it's just by 0.000001 seconds per keystroke only to look at Emojis? Will get old very fast.

happymellon 4y ago

Aren't these all just the next evolution of ncurses? That's not exactly new, and has been around long enough that I dont think these other project are moving the cli any further away.

agumonkey 4y ago

Most tui these days are not that functional. Compared to some as400 days apps or some old repls. Maybe recent projects are too frivolous but it's cool to see energy flowing there. More appealing than the heavy web imo.

clemens3 4y ago

Yes, and some are even intended only for the X terminal, not the real TTY. What is missing is a nice library for high level languages, as ncurses is famous and all that, but who, unless they are coding in C, can interface with it and even understand the documentation.

jonpalmisc 4y ago

I agree. Seeing the next generation of terminal apps that often seem to use "pretty" and "fancy" output formatting (read: "non-parseable" and "overly-decorated") makes me sad. Plain, simple, human-readable, and machine-parseable output can't be beat in my mind.

touisteur 4y ago
I'll take two examples of interesting TUIs I've enjoyed over the years: - clonezilla boots by default to a very simple tui, in the vein of make menuconfig on Linux. You can forward, backward, see all options, expert or simple, and check or uncheck them, and get some contextual help. Once you've set up everything, you can start cloning (or restoring) and it gives you simple progress bars. But before you start it gives you the command-line you can just run next time you want to do the exact same operation, which is quite handy... - AFL (the fuzzing tool) renewed the interest (to me at least) in 'progress TUIs'. Fuzzing can be very long and there are many things that usually flby2go well at first, so you want a dashboard and AFL provides one. Bonus: it's quite fun to look at and you end up trying to optimize some metrics (like the number of fuzzing cases per second...) since the TUI taunts you. For long-term monitoring AFL also maintains TSV files, with gnuplot scripts, but the UI makes the tool fun to use (doesn't hurt that AFL was so easy to use and landed crashes real quick). Praised be Michał Zalewski, aka lcamtuf. Both have an optional TUI that make the user experience so much more powerful (sorry I know we're nitpicking the word today...).
dymk 4y ago
Human-readable and machine-readable: not the same thing in the general case. Hence -porcelain and friends.
bigyikes 4y ago
I think there’s room for two categories of terminal apps. “Library” apps, and “User” apps. Library apps are intended to be consumed by other terminal apps, or by advanced users. User apps are strictly intended for humans. Take ffmpeg as an example. This is an excellent “library” app, so much that there are many actual libraries that are thin wrappers around it. It’s incredibly versatile. Do I want to interact with ffmpeg, though? For one-off tasks, no, I’ll just fire up VLC or some other tool instead of reading the ffmpeg man pages. Friendly, stylized, non-parseable, “user” terminal apps are a comfortable middle ground between hard-core “library” apps and full-on GUI apps.

gjulianm 4y ago

> Indeed, if all the features of modern graphical/web applications are dragged into terminals, then what is the point of using terminal anymore instead of native graphics/web? It's not "all the features", but just being able to build a basic interface without too much trouble is a blessing. Several use cases: - The most important: you don't have access to native graphics/web. A lot of people still need to work with remote servers where installing X is not viable and you can't access web ports. - Simplicity. For simple interfaces, it's far easier to just use the terminal with an extra Python dependency, than it is to create a regular UI that will require a graphical server, graphics libraries and such. A web interface would be even harder to do. - Easy adding interfaces to existing scripts. In fact I used textualize precisely for this, a script that launched some long running tasks, and I wanted to check the progress and be able to stop/throttle them. Launching a simple interface was easy enough, the rest of the script is still a regular Python script, but for that situation it just pops up a TUI. Also, it's not like TUI apps are new. A lot of terminal applications will launch a TUI sometimes because it's just easier. See for example some configuration dialogs for APT.

mark_l_watson 4y ago
Well said! I do a lot of my work over SSH or Mosh with tmux to remote servers. Projects like Textualize fulfill a real need here. Another cool hack: using a terminal backend for matplotlib to get inline plots while working via SSH/Mosh.
- shabble 4y ago
  is there a backend in particular you've found to work? I've looked periodically for something in this vein, but the only one I can see right now is https://pypi.org/project/matplotlib-terminal/ https://pypi.org/project/matplotlib-terminal/ which I haven't had much luck getting running.
tcoff91 4y ago
Another great thing is that they are keyboard driven. Keyboard driven computing is far more powerful than using a mouse for many things.

BiteCode_dev 4y ago

Ah but that's the best part about TUI, you can fall back on the cli when you don't want the whole burrito.

spicybright 4y ago
Well, sticking with the analogy you're falling back to a taco made from different ingredients rather than just a part of the burrito. That can be intrusive if they decide to put chicken instead of ground beef in it. More concretely, it's using a totally different tool to get a subset of functionality you want vs other solutions. Personally I don't see a reason why one would do that, but more power to you if you do. If anything, ordering the taco sometimes is going to give you a more refined palette than if you got the same burrito each time (i.e. more experience in the problem space you're working in). (I'm getting hungry now...)
stjohnswarts 4y ago
.... if the tui app includes the functionality.

wiseowise 4y ago

Nobody forces you to use them.

woodrowbarlow 4y ago

in practice, i rarely see a tool that only offers a tui. most tui tools i encounter will respond helpfully to a `--help` flag and let me do anything i need from a script. any tool that doesn't is nearly useless - i don't think this is lost on most cli app developers, and i don't think it's at odds with the quest for 'pretty' UIs in interactive mode.

zozbot234 4y ago

> I feel the opposite, these kinds of projects imho are just moving terminals away from their key benefits, being simple, predictable, brutally functional with no gratuitous animations or flourishes This stuff is not "new" at all. It's just the latest twist on the ANSI art of old, and the use case is similar.

icedchai 4y ago

I feel the same. Simple ANSI color is enough. Call me old school, I don't want emojis in my terminal.

cauefcr 4y ago
With emojis you usually also get unicode, which is great for all the non-ascii-languages out there.
- lmm 4y ago
  Except Japanese, where unicode is a big regression.
- icedchai 4y ago
  Non-ASCII language support is good. Poop emojis and smileys? No thanks.

smolder 4y ago

I still use IRSSI as an IRC client, running in a screen session, through SSH, from multiple machines or even from my phone. The TUI in gnu screen over SSH setup is really handy for securely accessing a continuously-running application from anywhere you happen to be. I could use irccloud or some other web based thing, sure, but I like hosting my own services and having auth and device whitelisting uniformly handled the SSH way. Yet a chat client doesn't work well as a set of CLI commands as opposed to a TUI. Email from TUI might not be too bad either. There are lots of cases where I think it'd fit.

nobleach 4y ago
I got pretty used to using Mutt back in the day. I was pulling my email from my ISP via IMAP, running Procmail on it and putting it into maildirs. Somewhere along the lines I got really lazy and Gmail became "good enough". I will admit that it's much nicer for viewing and sending rich content.

windexh8er 4y ago

> Indeed, if all the features of modern graphical/web applications are dragged into terminals, then what is the point of using terminal anymore instead of native graphics/web? This isn't it at all. Great example: k9s [0]. Sure, you can manage k8s via kubectl. Or you can manage it via some web UI. And both of those options are a pain in the ass compared to what you can do in k9s in a few keystrokes. The TUI is the perfect combination, when done well, between a GUI and CLI apps. The interface can get out of the way and the usage can be driven by keyboard input vs the duality of click 'n type, or memorizing commands with a myriad of nested subcommands / flags. [0] https://k9scli.io/ https://k9scli.io/

thrown_22 4y ago

Dealing with the DOM is so bad in browsers webdevs want to escape it at any cost. What they don't realize is that the reason the DOM is bad is because of webdevs like them. So we will end up with a DOM in the terminal and the locust plague of JS developers will move somewhere else.