6 ms·

> To get a good terminal UX, ... At that point you're just inventing a new DOM variant and aren't fundamentally different from any other opinionated GUI framew

> To get a good terminal UX, ... At that point you're just inventing a new DOM variant and aren't fundamentally different from any other opinionated GUI framework. The value of the terminal for me is the minimalism. I absolutely despise all these new "features" that get added via protocols. I _want_ the boring grid composed entirely of extremely primitive character cells where WYSIWYG in terms of any underlying abstraction. The only innovation I welcome in this space are improvements to portability and speed. My snarky response to the author's title would be that you can take your GUIs and all the janky flashing lights they entail and shove them up your ass.

joshka 2mo ago
The problem is that cells don't compose well as an accessibility thing. You need a DOM equivalent in order to realistically do a bunch of things that are meaningful at an app level. TUI libraries are all basically doing that DOM thing already - just custom and treating the final shippable product as the cells, positions and imperative instructions for how to tell a terminal what to do. I' just saying that a more declarative interaction is very likely the sort of simple and boring that helps portability (long term) and speed.
- fc417fc802 2mo ago
  Upon reflection, I think the only thing I'm opposed to is visible "features". As long as the final output remains a dumb grid of cells with extremely limited capabilities I can see where it would be useful for accessibility (or other) purposes to have a bunch of metadata in a standardized format describing the model that underlies the final output. A number of times I've been frustrated by the lack of additional channels when processing streams of data.