5 ms·

I love textualize/rich (and charm)! I think this solves some of the web's browser problems by breaking things out into components: - browsers are way too comp

I love textualize/rich (and charm)! I think this solves some of the web's browser problems by breaking things out into components: - browsers are way too complicated to build, terminals are way easier - browsers have a huge attack surface, terminals are smaller - browsers lock you into JavaScript (more or less), terminals don't - browsers have to support tons of backwards compatibility (quirks mode, TLS), terminals have less to support by being more circumspect 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. To that end, presuming we stick with terminals, I wonder if they're at risk of falling prey to the same problems, or if they have different potholes in their future. One thing in particular I saw someone else mention in a comment in a different thread is that terminals are almost all written in unsafe languages like C, which feels super bad. Something else is auth and identity--something the current web is pretty bad at.

mxuribe 5y ago
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.
- heavenlyhash 5y ago
  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.
  - russellendicott 5y ago
    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 https://github.com/rendicott/uggly Client with gif demo: https://github.com/rendicott/uggly-client https://github.com/rendicott/uggly-client
  - deleted 5y ago
    [deleted]
  - mxuribe 5y ago
    That's quite a rabbit hole to chase...but well worth it I think. Cheers!
tux1968 5y ago
> 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 https://github.com/wez/wezterm
- pkulak 5y ago
  Also Alacritty.
- pmarreck 5y ago
  Wezterm is indeed good! Thanks for the tip!
- camgunz 5y ago
  Seconded yeah, thanks for the tip! How had I not heard of this?
woodruffw 5y ago
> 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).
- camgunz 5y ago
  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.
CJefferson 5y ago
one big advantage of browsers is they are accessible to the visually imparted, which currently almost no TUIs are, including this one.
- camgunz 5y ago
  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.
- willm 5y ago
  We’re working on improving the accessibility story for TUIs. Since we’re targeting the web we can add screen reader support.
  - CJefferson 5y ago
    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.
qudat 5y ago
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 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.
- gnat 5y ago
  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?
  - Shared404 5y ago
    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.
  - qudat 5y ago
    I’d start here: https://github.com/charmbracelet/wish https://github.com/charmbracelet/wish
    - gnat 5y ago
      Thanks!
- jesushax 5y ago
  This is pretty cool! Looking forward to the launch tomorrow, good luck!

mxuribe 5y ago

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.

heavenlyhash 5y ago
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.
- russellendicott 5y ago
  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 https://github.com/rendicott/uggly Client with gif demo: https://github.com/rendicott/uggly-client https://github.com/rendicott/uggly-client
- deleted 5y ago
  [deleted]
- mxuribe 5y ago
  That's quite a rabbit hole to chase...but well worth it I think. Cheers!

tux1968 5y ago

> 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 https://github.com/wez/wezterm

pkulak 5y ago
Also Alacritty.
pmarreck 5y ago
Wezterm is indeed good! Thanks for the tip!
camgunz 5y ago
Seconded yeah, thanks for the tip! How had I not heard of this?

woodruffw 5y ago

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

camgunz 5y ago
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.

CJefferson 5y ago

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

camgunz 5y ago
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.
willm 5y ago
We’re working on improving the accessibility story for TUIs. Since we’re targeting the web we can add screen reader support.
- CJefferson 5y ago
  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.

qudat 5y ago

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

gnat 5y ago
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?
- Shared404 5y ago
  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.
- qudat 5y ago
  I’d start here: https://github.com/charmbracelet/wish https://github.com/charmbracelet/wish
  - gnat 5y ago
    Thanks!
jesushax 5y ago
This is pretty cool! Looking forward to the launch tomorrow, good luck!