Textual Web: TUIs for the Web
textual.textualize.io
textual.textualize.io
Personally I would cut complex animations (i.e. sub-character) and only have a single size monospace font. I would rip out CSS and go for maximum compatibility. (If something exists like that, please let me know!)
Another feature that could be cool is to have this served (optionally) via telnet. I would also make it be able to produce static content (with a subset of features).
I guess it's kinda like running over ssh? Or do you mean you hit an open unprotected port (telnet) and then the app takes care of setting up the SSL connection so you don't have to worry about SSH details?
You might enjoy various https://charm.sh/ apps, especially https://github.com/charmbracelet/wish. They seem to prefer SSH to telnet though.
When a 'TUI' begins to incorporate features like mouse-clickable buttons, drop-down menus, scrollbars, windowed interfaces (as opposed to panes & separate screens), it gradually shifts away from its core identity. Eventually, it becomes a GUI operating within the limitations of a terminal.
Imagine something like lazygit with text-drawn buttons, drop downs and other TUI anti-patterns. Or even more extreme, without its keybindings and modality. It would miss the point entirely.
I've already experimented with dropdown menus and minimizing sections. While I too love the TUI and keyboard driven experience, many want something they can click on, less overhead from every application having their own hotkeys. For me, it's about reaching more people, and the hope that I can bring more of them into the mouseless development experience
To me, these reasons underscore the need for a genuine GUI, rather than a TUI that requires users to open a terminal just to have something clickable.
This is more about blending in among GUI tools, which is also important.
This is what I find difficult to understand, why is that important? And to whom?
It made sense 35 years ago when MS-DOS was shipped by default and you just had to make do.
A full-featured web browser or a video chat client can't be realistically made TUI. I could have run Emacs in TUI mode, but I appreciate variable font support in non-code texts I write.
New users tend to get really involved with the buttons, but gradually shift to full text control over years.
Obviously in CAD sometimes you cannot enter coordinates and must grab the mouse... but it's still faster if you minimize use of the mouse.
Tools like Plasticity CAD¹ or Blender feel way more keyboard-friendly in this space.
Also lazygit and neovim (since you mentioned modals) are GUIs in the terminal. The entire reason for lazygit to exist is to have a user-friendly experience for people who don't want to use the more complex and spartian git cli.
I am not sure why you think my comment is in disagreement of that.
> The entire reason for lazygit to exist is to have a user-friendly experience for people who don't want to use the more complex and spartian git cli.
Same, I fully agree with that statement.
I agree there are also many GUIs tailored for professionals. Not sure if there are TUIs tailored for general consumers though.
Also there are some areas that's universally acknowledged to be better suited for GUI, anything that requires visualization like video editing, image editing, 3d modeling, etc. Maybe someone can go full ffmpeg to edit a feature length film, but that'll take some effort.
Only if the TUI is non-scriptable. That's the big bait-and-switch possible here: Is it a TUI in that the menu system is made out of text, or is it a TUI in that it's a command line with a scripting language and the ability to create new commands out of composable pieces? Just saying "Textual User Interface" doesn't disambiguate the two.
it was amazing watching them work, and there was no mouse involved. there wasn't even a mouse connected to the terminal. F-keys and hotkeys galore, and the applications were extremely responsive, none of this 400ms response from a webserver then another 1200ms waiting for the JS to render the page.
I am in favor of TUIs if they can bring this kind of accommodation for power-users. I agree with you that there is a strong danger of UX people getting involved and making things perfect for new people at the expense of anyone advanced.
As a user I don’t like what the web has become. People build UIs as if the medium is the message, but I can assure you the content is more important to me than the form. Plain text sports is popular for a reason!
Textual: Rapid Application Development framework for Python - https://news.ycombinator.com/item?id=37174657 - Aug 2023 (99 comments)
Textual Paint – MS Paint in your terminal - https://news.ycombinator.com/item?id=36859880 - July 2023 (34 comments)
Textual is a beautiful Terminal User Interface library in Python - https://news.ycombinator.com/item?id=35123383 - March 2023 (80 comments)
Textual TUI framework for Python adds CSS renderer - https://news.ycombinator.com/item?id=33306881 - Oct 2022 (85 comments)
Things I've learned building a modern TUI framework - https://news.ycombinator.com/item?id=32331367 - Aug 2022 (230 comments)
Textualize – A framework for building Text User Interface applications - https://news.ycombinator.com/item?id=31143327 - April 2022 (99 comments)
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?
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.
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.
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.
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.)
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.
1. <https://commons.wikimedia.org/wiki/File:Apple_Modifier_Keys....>
2. <https://commons.wikimedia.org/wiki/File:Apple_Keyboard_(A104...>
3. <https://commons.wikimedia.org/wiki/File:Apple_iMac_Keyboard_...>
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.
1. Wrong.
2. It doesn't even matter whether they have one or not—it's irrelevant.
3. You're strawmanning me so hard. Please knock it off. It's annoying.
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.
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.
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.
Some people have taken to writing GUI apps like you'd write a game, and the effects range from OK to fantastic. Check out Lagrange (https://gmi.skyjake.fi/lagrange/), AppManager (https://tildegit.org/solene/AppManager), Dear ImGUI (https://github.com/ocornut/imgui), egui (https://github.com/emilk/egui), and many others.
The only real difference in consideration is load-time. Gamers seem to be more patient than what I am with app load times.
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.
[1]: https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times...
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.
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.
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...
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.
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.
When displaying an image, simply type "open" to open with an external program.
By default, it uses xdg-open but you can configure it in offpunk with:
> handler image/* sxiv %s
note that "open" works also with pages and will open the cached html pages in your browser. If you want to open the original page use "open url"
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.
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.
experiments in progress here: https://github.com/hofstadter-io/hof/tree/_dev/lib/tui
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`
A TUI can be quite good UX instead if done right, I'd surmise.
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.
The command box, and being able to reach any function with 4 chars, was the best part imho. I grant it's not a true TUI, as they do pixel level rendering, but the keyboard driven experience and aesthetic certainly makes it a contender
Personally I don't like the react way of doing things, but seeing as there aren't really any good TUI libraries I suppose I'll make do.
I wrote a short example [1] that exposes a TUI game on the web. In theory, hot-seat terminal games should be playable over the web with this.
My current challenge has been around refreshing the screen for late joiners. I need to save some of the ANSI escape history and replay it to clients, or ask the application to redraw itself. If anyone has ideas on how to approach this i'm all ears.
How long would it take me to learn and get proficient with something like this? I would use it for email, JIRA tickets, reading github code, using the github/gitlab UI (as a TUI).
Maybe even some google sheets.
As I type this I now realize most of this is probably not possible :(
I suspect it has the same problem as ncurses: Not easy to learn, get proficient with, or rapidly produce something decent with.
I've been working on a project for a while that allows running any console program within it, and use text, keyboard, or mouse triggers to add a VT100 TUI, but it's uncomfortable to learn, very hard to get proficient with, and while it's possible to rapidly produce something decent, you're going to hit a hard wall producing something excellent.
Things I've noticed are the debugging and logging experience are pretty good. You could have multiple processes dumping to different log files and grepping those.
There's a lot of formatting you can do with Python and the sister library Rich.
Have spent about 12 hours on it and it's much easier to get a UI running than say learning a flavor of the month JavaScript framework.
0: https://developer.atlassian.com/server/jira/platform/jira-re...
Now command line interfaces... Those are pretty kick ass. I would love to see more command line interfaces on the web.
Perhaps I’m missing something. Is this not running on your machine? Are we reliant on some hosting service?
In this case, the computer running textual-web initiates the connection, so there’s no need to listen for new incoming connections. But in all other respects, it’s acting like a server. The code is still running on your machine with all the permissions it had when you started it, so... be careful.
Take a look at the repo, because the implementation’s fairly small and the README has more info: https://github.com/Textualize/textual-web
Basically fancy screen-scrapers that turn everything into forms and menus and fields, they do have their use. (In the industrial case, it's for things like text entry and mainframe applications to be made more "touchscreen friendly" for modern industrial devices and modernize them to the modern metal you have to use.)