TUI is just a thinly disguised GUI. I mean it's pretty cool what they've done, but if it's effectively just an alternative graphical frontend (that happens to run in a terminal emulator), well I guess someone out there has a use case where they need to run this over an SSH session?
Personally I find CLI (not TUI) and/or client libraries a much more attractive proposition; otherwise a native application, that uses proper system widgets and integrates with the rest of your desktop environment (an icon in the dock, system notifications, matching light/dark theme, etc), seems superior to a TUI in all aspects? (Except for "I need to run this over SSH / serial console"...)
I wrote a TUI before for work, entirely of my own volition and for my own near-exclusive consumption (it was theoretically for anyone, but I'm the only person who would've had a reason to look at it - we were a fairly silo'd dev shop).
This is what made me pick TUI over a web UI:
* no web stack, period. no client/server. no js or html. this simplified the problem dramatically. also, no additional services to babysit.
* no browser - no certificates, security, auth, etc. It's just unix permissions and ssh.
* there's something comforting about the constraints of just ASCII/ANSI and curses. No bikeshedding over border widths or radii when it's just you picking among a few characters for the shape. just having less decisions to make speeds things up and helps you focus on what you actually want the UI to be able to do.
Obviously if your app is just calling APIs anyway, that might be negate some of these bullets about no additional services to babysit etc. In this case, it was running an internal infra app that directly connected to a pg db.
And what made me pick it over just having a CLI:
* discoverability - it was a complicated app and while it was all technically exposed via cli flags, having a GUI made it a lot easier to figure out what the right incantation is.
* richer communication medium that's back-and-forth instead of unidirectional. The TUI is able to fetch a list of e.g. valid IDs and let you pick them with a check-list, instead of you having to go query the db yourself and type them in.
I consider it one of my greatest victories that my boss was able to use the TUI to recover from an incident without needing to page me while I was on holiday, and he said he barely had to read the docs and felt confident he was getting it right the first time. "I did it while sipping my coffee."
I used https://github.com/mabe02/lanterna - would recommend. They even have a Swing-based emulation mode for easy development iteration running it from intelliJ.
> there's something comforting about the constraints of just ASCII/ANSI and curses.
If you are using raw Ncurses from C or C++ you know where the name came from.
My favourite feature are the macros ncurses.h defines, like `OK` and `timeout`
100% one of the best things about building a TUI is not having the pain of modern web development. I do think there is a way to have a CLI & TUI come from the same code, so you can get the best of both, or pick the best for the task at hand.
TUIs being constrained to just text means that they are most likely 100% usable with a keyboard.
Text editors are a great example: I tried using VSCode with the vim extension, but every once in a (short) while some GUI panel "steals" the focus and I had to click somewhere to get back to where I was.
Apart from vim, I also use some chat TUI, and tig for browsing git, for the same reason.
It's like back in the days, common users of software could get really good and fly through with keyboard shortcuts. Nowadays I'm saddened when I have to watch a cashier CLICK through some shitty GUI at snail's speed.
> TUIs being constrained to just text means that they are most likely 100% usable with a keyboard.
Anecdata: a long time ago, I worked for people trying to sell a (physical) ad-system to Titan and they made a whizzy web UI for booking adverts on their system. Problem was that Titan already had a TTY booking system and their ad bookers could whip through multiple bookings on that using the keyboard in less time than the whizzy web UI took to even load the first page...
One thing that most TUIs have but most GUIs (web or native app) don't is fast keyboard navigation. There are obviously exceptions to both cases, but as a general rule this seems to hold true.
Watching people who are very familiar with the TUI that they're using do complex business transactions is a sight to behold. In particular, a seasoned user will likely type a series of commands that will get buffered until the TUI catches up with them - I've never seen a GUI that could do this.
Type-ahead works fine with single-threaded GUIs. It was rock solid in Windows 3.1. It worked in nearly all win32 apps because hardly anyone used threads other than for background tasks. But it's broken in most modern UI toolkits and on the web.
I'm probably a bit more positive to TUI type applications than you (and don't care about theme matching, docks, or notifications), given e.g. my editor runs purely in a terminal (and I'm writing a new terminal...) but I think we sort-of agree when you say it's just a thinly disguised GUI.
While I think it's impressive how good they've made it look, for me the point of a TUI is for it to be simple and pared down. It's nice if it looks good, but I want something keyboard driven and command focused rather than UI element focused. I'm not sure who the target group is here. Are there enough people who love to work in a terminal but still want their apps to look like GUI apps?
EDIT: From elsewhere on the site, it seems like they're trying to target people who would like to write GUIs, but find writing GUIs too hard, and that the TUI part is just a starting point. I'm ambivalent of the chances for that to succeed, but who knows.
I think you are spot on classifying the project as “for people who want to write GUI”, based on the GitHub read me (which has screenshots) it does not appear to be a tui on the web at all
https://github.com/Textualize/textual-web
It looks like on the web it is rendering widgets that the library can also render via tui on the terminal. So it seems the title is quite misleading. The web based ones are not using font glyphs to build up a ui.
ack, I was fooled by the screenshots. That is even less advisable than I had feared. the widgets would likely have very poor accessibility if they are implemented as text on canvas.
> I want something keyboard driven and command focused rather than UI element focused.
I think we are in more agreement than you might suspect. Command-driven operation is how I tell a good UI from a poor UI. Good interfaces are intuitive for beginners and provide a smooth learning curve to mastery. Good way to get there is for the interface to remain simple and consistent on the surface, but unravel more specialized power as you dig in, and ultimately allow full customization.
It's all the things that make macOS UI so good IMHO: apps look and work similarly at the surface, have consistent keyboard shortcuts, you get excellent feature discoverability through the top bar menu + search box, and you can even rebind any menu item to a custom shortcut (both per-app and system-wide) through the stock Settings app. Pitch that against your typical selection of TUI apps: vi, less, top, screen, tmux, irssi, mutt, etc all do things differently, the *only* thing they have in common is a grid of character cells.
Terminal emulators themselves unfortunately seem to be the anti-thesis of good UI. The ecosystem is highly fragmented. Writing a TUI app from scratch (yes I wrote my own TUI text editor) is hell, if you want to aim at more than the lowest common denominator, while ensuring portability (I'm talking just Linux+BSD+Mac; I wouldn't even know where to start with Windows). Even if you chose not to waste your life and started with Termbox or heck even ncurses, you'll still be fighting a dragon at the end of every dungeon level: keybindings (why can't I do ctrl+shift+a!?), colors (crap it ended up being black on black!), etc.
> From elsewhere on the site, it seems like they're trying to target people who would like to write GUIs, but find writing GUIs too hard, and that the TUI part is just a starting point.
I haven't looked at the framework yet (TL;DR...), but that seems like a goal that I could get behind. Writing a good GUI app nowadays means you have to learn and use platform-specific APIs, and cross-compiling is a massive pain.
Beeware (https://beeware.org/) is working on something pretty good in that direction. I encourage everyone to have a good look at it.
Mac OS doesn't have access keys for the menu bar. Either someone assigns a keyboard shortcut, which you can use, or you have to use the key combo that focuses the menu bar and then arrow through the menus. The first time I got a Mac, I thought this was insane. When I sold my MacBook years later, I still thought it was insane, because it is.
In contrast, the IBM Common User Access guidelines established that you can press Alt plus another key indicated by an underlined letter associated with a given menu option in order to open/select that option, with subsequent letter keypresses opening other menus further still or selecting menu items. Windows still supports this and both Gnome and KDE(?) apps that still use traditional menu bars do, too. (Gtk used to even let you assign which letters opened which menus/items directly from the main application UI—no opening up any control panel—but they got rid of it around Gnome 3, as I understand it.)
> Mac OS doesn't have access keys for the menu bar. Either someone assigns a keyboard shortcut, which you can use, or you have to use the key combo that focuses the menu bar and then arrow through the menus.
Try Cmd+Shift+/ (aka Cmd+?) and typing a few letters of the command you want to invoke. It's pretty much the same mechanism that Emacs uses (C-x followed by the command name).
I'll admit it's not very discoverable.
> In contrast, the IBM Common User Access guidelines established that you can press Alt plus another key indicated by an underlined letter associated with a given menu option in order to open/select that option
First, Macs don't have an "Alt" key ;) But more importantly, CUA dates back to 1987, which is predated by the original 1984 Macintosh - which by that time already had established quite a few conventions of its own. I wouldn't blame it on Apple that they've stuck with their own conventions, their OS is arguably the most consistent one on the market thanks to that. Some people (hi) greatly value that consistency.
I think it could be argued either way about which convention is better, I'd say it boils down to preference.
O[1] RLY?[2][3] (Whether they have one or not is beside the point.)
> more importantly, CUA dates back to 1987, which is predated by the original 1984 Macintosh - which by that time already had established quite a few conventions of its own. I wouldn't blame it on Apple that they've stuck with their own conventions
Irrelevant. The Mac OS isn't the same as the one that shipped in 1984. It certainly didn't have Spotlight then, for example. Supporting CUA-style menu access keys would be an additive change—the same way that importing the benefits of the UNIX userspace by way of NeXTStep was additive (but far less invasive than that one); no one said to stop supporting other menu access methods.
> Supporting CUA-style menu access keys would be an additive change [...].
As I said, Macs don't have an Alt key; there's an Opt key, which (depending on context) can work like AltGr or Alt (the latter usually when combined with Cmd). You can't draw a 1:1 comparison with a PC keyboard, because they're just different things.
Overloading Opt to access menus is not an additive change. Opt-e in my keyboard layout produces "ę"; Opt-x produces "ź". You'd take away my ability to type in my native language.
Introducing new modifier keys (say OptGr+e would produce "ę" but Opt-e would access the menu) would be a drastic and unwelcome change. I would equate it with changing the meaning of "Shift" when pressing number keys. It's something you just don't do to your users, no matter how much more sensible it appears to you.
Again, it's all platform conventions. When you travel to Italy, you don't bitch that nobody speaks German - even if German is standardized, and officially spoken in three different countries.
> an icon in the dock, system notifications, matching light/dark theme, etc
Textual apps will eventually support this and other OS integrations exposed by the browser. It's never going to look native, given the terminal origins. But it will be possible for them to play better with the OS. And when we add PWA support, they will have a more desktop look and feel.
SSH is an advantage when running in the terminal. In the browser the advantage is that you can deploy them where you couldn't run a web server. Think IOT, routers, lab equipment. Or just cloud servers, where you want a backend to work with the local file system.
Another advantage is development speed. Textual has a learning curve which is far less steep that a regular web stack. It allows non-web developers to build bespoke apps.
I also think that TUIs can be more attractive than GUIs in some scenarios. Not because they look better, but you can build UIs that are snappy and keyboard driven. TUIs are a more natural fit for that kind of interface.
> [...] you can build UIs that are snappy and keyboard driven.
That's not an advantage that is exclusive to TUIs; after all, you're running your TUI inside a graphical application that emulates a terminal. (Unless you're rocking an actual VT102, in which case I bow down to you.)
In fact there's an entire class of applications that are extremely snappy and keyboard driven, by their very nature: games.
Load time tolerance is proportional to session length and focus required. People put up with GTA V Online taking tens of minutes to load the "micro"transaction store contents [1] because when they sit down to play online they are going to spend a couple hours in near 100% focus.
Compare with a mobile game, even a 3D one, where sessions are usually in the tens of minutes themselves, a lot more effort is spent optimising load times and it can be a competitive advantage.
Lagrange cold-starts in roughly a second on my M1 Mac. That's roughly the same as Terminal.app on the same hardware.
Games tend to take a lot of time to start up because they need to preload heavyweight data, such as textures, models, maps, sounds, video. You don't need any of that in a desktop application.
TUIs are a really great way to mix GUIs into CLI "suites." For example, one may usually use homebrew through a CLI, but one can imagine that certain workflows with homebrew might be better served through a TUI than a CLI. Perhaps browsing and filtering the list of packages -- though the specific workflow isn't important for this example. In that case, homebrew can ship a CLI that handes most or all workflows, plus one or more TUI workflows to enhance some subset of those workflows. Because you're already interacting with it in a terminal, it's a pretty smooth transition to give you the rich TUI experience when appropriate. The same could not be said of a native application.
The only thing I think you're missing is that a browser is kind of a clunky dependency. It really wants you to use it for a certain kind of thing and although they can be tricked into doing other things, you and your users are always going to feel a bit of pressure to conform to the norms of the modern web.
So if you're trying to avoid the mess that is the web these days, a TUI is really your whole "everything else" for things that don't CLI well. So it's nice to be able to put it in a browser later on without having had to build it there in the first place.
There is an easy way to write GUI apps that both look good and do not boil down to the lowest common denominator of 80s state-of-the-art: use something like SDL/GLFW, with an immediate mode UI toolkit on top.
Lagrange (https://gmi.skyjake.fi/lagrange/) is a beautiful app that (despite my ideological purism in favoring more "native" solutions) I find perfectly usable and pleasant to use.
That’s why I developed a CLI brower ( https://sr.ht/~lioploum/offpunk/ ). When reading the title, I clicked hoping to see some alternatives or innovative solution to browse the web from a terminal.
Turns out it’s the opposite : putting a terminal in a web browser.
The point of textual is, from what I can tell, making simple and fast UIs very easy to develop. Running in a terminal also makes keyboard input easy, so why reinvent that wheel?
Being able to turn that into a website with little extra work is nice and I think the web absolutely needs a bit more simplicity.
> I guess someone out there has a use case where they need to run this over an SSH session?
Raises hand.
I write a lot of internal tools for musicians (primarily film composers), many of which are primarily local but will be web-based once I put together the rest of the pieces of the pipeline. Being able to run the same interface as a local desktop app, or as a web app, or over an SSH connection, is a huge selling point to me.
Plus, I just honestly love the look. It's clean and simple with high information density. Totally my cup of tea.
IMO Textual/Rich is one of the coolest projects to come out in recent years.
IMO, you're not missing much if anything. It's definitely a cool project and I've spent some time tinkering with it, but feels a lot more like an art project trying to evoke a certain aesthetic rather than something that actually makes writing terminal-based programs easier.
>rather than something that actually makes writing terminal-based programs easier
Are there alternate options you'd recommend? I've used Textual to create a few interactive apps and found it a pleasing experience. In my case, I didn't need it to be a TUI, but it was much easier to reason about compared to tkinter.
.jpg){kind=link}
Personally I find CLI (not TUI) and/or client libraries a much more attractive proposition; otherwise a native application, that uses proper system widgets and integrates with the rest of your desktop environment (an icon in the dock, system notifications, matching light/dark theme, etc), seems superior to a TUI in all aspects? (Except for "I need to run this over SSH / serial console"...)
Am I missing something here?