8 ms·

As a ratatui library maintainer, NO - please don't stop making TUIs ;) As a developer outside of that, I love the scratch the itch apps stuff mentioned in here

by joshka 2mo ago

As a ratatui library maintainer, NO - please don't stop making TUIs ;) As a developer outside of that, I love the scratch the itch apps stuff mentioned in here. I have a vibe coded SwiftUI chess repertoire builder app that fits in that same sort of space that I'm currently working on, where I'd probably not have chosen to explore the idea if not for coding agents. I agree with the article that the terminal is an odd shape which you're fighting against historical specs, etc. The key observation I have though is that the mismatch of terminal apps and libraries to deal with this are all fundamentally built around character cells and cursor movement plus various CSI/OSC/ASC/DEC/xterm/... protocols which are complex and have varying support and interact in weird ways. To get a good terminal UX, I think the answer to this is probably to throw all that compatibility mess away and redesign a modern terminal protocol that bakes in accessibility, regions, scrolling, selection, proper keyboard, etc. I know Mitchell Hashimoto has a bit of a different perspective on this, which seems like it's to define some more protocol stuff and continue to build up on things. I think that probably gets to 95% pretty well. But a 100% good is a full replacement.

anon7000 2mo ago
> To get a good terminal UX, I think the answer to this is probably to throw all that compatibility mess away and redesign a modern terminal protocol that bakes in accessibility, regions, scrolling, selection, proper keyboard, etc. Why not just… a GUI framework or layout that’s meant to be keyboard driven and information dense?
- jeroenhd 2mo ago
  TUIs run on any OS with minor patches to support quirks, GUI frameworks need a lot of work. TUIs don't need to follow any OS guidelines, cross-platform GUIs always look bad outside of the "main" platform. If you're only targeting macOS/Windows/Gnome/KDE then the solution is easy: just grab a GUI control set and go ham. Then there's remote access: you can spawn an X11 app through X forwarding and have a terrible laggy experience on Linux, you can use RemoteApps on Windows to have a good remote experience (but almost no other platform), you can use VNC to have an awful cross-platform experience, or you can use a TUI and have all the graphs and interactivity you need over a responsive, low-bandwidth connection on any combination of client+server.
  - wiseowise 2mo ago
    > TUIs don't need to follow any OS guidelines, cross-platform GUIs always look bad outside of the "main" platform. So because TUIs look universally bad, they're better than cross-platform GUI?
    - Dilettante_ 2mo ago
      >So because TUIs look universally bad You can't stay engaged if the menus don't bleep and bloop at you and confetti rains down on every click? That's a personal problem. A minimal UI is not automatically a bad-looking UI.
      - WA 2mo ago
        No, but I want to click to place the cursor in my 10 line prompt wherever I want. I want to double click to mark words. I want to use a scroll bar. I want to copy paste properly and not "23 lines pasted". I don’t want to read docs to find all keystrokes the TUI supports to achieve what I want.
        maleldil 2mo ago
        > not "23 lines pasted" If you mean what Claude Code does when you paste longer text, you can just press Cmd-V again to show the full text.
        WA 2mo ago
        Thanks. Kinda proves my point about TUIs having all kinds of hidden keyboard shortcuts.
        maleldil 2mo ago
        You're definitely right about that. I couldn't tell you where I found out about this keybind.
        2mo ago
