Hacker News Reader

Comment by MuffinFlavored | Hacker News Reader

Is there really a good reason in 2023 to have an interactive command line app? I've seen apps that at least maybe display a web server on localhost and then interact with it through the browser

Or Electron, etc.

I feel like command-line is alienating (deliberately, obviously) a huge portion of potential users. It basically guarantees whatever you made will only get used by tinkerers and not anybody serious (like if I have to pass a proof of concept pet project along to my manager, terminal might make it a non-starter 85% of the time)

View on HN

Yes definitely. Being able to easily access them via a remote shell is a killer feature IMO. Being able to pipe + automate is useful too if used non-interactively.

> Being able to easily access them via a remote shell is a killer feature IMO

You mean like being able to access a web page?

I have systems that have no web server and don't need one and adding one would add complexity and potential security risks to the system. Administration is only done via SSH.

There are just situations where the question goes the other way around: Is there any need for _more_ than a command line interface? No. Anyone competent enough to do anything meaningful on that server is also capable of doing it via command line.

I don't disagree with you, I'm just devil's advocating/showing an alternative viewpoint:

> Is there any need for _more_ than a command line interface?

Reworded: is there any need to make this harder to access than the equivalent of:

* kube-forwarder + open Chrome to http://localhost:3000

* ssh -L ...

* ngrok ...

All of the things you listed are still additional steps compared to just ssh and run the cli tool. Web UIs are nice too, for some things. But for many things, for at lot of us, the cli is where it’s at. And that is where it will continue to be.

We use Web UIs for some things, and cli tools for other things.

From my point of view, I'm not actively making it harder, I just don't make it as simple.

My development process usually starts in the terminal, as I am a terminal user and do iterative development there as well as tinkering with system interfaces.

A CLI is the natural first product of my development. Building a web interface is additional work. Also, it's been a decade since I have written any reasonable web frontend.

Granted, it's not a real TUI with curses and stuff, but I like to do some eye-candy with escape sequences. Because I am the most frequent user of my tools and I always like seeing something I deliberately made look good. :)

Thing is, if you can establish an SSH connection to the target machine, you can easily tunnel HTTP over that. And it doesn't need to have a dedicated web server service for that; the app can embed a localhost-only HTTP server directly.

One could argue that this is extra complexity... but I don't think this argument flies in comparison to "React for CLI", especially once you take into account all the dependencies.

Not every sshd is configured to allow port forwarding. In fact, I'd expect that on critical systems this is explicitly forbidden.

It's largely pointless to forbid it because once you have a byte stream (which you obviously do with ssh), you can tunnel whatever you want over it anyway. SSH own docs even point this out; man sshd_config(5):

"Note that disabling TCP forwarding does not improve security unless users are also denied shell access, as they can always install their own forwarders."

Hah, that is a fair point.

> tinkerers and not anybody serious

Counterpoint: tinkerers have a lot of overlap with the "serious" users for many CLI apps. People who want no-frills functionality. People who want things to run over N-deep nested SSH hops. Y'know, "unix-y" people (:

I use things like ncdu and vim on remote non-graphical systems all the time, for instance.

Though I do agree that non-interactive is the primary use-case for most CLI stuff.

1. Command line UIs are still an order of magnitude easier to build than even the most basic web page.

2. Every app doesn't have to target every user in the world. There is an entire category of developer-focused tooling that is very suitable for the command line.

3. There are plenty of contexts where the command line is the only interface available.

> Command line UIs are still an order of magnitude easier to build than even the most basic web page.

I think by "interactive command-line apps", parent commenter is talking more about "TUI applications" like e.g. `htop` or `vim`- which are persistent/interactive and treat the terminal as an interactive, 2d canvas into which they render the program content. As opposed to what I'd call "normal" CLI applications, which typically render output and expect user input on a line-by-line basis. (Like most REPLs, or the various ctl programs like `kubectl`, `pgctl`, etc.)

* lower bandwidth

* easier to write

* great if you use terminal only remote

* likely faster keyboard interaction when you get used to it.

At least that has been my take on the situation

The end-user of these things is not manager types... and that is both OK, and probably part of the point.

I personally love the growth of fancy, responsive TUI's. SSH-friendliness is a huge feature IMHO.

Just look at the "Who's using Ink?" section and that will answer your question.

Reply on news.ycombinator.com