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

61–70 of 113 posts

Re: Textual Web: TUIs for the Web

#61

Post by yoz »

two_handfuls wrote: post #20

> This works without creating a socket server on your machine, so you won't have to configure firewalls and ports to share your applications. Perhaps I’m missing something. Is this not running on your machine? Are we reliant on some hosting service?

It appears that, by default, the textual-web command makes a WebSocket connection to textualize-dev.io and hosts through that. WebSocket is a session-based network protocol that allows for long connections with bidirectional traffic.

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

Re: Textual Web: TUIs for the Web

#62

Post by Scottopherson »

Illniyar wrote: post #34

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

I'm not sure how they're rendering in the browser. But if the TUI is rendered to DOM elements and not canvas/webgl, perhaps it could be useful to use a browser automation tool like Playwright to run test suites against the TUI. If your project involves CLIs and web apps interacting with one another, you could exercise them and assert their behavior within the same test framework.

Re: Textual Web: TUIs for the Web

#63

Post by kotaKat »

Illniyar wrote: post #34

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

A similar thing is in use for mainframe applications to this very day to try to "modernize" them.

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

Re: Textual Web: TUIs for the Web

#64

Post by rollcat »

worthless-trash wrote: post #48
rollcat wrote: post #38

Earlier quoted context omitted.

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

Lagrange cold-starts in roughly a second on my M1 Mac. That's roughly the same as Terminal.app on the same hardware.

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.

Re: Textual Web: TUIs for the Web

#65

Post by eterps »

nine_k wrote: post #59
eterps wrote: post #46

Earlier quoted context omitted.

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

Many TUI programs, e.g. Midnight Commander, can use mouse, but are perfectly operable with just a keyboard. Same with Emacs or Vim in terminal mode. This is more about blending in among GUI tools, which is also important.

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

Re: Textual Web: TUIs for the Web

#66

Post by p_l »

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.

Older versions of AutoCAD (though even the most recent can't escape the REPL) are a good example.

Re: Textual Web: TUIs for the Web

#67

Post by nine_k »

eterps wrote: post #65
nine_k wrote: post #59

Earlier quoted context omitted.

Many TUI programs, e.g. Midnight Commander, can use mouse, but are perfectly operable with just a keyboard. Same with Emacs or Vim in terminal mode. This is more about blending in among GUI tools, which is also important.

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

Right now on my desktop I see 4 TUI windows, and 11 GUI windows.

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.

Re: Textual Web: TUIs for the Web

#68

Post by adamckay »

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.

tmux. I know the keyboard shortcuts (that I customised) to create new windows and panes, and the shortcut to resize them all equally. I've not bothered to learn / remember the keyboard shortcuts to swap pane focus or resize individual panes because I've enabled mouse support and simply click where I want to focus and drag to resize.

Re: Textual Web: TUIs for the Web

#69

Post by ReleaseCandidat »

ye-olde-sysrq wrote: post #40
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.…

> there's something comforting about the constraints of just ASCII/ANSI and curses.

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`

Re: Textual Web: TUIs for the Web

#70

Post by ilaksh »

HelloNurse wrote: post #33
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.

I so want to use this to emulate a Turbo Pascal-like UI for my SaaS. But I think it will confuse my users and also the OpenAI staff probably wouldn't even approve my plugin if it looked like that.
Post reply on HN