- Brian_K_White 2mo ago
  Countless reasons. Invent a gui client environment that is universal, works the same way everywhere, over any kind of channel, and is already implimented and supported everywhere, and utterly weightless in all dimensions (ram/cpu/network), and then you might be able to ask that question without it being incredibly ignorant. Today the closest you might be able to say is web/electron, which is gross on all counts. If anything the closest is X11, which is not remotely close enough. That's why not just...
  - crostlybostly 2mo ago
    HTML/Javascript would like a word
    - flossly 2mo ago
      we need a way to access locally running web apps without doing an ugly http://localhost:8022 and having to remember that. I'd say http://localapps should give an overview of all web apps running locally, with links to them. Those links should follow a naming scheme where the hostname ends with `.local` or smth. So: http://claudecode.local http://claudecode.local
      - antonvs 2mo ago
        > I'd say http://localapps should give an overview of all web apps running locally, with links to them. Malware will thank you.
      - fc417fc802 2mo ago
        Won't that be cluttered by various random processes listening via 0/0? Perhaps we need a standardized service that web apps can register with.
      - mr_olive 2mo ago
        Hah, I was dealing with this problem today. My approach: Add entries for my localhost apps to `/etc/hosts`, and set up nginx as a reverse proxy. Now when I go to `http://myapp.local http://myapp.local` in the browser, `/etc/hosts` tells it to go to `localhost:80`. The http server sitting there knows which port to send the request to. I also made a systemd service that starts nginx automatically. Now I have meaningful URLs for local apps, and I don't have to remember which one is listening on which port.
- trueno 2mo ago
  there's a million gui frameworks under the sun and i still haven't found one that feels like what everyone has been asking for: good dx, cross platform, fast, not ugly. pick i dunno 2 or 3. tui's get to check 2 or 3 of these just like any other gui library. somehow there still isn't a silver bullet here. now i personally don't build tuis but guake style dropdown simple command and i have some other thing someone made open immediately running in ghostty? hell yea. with that said yes there are some stupid tuis out there that are anything but simple.
  - singpolyma3 2mo ago
    Except web. Which inexplicably got all of these when no one was looking
    - TylerE 2mo ago
      Not fast.
      - psychoslave 2mo ago
        That depends what is build and how. Granted that a modern web browser is indeed an order of magnitude heavier than an OS, once that ticket is paid anyway, one can built very far, without relying on any additional bloat that contemporary web frameworks puts on top of it. There is not that much more data to send though HTTPS to bring a far more convenient UX than what raw text bespoke tweaks can offer over SSH.
      - singpolyma3 2mo ago
        How so? You can make slow things with it of course but it's not inherent.
      - zbentley 2mo ago
        Not “not ugly” either. The flexibility is too high and standardization of UX is too low. Technically, we’re missing adoption of default standard toolkits like swing or GTK, and politically a11y/compliance checkers are a far cry from something like the HIG of old.
- barnabee 2mo ago
  Agreed. This is exactly what I want, ideally with components and libraries and panels and data shareable and extendable between applications. The closest in spirit is Probably something like Dear ImGui[0] and the ecosystem of components and apps built with it, but it's not quite there for me. Something is missing. [0] https://github.com/ocornut/imgui https://github.com/ocornut/imgui
  - jrop 2mo ago
    [flagged]
- tyre 2mo ago
  charm.sh builds many such things. I love them and their personality.
- christophilus 2mo ago
  It’s trivially easy to run a TUI in a container. Not so much with GUIs. And, since I run as much as possible in containers, and as little as possible on my host machine, I much prefer TUIs.
  - yencabulator 2mo ago
    Wayland runs over a UNIX domain socket you know. And if you meant "virtual machine" or "cloud" by saying "container", `waypipe ssh myhost`.
  - pjmlp 2mo ago
    It is as easy as any X Windows or RDP connection.
- ziotom78 2mo ago
  BearLibTerminal might be something on this line, although its purpose is mainly for developing rougue-like games. It simulates a terminal in a GUI with a high-level API http://foo.wyrd.name/en:bearlibterminal http://foo.wyrd.name/en:bearlibterminal
  - joshka 2mo ago
    yeah, something along those lines - but more robustly defined.
