Textual Web: TUIs for the Web • Hacker News Board

Re: Textual Web: TUIs for the Web

#31

Post by rollcat » Thu, Sep 07, 2023, 3:34 PM UTC

__MatrixMan__ wrote: post #16

rollcat wrote: post #2

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 pr…

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"…

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.

Re: Textual Web: TUIs for the Web

#32

Post by verdverm » Thu, Sep 07, 2023, 3:35 PM UTC

Barrin92 wrote: post #28

eterps wrote: post #15

I prefer TUIs over GUIs primarily because TUIs are often tailored for advanced users — essentially, for professionals. In contrast, the majority of GUIs prioritize user-friendly experiences for the general consumer. 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…

I"m a professional software developer and I like user-friendly experiences. I didn't know drop down menus and clickable buttons (thought that was the point of a button) are somehow anathema to advanced users

I typically use `-` on HN to click the button, advanced users will find a way... enter Vimium stage left

Re: Textual Web: TUIs for the Web

#33

Post by HelloNurse » Thu, Sep 07, 2023, 3:36 PM UTC

maronato wrote: post #8

TUIs feel like the epitome of “they were so preoccupied with whether or not they could, they didn't stop to think if they should.”

Too young to remember MS-DOS TUI masterpieces like Norton Commander or Borland Turbo Pascal? For a large segment of serious software that didn't need fancy graphics there was no justification for the reduced performance, dubious hardware compatibility and more complex programming of a proper GUI.

Re: Textual Web: TUIs for the Web

#34

Post by Illniyar » Thu, Sep 07, 2023, 3:36 PM UTC

I don't understand the value proposition. In what situations would I want to make my TUI available as a web app?

Re: Textual Web: TUIs for the Web

#35

Post by tomaszsobota » Thu, Sep 07, 2023, 3:37 PM UTC

I'm happy to see this stage come to fruition! What I really can't wait for is to be able to build static websites with this, but to me, that's a really good first step towards that.

Re: Textual Web: TUIs for the Web

#36

Post by verdverm » Thu, Sep 07, 2023, 3:38 PM UTC

Difwif wrote: post #11

When is the Emacs clone coming?

lol, I've been working on a TUI of late around CUE and feel myself slipping towards IDE territory. Not helping is that the underlying tcell library has functions specifically for supporting vim & emacs modes

Re: Textual Web: TUIs for the Web

#37

Post by nottheengineer » Thu, Sep 07, 2023, 3:39 PM UTC

rollcat wrote: post #2

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 pr…

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.

Re: Textual Web: TUIs for the Web

#38

Post by rollcat » Thu, Sep 07, 2023, 3:40 PM UTC

willm wrote: post #10

rollcat wrote: post #2

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 pr…

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

> [...] 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/), AppManager (https://tildegit.org/solene/AppManager), Dear ImGUI (https://github.com/ocornut/imgui), egui (https://github.com/emilk/egui), and many others.

Re: Textual Web: TUIs for the Web

#39

Post by zimpenfish » Thu, Sep 07, 2023, 3:40 PM UTC

the_gipsy wrote: post #12

rollcat wrote: post #2

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 pr…

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, co…

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

Re: Textual Web: TUIs for the Web

#40

Post by ye-olde-sysrq » Thu, Sep 07, 2023, 3:42 PM UTC

rollcat wrote: post #2

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 pr…

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.