One reason to prefer textual UIs is that you can use them from any computer anywhere fast (no slow video VNC). Also, if you are already using a terminal, then improving that experience is nice. There is a big enough market there for this company.

However, I'm not sure what a "proper" GUI is. Terminals have a widely used open standard. These protocols are more standard and interoperable than any GUI framework, and they are supported on every system. Once you add video in there, close a few more gaps, I think competing with the browser, or bringing the full computer experience to the terminal is reasonable.

Obviously if terminals add something like video, it's "copying" rendering pipelines from "proper" GUIs, but making the terminal experience better, which could also be viewed as bringing UNIX zen to GUIs, if it makes it big, you'll love it too! <3

Or what if you just prefer to not use a browser to get your information on the internet. Textualize is like the only choice I can jump to.

It’s much better to hyperlink and open image and video in the browser from the terminal. In my opinion. Playing it would just block your terminal session, so it’s pretty annoying to have to open another tab with an inline video playing. I am happy with the features with textualize and haven’t even thought about needing things that play over a duration beyond a few seconds.

Textualize then becomes the browser api that I build my terminal browser and render only the components I care about.

None of that background or js libraries, ads. It’s well worth it.

The use case is something like medical billing entry where people are trained to know all of the billing codes and they still use an AS400 green screen console.

The employees work by keyboard shortcuts and are extremely efficient, and every time someone tries to replace the AS400 with a modern web app, their productivity drops 100x.

It’s the same scenario as a vim/emacs wizard vs a slick looking GUI that doesn’t have keyboard shortcuts.

The solution to manual medical billing is to have computers do the billing. The system can be configured via GUI with rules about billing codes, payers, DX codes, etc. and then the rest of the system Just Does It.

(I work at a company automating medical billing.)

It does seems niche at this point. One scenario I can see is where you want something more user friendly than pure CLI and where providing a web UI might be too risky for some reason. A TUI could allow users to SSH in to server somewhere and just have TUI app as their shell. It's a bit contrived I grant you that.

Personally I found Textual a little weird to use, but better than ncurses. Though it didn't really yield what I wanted. I like the old mainframe style TUI application, those already struck me as being wildly efficient.

> Personally I found Textual a little weird to use, but better than ncurses.

Out of curiosity, have you looked at it's sibling project "rich"?

https://github.com/Textualize/rich

Seems like it provides a TUI toolkit as well, and it looks a bit less weird than the approach Textual uses.

Was thinking of trying it out with a side project recently, but got pulled onto some other stuff instead so haven't yet started. Nor made the choice between them. ;)

Also, charm's bubbletea framework if you use golang.

https://github.com/charmbracelet/bubbletea

Proper GUI's are nice and all, until you need to do the same thing over an ssh connection.

Sometimes that works ok (ie forwarding X on a high bandwidth connection), but other times the proper GUI acts like a complete pig. :(

A text based GUI sounds like it might be the best of both worlds.

greybeard nix admin here: I agree People have forgotten way too many of the lessons we learned in Ops Companies like to slap "agile" and "devops" labels on things, but I see the same old fights... (biased because I hate gui-ninjas)