fc417fc802 2mo ago
> 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.
torginus 2mo ago
I have a question - I've briefly looked at the API, and it seems like a mostly general-purpose user interfance library. What do you think of replacing the 'render' part with something that's more like a generic UI? You could keep the UX the same, yet your app would look like a desktop app (or at least close to it). Trying to fit in the limitations of 80x25 text rendering is cool, but there's nothing in the underlying architecture that of modern graphics display that's predisposed to that, it all ends up as GPU commands. I'm sure you could get most of the way to what I'm describing with just replacing the font/character set with one that renders things like borders in greater detail. Hell, you could even add this as post-processing. You look at the terminal output with cellular automata like rules, and try to render UI primitives fitting that.
- joshka 2mo ago
  If you're redesigning a protocol layer, then I'd say you still want to target fixed size cells as the unit of rendering. It's just not the central abstraction like it is in the current terminal approach. Because you're one step above here, you have th ability to do better border handling. There's a lot a things you miss trying to force borders through a character set thing (e.g. missing characters depending on your font, missing ability to position borders naturally, interaction with background color, adjustment of size and space of rendered text due to interaction with unicode characters and fixed positioning) ... But in general, going with a fresh new protocol allows you to do a bunch of things semantically that are currently done as pure graphical stuff and that's useful.
  - torginus 2mo ago
    I was suggesting something that could be done without changing the protocol itself. From what I undestand, the terminal is essentially a concatenative text buffer extended with control commands allowing you to move the cursor (pen) to draw more sophisticated stuff, and update UIs. The logical way to extend this would be to allow genericdrawing commands over the protocol, at which point the whole thing starts sounding like X11. I'm sure the Unix people at MIT in the 80s saw this as the natural evolution from text terminals to graphics based ones. Not saying this is a bad idea, but sounds suspiciously like a retread of history. Or you might want to stop before that, as you suggested, at targeting fixed size cells for rendering, and keeping the console-like UX throughout. I'm sure there's a sensible intermediate step, but if you want to do things like displaying graphs or images (turning the terminal into something that's halfway between a terminal emulator and a Jupyter notebook), it'd be awkward to respect the character grid and the non-square characters themselves. I'm curious what you think about how far this new protocol should go, and in what direction. You mention 'semantics', as describing behavior, not just what gets drawn to the screen, which neither X11 nor tty does.
fractorial 2mo ago
Damn, what an epic library name.
jrop 2mo ago
The approach you're describing (redesign the protocol) is one path. Another is to sidestep the protocol entirely by using a platform that already owns its rendering surface and happens to run in a terminal: my preference is Neovim. Let me get the caveats out of the way first: this only makes sense if you already live in Neovim. The whole ergonomic case is muscle memory you already have. If you're not a Neovim user, you're just buying another learning curve. Also, the language is Lua (not Rust) so it won't appeal to the ratatui crowd on that front, and there's no proper layout system yet. Neovim [0] renders to its own buffer system (extmarks, floating windows, virtual text) rather than emitting ANSI escape codes. Under the hood it's still a terminal app, but from the UI author's perspective you're not fighting terminfo, CSI sequences, or varying terminal support. You get proper cursor tracking, scroll regions, and editable text areas out of the box. On the UI framework side, morph.nvim [1] provides a React-like component model (h(), state, reconciliation) on top of Neovim. It's not a general answer the way ratatui is, but for the slice of devs already in Neovim (there are dozens of us!), it's a pragmatic way to get GUI-framework-like ergonomics without the terminal protocol fight. For a sample of what TUIs in this paradigm can look like, I've been working on tuis.nvim [2] (Docker, K8s, SystemD services, process management, and more all as native Neovim buffer TUIs). [0] https://neovim.io https://neovim.io [1] https://github.com/jrop/morph.nvim https://github.com/jrop/morph.nvim [2] https://github.com/jrop/tuis.nvim https://github.com/jrop/tuis.nvim
- joshka 2mo ago
  I have built a pretty full version of that idea in rust (codex tui2). There's a while tonne of downsides that make it basically impossible to really get to 100% good on this. > Under the hood it's still a terminal app, but from the UI author's perspective you're not fighting terminfo, CSI sequences, or varying terminal support. You get proper cursor tracking, scroll regions, and editable text areas out of the box. All that is not true. Take scrolling for example. Each terminal emulator implements this subtly differently (mouse/trackpad/speed etc.), scrolling will never feel native unless you push the control of it into the terminal emulator. There's more than that, each and every point on this becomes something that you have a gap between native and the terminal emulator that you're building to run in the terminal. See https://github.com/openai/codex/issues/8344 https://github.com/openai/codex/issues/8344 and https://github.com/openai/codex/pull/9640 https://github.com/openai/codex/pull/9640 Claude code and gemini have both had various versions of the same idea at times. I'm unsure where they ended up.
