Live data from Hacker News

Textual Web: TUIs for the Web

textual.textualize.io

41–50 of 113 posts

Re: Textual Web: TUIs for the Web

#41
Neat. I’d like more alternatives to the current paradigm of design. For example I’m currently building a UI with gradio and I’m enjoying it vs html/JS. The level of complexity to build a usable app is about as low as I can imagine until we get to a wisywig.

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!

Re: Textual Web: TUIs for the Web

#42
I think the best "TUI" I used was the Bloomberg Terminal.

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

Re: Textual Web: TUIs for the Web

#43
post #24
post #21

Earlier quoted context omitted.

Visual Studio (not Code), JetBrains, Photoshop, AutoCAD, Blender, every single tool for circuit simulation and FPGA programming would like a word with you. 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.

> Visual Studio (not Code), JetBrains, Photoshop, AutoCAD, Blender, every single tool for circuit simulation and FPGA programming would like a word with you. 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.

From reading both of your comments it looks like you are saying that people who use [Visual Studio (not Code), JetBrains, Photoshop, AutoCAD, Blender, every single tool for circuit simulation and FPGA programming] fall into the category "general consumer" but people who use vim fall into the category "professional". That's not how I would distinguish professionals from general consumers.

Re: Textual Web: TUIs for the Web

#44
post #19
post #17

Earlier quoted context omitted.

I don't think the two use cases are mutually exclusive. You can have that keyboard driven muscle-memory workflow, while keeping things discoverable for users who haven't committed everything to memory.

Do you have examples where this is the case? In my experience, they've always seemed mutually exclusive.

zellij

Re: Textual Web: TUIs for the Web

#45
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.…

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

Re: Textual Web: TUIs for the Web

#46
post #19

Earlier quoted context omitted.

Do you have examples where this is the case? In my experience, they've always seemed mutually exclusive.

the TUI library for tcell has mouse support, though you see it more in tview (or one of the dozens of maintained forks) 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…

> many want something they can click on [...] it's about reaching more people

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.

Re: Textual Web: TUIs for the Web

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

In theory GUI is a superset of TUI, there's nothing inherently bad or unproductive about GUI. You can argue in practice there exist a lot of unproductive GUI that's worse than a TUI client, but I think it's the problem of the designer, not the tool.

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.

Re: Textual Web: TUIs for the Web

#48
post #38
post #10

Earlier quoted context omitted.

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

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

Re: Textual Web: TUIs for the Web

#49
post #46

Earlier quoted context omitted.

the TUI library for tcell has mouse support, though you see it more in tview (or one of the dozens of maintained forks) 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…

> many want something they can click on [...] it's about reaching more people 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.

yeah, I've consigned myself to needing a GUI, but for the time being, iteration with a TUI is much faster. Our focus is also CUE, where working from the Go API unlocks way more possibilities. We get to keep the extra complexity of representing CUE constructs as JSON for sending on the wire. Though that GUI might be native and avoid all the web stuff anyway.

Re: Textual Web: TUIs for the Web

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

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

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.
Post reply on HN