Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Textual Web: TUIs for the Web

textual.textualize.io

Post reply on HN
Print view View original

21–30 of 113 posts

Re: Textual Web: TUIs for the Web

#21

Post by Spivak »

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…

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.

Re: Textual Web: TUIs for the Web

#22

Post by rollcat »

vidarh wrote: post #6
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'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…

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

Re: Textual Web: TUIs for the Web

#23

Post by AnonymouX47 »

MobiusHorizons wrote: post #14
vidarh wrote: post #6

Earlier quoted context omitted.

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…

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

Umm... actually, it's still all text / font glyphs. Basically, it works via a terminal emulator running in the browser, rendering to a canvas.

Re: Textual Web: TUIs for the Web

#24

Post by eterps »

Spivak wrote: post #21
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…

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.

Re: Textual Web: TUIs for the Web

#25

Post by somat »

The tui only really makes sense in the context of the tty terminal. I like the tui for one reason, it makes running the interface remotely via ssh effortless. Other than that they sort of suck.

Now command line interfaces... Those are pretty kick ass. I would love to see more command line interfaces on the web.

Re: Textual Web: TUIs for the Web

#26

Post by gorjusborg »

Spivak wrote: post #21
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…

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.

Technically neovim is a GUI, but not in the sense most people would accept.

Re: Textual Web: TUIs for the Web

#27

Post by Halfwhit »

eterps wrote: post #19
willm wrote: 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.

Emacs?

Re: Textual Web: TUIs for the Web

#28

Post by Barrin92 »

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

Re: Textual Web: TUIs for the Web

#29

Post by guestbest »

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 think what you’re focusing on GUI’s that don’t target power users anymore while TUI’s that do.

Re: Textual Web: TUIs for the Web

#30

Post by verdverm »

eterps wrote: post #19
willm wrote: 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.

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 more of them into the mouseless development experience

Post reply on HN