vatsachak 2mo ago
So...emacs
- pjmlp 2mo ago
  Which is kind of a poor man's Lisp Machines. https://interlisp.org https://interlisp.org
internet2000 2mo ago
Not only I want people to stop making TUIs, I want you to stop maintaining your TUI library!
tptacek 2mo ago
Ratatui is such great work. The New Terminal, the complete break from VT100, is I think the most powerful rebuttal to what I'm saying about TUIs. My take is that the Morlocks should pack everything that is great about TUIs (and there are great things about them) and move them upstairs to live alongside the Eloi in GUI-land. Let 1000 Bloomberg terminal interfaces bloom. But there's another even more ambitious take on this, which is to take everything that's pleasant and good about Eloi world and bring it down into the Morlock caves. I don't think you can accomplish that so long as you're drawing interfaces with punctuation characters, but there's nothing to say a terminal has to work that way; you can have a terminal with rich out-of-band-signaled UI. Not just, like, Kitty graphics, but something more like a real terminal that is meant from day 1 to work with all the complexity of a Bloomberg terminal. You could have had it in 2010, but it's a king hell mess to put together, and you'd sort of assume nobody was going to use it (because it's a break from VT100 compatibility). But that doesn't matter anymore! We are the music makers, &c &c. I think a lot of very smart people assume we're going to build up from VT100 to something incrementally but significantly better (Ghostty is already materially better than anything I'd used prior). But I hope those people eventually set their sights higher.
- joshka 2mo ago
  > as you're drawing interfaces with punctuation characters Yeah, in my hypothetical new protocol, the character cell is still there, but it's not the element that drives the main abstraction. The layer above that being more semantic is where the smarts is. So borders, interactive areas, mouse hit mapping to elements, etc. ends up being built into the protocol rather than being a cell level thing. Cells having proper borders being similar to how they allow for underline, being able to have both images and text, ... I think it's important to do something about the VT100 +kitchen sink stack and to have that as something that still works with that in areas of the new terminal proto. I've got a slopcoded rust library in the works that's about fully mapping the full list of terminal protocols and related things in one coherent library (VT100, ECMA48, DEC modes, iTerm extensions, Kitty, ...). From there I think making that fairly isomorphic with the terminal emulator layer (I have a RIIR ghostty slopfactor there too that fits). I think ghostty / superlogical looks at this from the perspective of doing pty things and then transfering that calculated state across the wire while doing fun stuff with windows, panes etc. with replay and that sort of thing. I think this is valuable too. I suspect that there's possibly a way to do a bit of a hybrid on this - normal pty things with the extra sidecar of more semantic structured, but it'll make things more complex for app builders on that side of things. (On another comment I saw you mentioned "couldn't help noticing how much of the tedious work of putting a TUI together". I think probably textual in python is probably the best of the low ceremony libraries for making TUIs if you haven't checked that out yet. I think someday there will be a good Rust library that has that level of put together-ness. I have some ideas on this for ratatui and have seen a bunch of things that are directionally right for this, but nothing that gets close yet).
quantumwannabe 2mo ago
Grok Build uses your library and it has the best TUI of any app I've ever used. It has a lot of features that we take for granted in GUIs like scrollable regions, buttons, collapsible panes, and text selection. I don't know why Codex and Claude Code haven't switched over; both apps have a terrible UI in comparison.
- joshka 2mo ago
  Codex uses Ratatui also since June last year. You might be interested to read https://github.com/openai/codex/issues/8344 https://github.com/openai/codex/issues/8344 There's a lot of things you can do to get to 90-95% fidelity with a normal scollable terminal, but that last 5-10% is impossible. And it's because the you're throwing away a bunch of information about mouse movements, clicks, scrolling, keyboard on the input side and all the layout info on the output side (the terminal just sees cells, locations, etc.). A good analogy is what if your webserver could only send pixels, not html. And receive raw mouse movements. The amount of stuff you have to do to reconcile that across operating systems and hardware would be enormous. That's what you realistically have when you're writing a tool that reimplements all the bits from a terminal emulator in a tui.
