4 ms·

While 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 gi

While 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 ago
I 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 ago
I 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 ago
  A 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.
pjmlp 4y ago
Eventually they will rediscover Expect as well, then we will have a renaissance of TUI scripting languages.

gjulianm 4y ago

I 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 ago

I 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 ago
A 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.

pjmlp 4y ago

Eventually they will rediscover Expect as well, then we will have a renaissance of TUI scripting languages.