5 ms·
> 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 nativ
by 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 agoWell 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 agois 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 agoAnother great thing is that they are keyboard driven. Keyboard driven computing is far more powerful than using a mouse for many things.
- pjmlp 4y agoNot really, as proven by keyboard + mouse chords.
- zasdffaa 4y agoPowerful? you mean it can do more than is actually possible to do with a mouse?
- agentwiggles 4y agoPower is the amount of work done over a period of time, so even if you can do the same exact set of things with a mouse and keyboard, if the keyboard is faster at doing them, it's more powerful. You can do all your text entry by clicking keys on an on-screen keyboard if you like, but saying that a physical keyboard is a more "powerful" way to enter text seems reasonable to me. (sorry in advance, I know this is needlessly "well ackchually" lol)
- zasdffaa 4y ago> but saying that a physical keyboard is a more "powerful" way to enter text seems reasonable to me No. It's faster and that's all. So call it by that word which is very precise. If you say 'power' = 'speed' then you've destroyed the meaning of one of those words, just for the modern habit of co-opting a fancier word for a simpler one. I'd prefer people didn't do that, and differentiated 'speed' from a thing you call power which indicates "I can't do that at all, at any speed". If you don't like bullshit marketing and PR, don't follow it.
- jjav 4y ago> No. It's faster and that's all. So call it by that word which is very precise. Definition of "power" is work done over some unit of time, so OP was using it precisely.
- clucas 4y agoInteresting, so do you avoid describing one programming language as being "more powerful" than another? They're all Turing complete, after all... it's just a question of how fast you can develop in one, right?
- kiawe_fire 4y agoWhile TUI apps are not new, and I’m not inherently against them (I very much like them), I am worried that the recent proliferation of frameworks is going to give a lot of developers a shiny new toy to build fancy apps with that will now be much more limited as a result. IMO, the simple input/output and parsable nature of a good CLI app lends itself to chainability, scriptability, and reusability that is still more powerful and flexible than just about anything else. Put in other terms, you can build a GUI/TUI over one or more CLI apps, but you can’t build CLI apps over one or more GUI/TUI apps. If developers using these tools realize the need to build these things in layers and not force usage of their app solely through the TUI, then great - everyone wins. But I’m pessimistic that will be the case.
- gjulianm 4y agoI don’t know, even with good frameworks TUI interfaces are harder to do than simple CLI. From what I’ve seen, interfaces made with these framework aren’t replacing CLI tools, just augmenting them. In fact I think the use cases are usually completely different, when a TUI comes up it’s because you really need interactivity and not just “launch command and see the output”. And viceversa, I don’t see anyone making TUIs for use cases that are just sending commands and seeing output.
- deleted 4y ago[deleted]
- charcircuit 4y agoI think you are being blinded by UNIXisms. If you want something that is chainable, scriptable, and reusable you want a library. You can build many different user interfaces over the same library. Unlike a CLI you don't have to serialize and deserialize into strings and doing error handling is much easier.
- badsectoracula 4y agoA library limits you to the language it is written in, meanwhile a CLI program can be combined/chained with other CLI programs regardless of the language it is written - you can mix programs written in C, Java, C#, Haskell, Rust, Python, Go, etc without caring about these languages or even having their development tools/compilers installed just so you can tie them together.