chamomeal 2mo ago
I’ve found some of my favorite TUI apps by scrolling around in the built-with-ratatui page. I have always bounced off of rust but ratatui must be a great library!!

by joshka 2mo ago

anon7000 2mo ago

> To get a good terminal UX, I think the answer to this is probably to throw all that compatibility mess away and redesign a modern terminal protocol that bakes in accessibility, regions, scrolling, selection, proper keyboard, etc. Why not just… a GUI framework or layout that’s meant to be keyboard driven and information dense?

jeroenhd 2mo ago
TUIs run on any OS with minor patches to support quirks, GUI frameworks need a lot of work. TUIs don't need to follow any OS guidelines, cross-platform GUIs always look bad outside of the "main" platform. If you're only targeting macOS/Windows/Gnome/KDE then the solution is easy: just grab a GUI control set and go ham. Then there's remote access: you can spawn an X11 app through X forwarding and have a terrible laggy experience on Linux, you can use RemoteApps on Windows to have a good remote experience (but almost no other platform), you can use VNC to have an awful cross-platform experience, or you can use a TUI and have all the graphs and interactivity you need over a responsive, low-bandwidth connection on any combination of client+server.
- wiseowise 2mo ago
  > TUIs don't need to follow any OS guidelines, cross-platform GUIs always look bad outside of the "main" platform. So because TUIs look universally bad, they're better than cross-platform GUI?
  - Dilettante_ 2mo ago
    >So because TUIs look universally bad You can't stay engaged if the menus don't bleep and bloop at you and confetti rains down on every click? That's a personal problem. A minimal UI is not automatically a bad-looking UI.
    - WA 2mo ago
      No, but I want to click to place the cursor in my 10 line prompt wherever I want. I want to double click to mark words. I want to use a scroll bar. I want to copy paste properly and not "23 lines pasted". I don’t want to read docs to find all keystrokes the TUI supports to achieve what I want.
      - maleldil 2mo ago
        > not "23 lines pasted" If you mean what Claude Code does when you paste longer text, you can just press Cmd-V again to show the full text.
        WA 2mo ago
        Thanks. Kinda proves my point about TUIs having all kinds of hidden keyboard shortcuts.
        maleldil 2mo ago
        You're definitely right about that. I couldn't tell you where I found out about this keybind.
      - 2mo ago
Brian_K_White 2mo ago
Countless reasons. Invent a gui client environment that is universal, works the same way everywhere, over any kind of channel, and is already implimented and supported everywhere, and utterly weightless in all dimensions (ram/cpu/network), and then you might be able to ask that question without it being incredibly ignorant. Today the closest you might be able to say is web/electron, which is gross on all counts. If anything the closest is X11, which is not remotely close enough. That's why not just...
- crostlybostly 2mo ago
  HTML/Javascript would like a word
  - flossly 2mo ago
    we need a way to access locally running web apps without doing an ugly http://localhost:8022 and having to remember that. I'd say http://localapps should give an overview of all web apps running locally, with links to them. Those links should follow a naming scheme where the hostname ends with `.local` or smth. So: http://claudecode.local http://claudecode.local
    - antonvs 2mo ago
      > I'd say http://localapps should give an overview of all web apps running locally, with links to them. Malware will thank you.
    - fc417fc802 2mo ago
      Won't that be cluttered by various random processes listening via 0/0? Perhaps we need a standardized service that web apps can register with.
    - mr_olive 2mo ago
      Hah, I was dealing with this problem today. My approach: Add entries for my localhost apps to `/etc/hosts`, and set up nginx as a reverse proxy. Now when I go to `http://myapp.local http://myapp.local` in the browser, `/etc/hosts` tells it to go to `localhost:80`. The http server sitting there knows which port to send the request to. I also made a systemd service that starts nginx automatically. Now I have meaningful URLs for local apps, and I don't have to remember which one is listening on which port.
