5 ms·

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 r

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"...) Am I missing something here?

Kerrick 3y ago
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.
bityard 3y ago
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.
- asicsp 3y ago
  >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.
vidarh 3y ago
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.
- MobiusHorizons 3y ago
  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 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.
  - AnonymouX47 3y ago
    Umm... actually, it's still all text / font glyphs. Basically, it works via a terminal emulator running in the browser, rendering to a canvas.
    - MobiusHorizons 3y ago
      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.
    - deleted 3y ago
      [deleted]
Mister_Snuggles 3y ago
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.
- masfuerte 3y ago
  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.
  - cout 3y ago
    I'm dumbfounded when I type faster than the web browser can keep up and see the characters on the screen in a different order than I typed them.
    - masfuerte 3y ago
      I do an online sudoku which sometimes processes the numbers and arrow keys out of order. I feel like I'm being gaslit.
willm 3y ago
> 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.
- rollcat 3y ago
  > [...] 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. 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/ https://gmi.skyjake.fi/lagrange/), AppManager (https://tildegit.org/solene/AppManager https://tildegit.org/solene/AppManager), Dear ImGUI (https://github.com/ocornut/imgui https://github.com/ocornut/imgui), egui (https://github.com/emilk/egui https://github.com/emilk/egui), and many others.
  - worthless-trash 3y ago
    > In fact there's an entire class of applications that are extremely snappy and keyboard driven, by their very nature: games. The only real difference in consideration is load-time. Gamers seem to be more patient than what I am with app load times.
the_gipsy 3y ago
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.
- zimpenfish 3y ago
  > 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...
__MatrixMan__ 3y ago
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.
- rollcat 3y ago
  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/ 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.
  - __MatrixMan__ 3y ago
    I'll look into these things, thank you.
ploum 3y ago
Agree, I’m also a fan of CLI. That’s why I developed a CLI brower ( https://sr.ht/~lioploum/offpunk/ 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.
- anthk 3y ago
  Offpunk needs an option to open images with sxiv instead of displaying them inline.
  - ploum 3y ago
    That option exists. 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"
nottheengineer 3y ago
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.
ye-olde-sysrq 3y ago
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 https://github.com/mabe02/lanterna - would recommend. They even have a Swing-based emulation mode for easy development iteration running it from intelliJ.
- verdverm 3y ago
  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. experiments in progress here: https://github.com/hofstadter-io/hof/tree/_dev/lib/tui https://github.com/hofstadter-io/hof/tree/_dev/lib/tui
- ReleaseCandidat 3y ago
deleted 3y ago
[deleted]
aatd86 3y ago
A CLI forces you to deal with commands, flags and whatnot. A TUI can be quite good UX instead if done right, I'd surmise.
rewgs 3y ago
> 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.

Kerrick 3y ago

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.

bityard 3y ago

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.

asicsp 3y ago
>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.

vidarh 3y ago

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.

MobiusHorizons 3y ago
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 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.
- AnonymouX47 3y ago
  Umm... actually, it's still all text / font glyphs. Basically, it works via a terminal emulator running in the browser, rendering to a canvas.
  - MobiusHorizons 3y ago
    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.
  - deleted 3y ago
    [deleted]

Mister_Snuggles 3y ago

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.

masfuerte 3y ago
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.
- cout 3y ago
  I'm dumbfounded when I type faster than the web browser can keep up and see the characters on the screen in a different order than I typed them.
  - masfuerte 3y ago
    I do an online sudoku which sometimes processes the numbers and arrow keys out of order. I feel like I'm being gaslit.

willm 3y ago

> 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.

rollcat 3y ago
> [...] 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. 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/ https://gmi.skyjake.fi/lagrange/), AppManager (https://tildegit.org/solene/AppManager https://tildegit.org/solene/AppManager), Dear ImGUI (https://github.com/ocornut/imgui https://github.com/ocornut/imgui), egui (https://github.com/emilk/egui https://github.com/emilk/egui), and many others.
- worthless-trash 3y ago
  > In fact there's an entire class of applications that are extremely snappy and keyboard driven, by their very nature: games. The only real difference in consideration is load-time. Gamers seem to be more patient than what I am with app load times.

the_gipsy 3y ago

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.

zimpenfish 3y ago
> 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...

__MatrixMan__ 3y ago

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.

rollcat 3y ago
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/ 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.
- __MatrixMan__ 3y ago
  I'll look into these things, thank you.

ploum 3y ago

Agree, I’m also a fan of CLI. That’s why I developed a CLI brower ( https://sr.ht/~lioploum/offpunk/ 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.

anthk 3y ago
Offpunk needs an option to open images with sxiv instead of displaying them inline.
- ploum 3y ago
  That option exists. 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"

nottheengineer 3y ago

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.

ye-olde-sysrq 3y ago

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 https://github.com/mabe02/lanterna - would recommend. They even have a Swing-based emulation mode for easy development iteration running it from intelliJ.

verdverm 3y ago
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. experiments in progress here: https://github.com/hofstadter-io/hof/tree/_dev/lib/tui https://github.com/hofstadter-io/hof/tree/_dev/lib/tui
ReleaseCandidat 3y ago

deleted 3y ago

[deleted]

aatd86 3y ago

A CLI forces you to deal with commands, flags and whatnot. A TUI can be quite good UX instead if done right, I'd surmise.

rewgs 3y ago

> 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.