Comment by rollcat | Hacker News Reader

Comment by rollcat | Hacker News Reader

Parent Full thread

> GUIs UI conventions never became that powerful, and new GUIs don't even follow most of the useful UI conventions. That's so generalized a problem that the newest GUI toolkits don't even have native support for a lot of the GUI conventions.

Yes, that's unfortunately the status quo. TUI's main saving graces, and the reason why it's actually a popular choice for modern apps, are:

- It works everywhere (once you solve the portability quirks, which are present both at OS level and on each different terminal emulator)

- The API is simple and stupid (paint a character here)

- There's only this many things you can do, so you don't over-engineer your UI

- Accessibility. Screen readers are guaranteed to work (but lack a11y context)

I wish there was a simple and stupid, portable GUI framework that had all of these qualities, without the unnecessary historical baggage. htop or ranger are actually pretty good apps, just wish they weren't chained to an emulator.

> I wish there was a simple and stupid, portable GUI framework that had all of these qualities, without the unnecessary historical baggage.

The baggage may be unnecessary, but I think the key to the success of TUIs is that the terminal’s interaction mechanism is restrictive. To accomplish this in a similar way in the GUI, I think you need to design a toolkit that intentionally constrains the rendering target and input mechanisms that the GUIs can take advantage of. You might end up with something better, but I think it will be very reminiscent of current terminal emulators.

I think my ideal terminal emulator would be HTML based. Programs would output HTML, with some special extra tags. If you want a UI, serve a web interface on a random port and embed it in an iframe.

You could make app launchers with links that run other apps, and even non terminal people would want to use it.

I think that’s more or less what this project is working towards:

https://hyper.is

> To accomplish this in a similar way in the GUI, I think you need to design a toolkit that intentionally constrains the rendering target and input mechanisms that the GUIs can take advantage of.

I like to think that software developers are very smart people, and only need a little nudge to steer in the right direction. If all you have is PutRune(x,y,r) and intentionally omit PutPixel(x,y,p), you'll indeed just make a worse terminal emulator.

Any decent UI toolkit focuses on a high-level description of the user interface (that's how you get a11y, basic keyboard navigation, etc almost for free), and only provides the low-level operations as escape hatches. This has to be the default route, even for complex or highly customized interfaces (spreadsheet, DAW, etc).

I think our nudge could be direct support for terminals as a fallback rendering backend. Best of both worlds: you get a well-behaved GUI app, that you can also use over a serial console (with gradual loss of functionality) if things get dire.

> Accessibility. Screen readers are guaranteed to work

I wonder how useful screen readers are in curses-style applications (I don't have any experience with screen readers)? Sure, it can probably read it, but applications like this is essentially just a screenful soup of character blocks. It sounds like it'd make for a very tedious screen reading experience.

Correct. There's no additional context for the reader. There's blind people who are pretty good at Nethack. Once you're stuck with a character soup you might as well fully embrace it.

All those points equally apply to web apps and that’s exactly why web apps are becoming the default starting point for any new product.

Reply on news.ycombinator.com