trueno 2mo ago
there's a million gui frameworks under the sun and i still haven't found one that feels like what everyone has been asking for: good dx, cross platform, fast, not ugly. pick i dunno 2 or 3. tui's get to check 2 or 3 of these just like any other gui library. somehow there still isn't a silver bullet here. now i personally don't build tuis but guake style dropdown simple command and i have some other thing someone made open immediately running in ghostty? hell yea. with that said yes there are some stupid tuis out there that are anything but simple.
- singpolyma3 2mo ago
  Except web. Which inexplicably got all of these when no one was looking
  - TylerE 2mo ago
    Not fast.
    - psychoslave 2mo ago
      That depends what is build and how. Granted that a modern web browser is indeed an order of magnitude heavier than an OS, once that ticket is paid anyway, one can built very far, without relying on any additional bloat that contemporary web frameworks puts on top of it. There is not that much more data to send though HTTPS to bring a far more convenient UX than what raw text bespoke tweaks can offer over SSH.
    - singpolyma3 2mo ago
      How so? You can make slow things with it of course but it's not inherent.
    - zbentley 2mo ago
      Not “not ugly” either. The flexibility is too high and standardization of UX is too low. Technically, we’re missing adoption of default standard toolkits like swing or GTK, and politically a11y/compliance checkers are a far cry from something like the HIG of old.
barnabee 2mo ago
Agreed. This is exactly what I want, ideally with components and libraries and panels and data shareable and extendable between applications. The closest in spirit is Probably something like Dear ImGui[0] and the ecosystem of components and apps built with it, but it's not quite there for me. Something is missing. [0] https://github.com/ocornut/imgui https://github.com/ocornut/imgui
- jrop 2mo ago
  [flagged]
tyre 2mo ago
charm.sh builds many such things. I love them and their personality.
christophilus 2mo ago
It’s trivially easy to run a TUI in a container. Not so much with GUIs. And, since I run as much as possible in containers, and as little as possible on my host machine, I much prefer TUIs.
- yencabulator 2mo ago
  Wayland runs over a UNIX domain socket you know. And if you meant "virtual machine" or "cloud" by saying "container", `waypipe ssh myhost`.
- pjmlp 2mo ago
  It is as easy as any X Windows or RDP connection.
ziotom78 2mo ago
BearLibTerminal might be something on this line, although its purpose is mainly for developing rougue-like games. It simulates a terminal in a GUI with a high-level API http://foo.wyrd.name/en:bearlibterminal http://foo.wyrd.name/en:bearlibterminal
- joshka 2mo ago
  yeah, something along those lines - but more robustly defined.

fc417fc802 2mo ago

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

torginus 2mo ago

I have a question - I've briefly looked at the API, and it seems like a mostly general-purpose user interfance library. What do you think of replacing the 'render' part with something that's more like a generic UI? You could keep the UX the same, yet your app would look like a desktop app (or at least close to it). Trying to fit in the limitations of 80x25 text rendering is cool, but there's nothing in the underlying architecture that of modern graphics display that's predisposed to that, it all ends up as GPU commands. I'm sure you could get most of the way to what I'm describing with just replacing the font/character set with one that renders things like borders in greater detail. Hell, you could even add this as post-processing. You look at the terminal output with cellular automata like rules, and try to render UI primitives fitting that.

