Hacker News Reader

> browsers have to support tons of backwards compatibility (quirks mode, TLS), terminals have less to support by being more circumspect

I think most terminal emulator developers would dispute this -- there's a lot of complex legacy behavior in TTY/PTY handling, in supporting various escape sequences, being behavior-compatible with dominant emulators like XTerm, etc. Most of it is also "esoteric" in a way that backwards compatibility on the web isn't, since very little is actually standardized (the only pieces I can think of are POSIX for some parts of the PTY layer and X3.64 for some terminal control sequences).

This is pretty fair, though I do think being able to write something like st or even rxvt stands in contrast to... anyone building a different browser? But you're right, we can do better here. A lot of discussions and process in the kitty community have been super enlightening for me, the dev there knows so much.

Agreed with your comments, and in fact your comment here:

> ...It feels like we're on the beginning of the next cycle a little. First we scattered a bunch of apps to see how we should use the internet, then we focused on the browser, now we're scattering some more apps to see which solves our new problems better...

Is something that i also have been thinking about myself. I'm seeing the popularity - maybe resurgence - of text based web browsers as well as the Gemini protocol and associated Gopher sites (Capsules i think they're called?) really rise a bunch lately. I'll add that the prevalence of many devs/techies to implement ad blockers, maybe tweak their browsers to avoid running javascript, etc...to represent some shift towards more minimal interfaces for accomplishing their needs. And, simply blanket re-using of old interfaces (some decades old) without some adjustment might not scale to current-day needs in some cases. I myself look forward to these types of TUI experiments (including taking old text-based interfaces and evolving them for nowadays), as i'm optimistic some will stick around.

I want to see more things like this emerge too.

I think one of the bigger barriers is that terminals don't really have a component reuse boundary.

What I mean by that is: in the browser, you can always put more HTML inside a div tag, and generally speaking, it's gonna stay within the boundaries of that div tag, and things will compose and it won't be a fuss. In the terminal: what's the equivalent of that?

It's possible, and yet not actually remotely pleasant, to make a new PTY/TTY for each component (or each small application that you want to embed within another), and then grab the state of that PTY and replicate it into a rectangular region in another PTY that's bigger. There's so, so, SO much friction in this, though. It also only solves the view bounding: it doesn't solve, for example, the ability to have a copy/paste operation that works on the interior content in a standard way (instead each terminal application solves that itself, usually with some unique bespoke shortcut sequence, because you need _application logic_ to find text ranges since what's rendered to a terminal vs what the logical text state is are usually different).

I think if someone created some very basic component-oriented UI system to solve the composition problem -- then kept most of the components as roughly PTY/TTY and TUI concepts! -- it could lead to interesting places that PTY stuff will have difficulty getting to alone.

I'm actually working on this. Component based over the wire TUI system. It's in a decent alpha state but I want to code and host some more sample sites before I start sharing a ton.

Protocol: https://github.com/rendicott/uggly

Client with gif demo: https://github.com/rendicott/uggly-client

That's quite a rabbit hole to chase...but well worth it I think. Cheers!

Oh man I want this to be true so badly! My career was built on building web apps and I also love the terminal. I think ssh apps have the potential to bridge the gap between the convenience of web apps (no install required) and the terminal.

I just built a new app (https://lists.sh — launching tomorrow) which leverages the charm toolset. It was a ton of fun to build and I think the workflow for publishing blog posts is more convenient than virtually every other blog platform I’ve tried.

This is pretty cool! Looking forward to the launch tomorrow, good luck!

I've been looking for a set of instructions about how to set up an ssh app that doesn't open my computer to pwnage. Do you know of such a set of instructions?

I’d start here: https://github.com/charmbracelet/wish

Thanks!

Possibly something along the lines of a chrooted user for $app that all users log into? Said user would run the application program instead of a shell probably, and actual auth for end users would be more like an http auth style setup instead of "logging in" to the server.

At that point I think you're about as safe as "Generic PHP Web App" - I'm sure I've missed something, but that's where I'd start looking.

> terminals are almost all written in unsafe languages like C

If you're on the hunt for one that isn't, check out wezterm, it's delightfully good.

https://github.com/wez/wezterm

Seconded yeah, thanks for the tip! How had I not heard of this?

Also Alacritty.

Wezterm is indeed good! Thanks for the tip!

one big advantage of browsers is they are accessible to the visually imparted, which currently almost no TUIs are, including this one.

We’re working on improving the accessibility story for TUIs. Since we’re targeting the web we can add screen reader support.

Great, I'm glad to hear it!

I don't mean to insult what you've done, but accessiblity is (in my experience) one of those things which is really hard to add retroactively to systems.

OH! This is a great point (where is 'mwcampbell when you need him haha). Accessibility is a requirement of any future stack, for sure. I guess I assume accessibility is workable for text, but TUIs probably not so much.