joshka 2mo ago
If you're redesigning a protocol layer, then I'd say you still want to target fixed size cells as the unit of rendering. It's just not the central abstraction like it is in the current terminal approach. Because you're one step above here, you have th ability to do better border handling. There's a lot a things you miss trying to force borders through a character set thing (e.g. missing characters depending on your font, missing ability to position borders naturally, interaction with background color, adjustment of size and space of rendered text due to interaction with unicode characters and fixed positioning) ... But in general, going with a fresh new protocol allows you to do a bunch of things semantically that are currently done as pure graphical stuff and that's useful.
- torginus 2mo ago
  I was suggesting something that could be done without changing the protocol itself. From what I undestand, the terminal is essentially a concatenative text buffer extended with control commands allowing you to move the cursor (pen) to draw more sophisticated stuff, and update UIs. The logical way to extend this would be to allow genericdrawing commands over the protocol, at which point the whole thing starts sounding like X11. I'm sure the Unix people at MIT in the 80s saw this as the natural evolution from text terminals to graphics based ones. Not saying this is a bad idea, but sounds suspiciously like a retread of history. Or you might want to stop before that, as you suggested, at targeting fixed size cells for rendering, and keeping the console-like UX throughout. I'm sure there's a sensible intermediate step, but if you want to do things like displaying graphs or images (turning the terminal into something that's halfway between a terminal emulator and a Jupyter notebook), it'd be awkward to respect the character grid and the non-square characters themselves. I'm curious what you think about how far this new protocol should go, and in what direction. You mention 'semantics', as describing behavior, not just what gets drawn to the screen, which neither X11 nor tty does.

fractorial 2mo ago

Damn, what an epic library name.

jrop 2mo ago

The approach you're describing (redesign the protocol) is one path. Another is to sidestep the protocol entirely by using a platform that already owns its rendering surface and happens to run in a terminal: my preference is Neovim. Let me get the caveats out of the way first: this only makes sense if you already live in Neovim. The whole ergonomic case is muscle memory you already have. If you're not a Neovim user, you're just buying another learning curve. Also, the language is Lua (not Rust) so it won't appeal to the ratatui crowd on that front, and there's no proper layout system yet. Neovim [0] renders to its own buffer system (extmarks, floating windows, virtual text) rather than emitting ANSI escape codes. Under the hood it's still a terminal app, but from the UI author's perspective you're not fighting terminfo, CSI sequences, or varying terminal support. You get proper cursor tracking, scroll regions, and editable text areas out of the box. On the UI framework side, morph.nvim [1] provides a React-like component model (h(), state, reconciliation) on top of Neovim. It's not a general answer the way ratatui is, but for the slice of devs already in Neovim (there are dozens of us!), it's a pragmatic way to get GUI-framework-like ergonomics without the terminal protocol fight. For a sample of what TUIs in this paradigm can look like, I've been working on tuis.nvim [2] (Docker, K8s, SystemD services, process management, and more all as native Neovim buffer TUIs). [0] https://neovim.io https://neovim.io [1] https://github.com/jrop/morph.nvim https://github.com/jrop/morph.nvim [2] https://github.com/jrop/tuis.nvim https://github.com/jrop/tuis.nvim

joshka 2mo ago
I have built a pretty full version of that idea in rust (codex tui2). There's a while tonne of downsides that make it basically impossible to really get to 100% good on this. > Under the hood it's still a terminal app, but from the UI author's perspective you're not fighting terminfo, CSI sequences, or varying terminal support. You get proper cursor tracking, scroll regions, and editable text areas out of the box. All that is not true. Take scrolling for example. Each terminal emulator implements this subtly differently (mouse/trackpad/speed etc.), scrolling will never feel native unless you push the control of it into the terminal emulator. There's more than that, each and every point on this becomes something that you have a gap between native and the terminal emulator that you're building to run in the terminal. See https://github.com/openai/codex/issues/8344 https://github.com/openai/codex/issues/8344 and https://github.com/openai/codex/pull/9640 https://github.com/openai/codex/pull/9640 Claude code and gemini have both had various versions of the same idea at times. I'm unsure where they ended up.

vatsachak 2mo ago

So...emacs

pjmlp 2mo ago
Which is kind of a poor man's Lisp Machines. https://interlisp.org https://interlisp.org

internet2000 2mo ago

Not only I want people to stop making TUIs, I want you to stop maintaining your TUI library!

tptacek 2mo ago

Ratatui is such great work. The New Terminal, the complete break from VT100, is I think the most powerful rebuttal to what I'm saying about TUIs. My take is that the Morlocks should pack everything that is great about TUIs (and there are great things about them) and move them upstairs to live alongside the Eloi in GUI-land. Let 1000 Bloomberg terminal interfaces bloom. But there's another even more ambitious take on this, which is to take everything that's pleasant and good about Eloi world and bring it down into the Morlock caves. I don't think you can accomplish that so long as you're drawing interfaces with punctuation characters, but there's nothing to say a terminal has to work that way; you can have a terminal with rich out-of-band-signaled UI. Not just, like, Kitty graphics, but something more like a real terminal that is meant from day 1 to work with all the complexity of a Bloomberg terminal. You could have had it in 2010, but it's a king hell mess to put together, and you'd sort of assume nobody was going to use it (because it's a break from VT100 compatibility). But that doesn't matter anymore! We are the music makers, &c &c. I think a lot of very smart people assume we're going to build up from VT100 to something incrementally but significantly better (Ghostty is already materially better than anything I'd used prior). But I hope those people eventually set their sights higher.

joshka 2mo ago
> as you're drawing interfaces with punctuation characters Yeah, in my hypothetical new protocol, the character cell is still there, but it's not the element that drives the main abstraction. The layer above that being more semantic is where the smarts is. So borders, interactive areas, mouse hit mapping to elements, etc. ends up being built into the protocol rather than being a cell level thing. Cells having proper borders being similar to how they allow for underline, being able to have both images and text, ... I think it's important to do something about the VT100 +kitchen sink stack and to have that as something that still works with that in areas of the new terminal proto. I've got a slopcoded rust library in the works that's about fully mapping the full list of terminal protocols and related things in one coherent library (VT100, ECMA48, DEC modes, iTerm extensions, Kitty, ...). From there I think making that fairly isomorphic with the terminal emulator layer (I have a RIIR ghostty slopfactor there too that fits). I think ghostty / superlogical looks at this from the perspective of doing pty things and then transfering that calculated state across the wire while doing fun stuff with windows, panes etc. with replay and that sort of thing. I think this is valuable too. I suspect that there's possibly a way to do a bit of a hybrid on this - normal pty things with the extra sidecar of more semantic structured, but it'll make things more complex for app builders on that side of things. (On another comment I saw you mentioned "couldn't help noticing how much of the tedious work of putting a TUI together". I think probably textual in python is probably the best of the low ceremony libraries for making TUIs if you haven't checked that out yet. I think someday there will be a good Rust library that has that level of put together-ness. I have some ideas on this for ratatui and have seen a bunch of things that are directionally right for this, but nothing that gets close yet).

quantumwannabe 2mo ago

Grok Build uses your library and it has the best TUI of any app I've ever used. It has a lot of features that we take for granted in GUIs like scrollable regions, buttons, collapsible panes, and text selection. I don't know why Codex and Claude Code haven't switched over; both apps have a terrible UI in comparison.

joshka 2mo ago
Codex uses Ratatui also since June last year. You might be interested to read https://github.com/openai/codex/issues/8344 https://github.com/openai/codex/issues/8344 There's a lot of things you can do to get to 90-95% fidelity with a normal scollable terminal, but that last 5-10% is impossible. And it's because the you're throwing away a bunch of information about mouse movements, clicks, scrolling, keyboard on the input side and all the layout info on the output side (the terminal just sees cells, locations, etc.). A good analogy is what if your webserver could only send pixels, not html. And receive raw mouse movements. The amount of stuff you have to do to reconcile that across operating systems and hardware would be enormous. That's what you realistically have when you're writing a tool that reimplements all the bits from a terminal emulator in a tui.

chamomeal 2mo ago

I’ve found some of my favorite TUI apps by scrolling around in the built-with-ratatui page. I have always bounced off of rust but ratatui must be a great library!!