6 ms·

Strace-ui, Bonsai_term, and the TUI renaissance

158 points by matt_d 5mo ago

rbanffy 5mo ago
I wish more terminals supported Tektronix and ReGIS graphics. We could do some really interesting visuals with those.
laidoffamazon 5mo ago
[flagged]
- Balinares 5mo ago
  They (correctly IMO) seem to think that the hard thing in sourcing the top candidates by the sort of metric they care about, is getting them to even know about you as a potential employer. That means figuring out where those candidates might be and finding ways to get your name in front of their eyeballs. So, cool nerdy blog posts on HN, cool nerdy puzzles on Cracking the Cryptic, etc. Having been sorta involved in hiring in the same sorta market, I can respect how astute their approach is.
knuckleheads 5mo ago
I have had a similar notion, around the same time, with tui's and strace in particular. Lots of experiments, never quite good enough to publish or try to popularize. Something I've found in the last few years though, and especially the last six months, is that the impulse to make a better tui has died for me. Claude et al are going to wield these tools via cli far better than I can via tui. The built in visualization is nice for sure in tui, an embodied perspective on how to investigate something, however Claude can make a custom one for me in the moment within a few minutes. My impulse is to throw Claude at the issue with the bare linux toolbox while I do other things, not hand craft better tools that I don't have much motivation to use right now.
- tuo-lei 5mo ago
  [dead]
haeseong 5mo ago
The deeper reason agents write good Bonsai_term code is that the entire UI renders as plain text, so a screenshot test is just a diff the model can read and verify on its own. A GUI's visual state needs a vision model to inspect, but a TUI's output already lives in the agent's native modality, which closes the feedback loop for free.
- nsonha 5mo ago
  for snapshot tests it seems better to diff a data representation such as some yaml string, than to diff UIs
  - rickyvetter 5mo ago
    The whole UI seems better for LLMs to consume and also displays nicely in-editor for humans. Test failures become failing screenshot tests essentially, which are really comfortable changes to review.
    - nsonha 5mo ago
      "displays nicely in-editor" is the whole point of yaml. The snapshots in the article are just yaml with additional useless ASCII characters
      - rickyvetter 5mo ago
        Yaml is just a serialization of some intermediate representation. The expect test output in the article is a full-fidelity (minus color) rendering of the UI. I would argue that the final app UI is both easier to read for humans and covers more code. As an example, a naive yaml test would likely not capture positions of all of the elements in the app and so you’d be able to silently introduce positioning bugs. On the flip side, if the yaml does include positioning information then it’s now substantially harder to read than the UI test and the signal from the test is compromised because readers will have a harder time understanding and be more likely to ignore.
- 5mo ago
krismatja 5mo ago
Interesting that Jane Street has taken an interest in TUIs, I think mostly this renaissance is partly due to the current bloat of Electron GUIs. There are other great examples of TUIs that i've seen around the web: https://github.com/ratatui/awesome-ratatui https://github.com/ratatui/awesome-ratatui https://terminaltrove.com/explore/ https://terminaltrove.com/explore/ https://github.com/rothgar/awesome-tuis https://github.com/rothgar/awesome-tuis But I think we will swing back to using GUIs when we find a performant way of making them, I don't know what it is yet but surely someone is working on this. TUIs look good to look at though!
- deleted 5mo ago
  [deleted]
- oDot 5mo ago
  Yep, that's about it. I am making a TUI for non-techies, packing it with Ghostty, and sending it to non-techies to use: https://github.com/weedonandscott/trolley https://github.com/weedonandscott/trolley
  - fragmede 5mo ago
    Soooo... lib ghostty supports the kitty (but not sixel) terminal image format.
  - FergusArgyll 5mo ago
    Cool idea!
- schonfinkel 5mo ago
  > But I think we will swing back to using GUIs when we find a performant way of making them I like this new TUI renaissance as well, but if you wanna see what a symbiotic relationship between GUIs x TUIs could look like you need to see what Emacs does with Orgmode and the whole Org ecosystem of org-agenda, org-roam, etc. Lot's of these TUIs from the awesome are somewhat already inside Emacs. https://orgmode.org/ https://orgmode.org/ https://orgmode.org/manual/Agenda-Views.html https://orgmode.org/manual/Agenda-Views.html
- 5mo ago
bedstefar 5mo ago
I don't really get the TUI craze. Would love it if someone has some perspective that I'm lacking. Display technology has seen so much progress in the past decades. Apple marketing has taught us about "Retina" displays with pixels so small that you can't tell them apart without a microscope. We get these very rich and colorful desktop environments but we actively decide to not use any of that. Now, I get that a TUI can look incredibly crisp with proper text rendering, kerning, ligatures, nerd fonts and so on, but still with all that, at the end of the day we still have a thingamajig that implements a VT100. It is a strict subset of what could potentially be drawn with a proper GUI framework. I understand that TUIs can run over SSH channels, can be juggled with Zellij/tmux/mprocs -- as such they are composable in the sense that they can be used in a way the author(s) didn't think of. It's been a while since I've done any of that personally, and I for one think it's a bit of a cop-out that the Claude Code integration in PyCharm is just the TUI [1] inside a terminal emulator inside my IDE when it could be so much more, just to provide one example. The article shows off an strace TUI, and it's not like I can't see the benefits of making strace output more browsable. What I don't understand is why that must happen inside a terminal window where (for instance) all text must have the same font and size. So what is the appeal? I'm asking in good faith. Is it because the perceived alternative is another run-off-the-mill Electron RAM guzzler, because there aren't any _good_ GUI widget frameworks? Is it the multi-platform aspect? If all we work in are these super-lean TUIs maybe we don't even need so powerful computers or such high-DPI displays anymore? I'm genuinely puzzled, but interested to know how TUIs appeal to other people. 1) which, I understand, is itself a React app with a console renderer!
- kamiheku 5mo ago
  I appreciate TUIs for - Optimizing for fast, keyboard-only usage - Allowing me to customize the presentation according to my preferences - Not having to leave my terminal, where I spend most of my time (I do realize this is something of a chicken-and-egg situation)
  - lobofta 5mo ago
    Right, not having to leave the terminal is a big one for me too. I live there and every time I start some desktop app, I gotta switch gears, potentially grab the mouse, leave my vim keybinds behind and leave my font and color scheme behind. I just feel more productive on the terminal then on desktop apps. I think also a big problem of desktop apps is that you have to deal with window management. Now that I am on Niri it is really apparent to me how much I hated juggling windows in pretty much any other window manager that I ever used, except, interestingly enough, tmux.
Natalia724 5mo ago
[flagged]
rickyvetter 5mo ago
I work on bonsai_term (though Jose is the primary author and many others have contributed incredible work). I'm happy to try and answer any questions that the post may bring up.
- zethus 5mo ago
  Hi ricky. No questions here, just a fan of yours.
- sn9 5mo ago
  Ask (tell!) Jose to release the manga reader!
lionkor 5mo ago
Slightly OT, but the next logical steps include, in no particular order: - frameworks for tui development, including react-like DOM shit - further ad-hoc specs building on top of ANSI escape codes for finer control - maybe a scripting language
- rbanffy 5mo ago
  > - frameworks for tui development, including react-like DOM shit React-ncurses FTW
- jrop 5mo ago
  I've been working on exactly this with morph.nvim [1] — a React-like component model (h(), component lifecycle, reconciliation, extmark-based styling) for building declarative TUIs. It uses Neovim as a base, which might seem like an odd choice, but Neovim gives a lot out of the box that most TUI frameworks don't: syntax highlighting, extmark tracking (i.e., editable regions that feed back into the component state — type in a filter and the UI re-renders around it), and navigation that Vim users already know without learning yet another keybinding layer. Built on top, tuis.nvim [2] ships real plugins — Docker, K8s, Bitwarden, process manager — all as native Neovim buffer TUIs. No Electron, no separate app window, runs over SSH. [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
- stronglikedan 5mo ago
  > frameworks for tui development https://github.com/ratatui/awesome-ratatui https://github.com/ratatui/awesome-ratatui
- gosub100 5mo ago
  GL accelerated TUIs.
globular-toast 5mo ago
TUIs are just GUIs that use a grid of characters instead of pixels. They are strictly worse than true GUIs, by definition. The only thing I liked TUIs for is running over SSH, but can any of these newer ones really run over SSH with any kind of decent performance anyway? I think people are confused and think they like TUIs because they like them being keyboard driven etc. But this could all be done with a GUI. The other factor is probably just fashion. Similar to how some kids are now listening to music on cassette tapes, which are objectively worse than other media in almost all respects. The less cynical take is it's like vinyl: it does come with compromises but gives us back some of the things we lost over the years. The actual interesting text-based interface is the CLI. I've seen a few examples of TUIs that really should be a CLI and would be much more useful as such.
LAC-Tech 5mo ago
Questiom for TUI writers - in 2026 is there any terminal emulator that doesn't understand ecma 48 control codes?
henry28256 5mo ago
[flagged]
typon 5mo ago
Always pains me to see all this innovation and cool software work being applies towards making a machine that extracts money from retail investors and makes a few people extremely wealthy. What a depressing and colossal waste of time.
0xdeadbeefbabe 5mo ago
Wasn't able to follow install instructions for bonsai_term. Have you seen ncurses? It's really easy to install.
zashboy 4mo ago
Worth adding to the list: TUIs have found an unexpected new job as the "read" layer for AI agents — they already render exactly the state the agent needs (fleet health, live metrics, log tails) without a separate REST API, and the MCP server just maps that state to tool calls. The shared human/agent view is what makes it interesting. That's the direction we took with Servonaut, a server management TUI with a built-in MCP server: https://github.com/zb-ss/servonaut https://github.com/zb-ss/servonaut.

158 points by matt_d 5mo ago

rbanffy 5mo ago

I wish more terminals supported Tektronix and ReGIS graphics. We could do some really interesting visuals with those.

laidoffamazon 5mo ago

[flagged]

Balinares 5mo ago
They (correctly IMO) seem to think that the hard thing in sourcing the top candidates by the sort of metric they care about, is getting them to even know about you as a potential employer. That means figuring out where those candidates might be and finding ways to get your name in front of their eyeballs. So, cool nerdy blog posts on HN, cool nerdy puzzles on Cracking the Cryptic, etc. Having been sorta involved in hiring in the same sorta market, I can respect how astute their approach is.

knuckleheads 5mo ago

I have had a similar notion, around the same time, with tui's and strace in particular. Lots of experiments, never quite good enough to publish or try to popularize. Something I've found in the last few years though, and especially the last six months, is that the impulse to make a better tui has died for me. Claude et al are going to wield these tools via cli far better than I can via tui. The built in visualization is nice for sure in tui, an embodied perspective on how to investigate something, however Claude can make a custom one for me in the moment within a few minutes. My impulse is to throw Claude at the issue with the bare linux toolbox while I do other things, not hand craft better tools that I don't have much motivation to use right now.

tuo-lei 5mo ago
[dead]

haeseong 5mo ago

The deeper reason agents write good Bonsai_term code is that the entire UI renders as plain text, so a screenshot test is just a diff the model can read and verify on its own. A GUI's visual state needs a vision model to inspect, but a TUI's output already lives in the agent's native modality, which closes the feedback loop for free.

nsonha 5mo ago
for snapshot tests it seems better to diff a data representation such as some yaml string, than to diff UIs
- rickyvetter 5mo ago
  The whole UI seems better for LLMs to consume and also displays nicely in-editor for humans. Test failures become failing screenshot tests essentially, which are really comfortable changes to review.
  - nsonha 5mo ago
    "displays nicely in-editor" is the whole point of yaml. The snapshots in the article are just yaml with additional useless ASCII characters
    - rickyvetter 5mo ago
      Yaml is just a serialization of some intermediate representation. The expect test output in the article is a full-fidelity (minus color) rendering of the UI. I would argue that the final app UI is both easier to read for humans and covers more code. As an example, a naive yaml test would likely not capture positions of all of the elements in the app and so you’d be able to silently introduce positioning bugs. On the flip side, if the yaml does include positioning information then it’s now substantially harder to read than the UI test and the signal from the test is compromised because readers will have a harder time understanding and be more likely to ignore.
5mo ago

krismatja 5mo ago

Interesting that Jane Street has taken an interest in TUIs, I think mostly this renaissance is partly due to the current bloat of Electron GUIs. There are other great examples of TUIs that i've seen around the web: https://github.com/ratatui/awesome-ratatui https://github.com/ratatui/awesome-ratatui https://terminaltrove.com/explore/ https://terminaltrove.com/explore/ https://github.com/rothgar/awesome-tuis https://github.com/rothgar/awesome-tuis But I think we will swing back to using GUIs when we find a performant way of making them, I don't know what it is yet but surely someone is working on this. TUIs look good to look at though!

deleted 5mo ago
[deleted]
oDot 5mo ago
Yep, that's about it. I am making a TUI for non-techies, packing it with Ghostty, and sending it to non-techies to use: https://github.com/weedonandscott/trolley https://github.com/weedonandscott/trolley
- fragmede 5mo ago
  Soooo... lib ghostty supports the kitty (but not sixel) terminal image format.
- FergusArgyll 5mo ago
  Cool idea!
schonfinkel 5mo ago
> But I think we will swing back to using GUIs when we find a performant way of making them I like this new TUI renaissance as well, but if you wanna see what a symbiotic relationship between GUIs x TUIs could look like you need to see what Emacs does with Orgmode and the whole Org ecosystem of org-agenda, org-roam, etc. Lot's of these TUIs from the awesome are somewhat already inside Emacs. https://orgmode.org/ https://orgmode.org/ https://orgmode.org/manual/Agenda-Views.html https://orgmode.org/manual/Agenda-Views.html
5mo ago

bedstefar 5mo ago

I don't really get the TUI craze. Would love it if someone has some perspective that I'm lacking. Display technology has seen so much progress in the past decades. Apple marketing has taught us about "Retina" displays with pixels so small that you can't tell them apart without a microscope. We get these very rich and colorful desktop environments but we actively decide to not use any of that. Now, I get that a TUI can look incredibly crisp with proper text rendering, kerning, ligatures, nerd fonts and so on, but still with all that, at the end of the day we still have a thingamajig that implements a VT100. It is a strict subset of what could potentially be drawn with a proper GUI framework. I understand that TUIs can run over SSH channels, can be juggled with Zellij/tmux/mprocs -- as such they are composable in the sense that they can be used in a way the author(s) didn't think of. It's been a while since I've done any of that personally, and I for one think it's a bit of a cop-out that the Claude Code integration in PyCharm is just the TUI [1] inside a terminal emulator inside my IDE when it could be so much more, just to provide one example. The article shows off an strace TUI, and it's not like I can't see the benefits of making strace output more browsable. What I don't understand is why that must happen inside a terminal window where (for instance) all text must have the same font and size. So what is the appeal? I'm asking in good faith. Is it because the perceived alternative is another run-off-the-mill Electron RAM guzzler, because there aren't any _good_ GUI widget frameworks? Is it the multi-platform aspect? If all we work in are these super-lean TUIs maybe we don't even need so powerful computers or such high-DPI displays anymore? I'm genuinely puzzled, but interested to know how TUIs appeal to other people. 1) which, I understand, is itself a React app with a console renderer!

kamiheku 5mo ago
I appreciate TUIs for - Optimizing for fast, keyboard-only usage - Allowing me to customize the presentation according to my preferences - Not having to leave my terminal, where I spend most of my time (I do realize this is something of a chicken-and-egg situation)
- lobofta 5mo ago
  Right, not having to leave the terminal is a big one for me too. I live there and every time I start some desktop app, I gotta switch gears, potentially grab the mouse, leave my vim keybinds behind and leave my font and color scheme behind. I just feel more productive on the terminal then on desktop apps. I think also a big problem of desktop apps is that you have to deal with window management. Now that I am on Niri it is really apparent to me how much I hated juggling windows in pretty much any other window manager that I ever used, except, interestingly enough, tmux.

Natalia724 5mo ago

[flagged]

rickyvetter 5mo ago

I work on bonsai_term (though Jose is the primary author and many others have contributed incredible work). I'm happy to try and answer any questions that the post may bring up.

zethus 5mo ago
Hi ricky. No questions here, just a fan of yours.
sn9 5mo ago
Ask (tell!) Jose to release the manga reader!

lionkor 5mo ago

Slightly OT, but the next logical steps include, in no particular order: - frameworks for tui development, including react-like DOM shit - further ad-hoc specs building on top of ANSI escape codes for finer control - maybe a scripting language

rbanffy 5mo ago
> - frameworks for tui development, including react-like DOM shit React-ncurses FTW
jrop 5mo ago
I've been working on exactly this with morph.nvim [1] — a React-like component model (h(), component lifecycle, reconciliation, extmark-based styling) for building declarative TUIs. It uses Neovim as a base, which might seem like an odd choice, but Neovim gives a lot out of the box that most TUI frameworks don't: syntax highlighting, extmark tracking (i.e., editable regions that feed back into the component state — type in a filter and the UI re-renders around it), and navigation that Vim users already know without learning yet another keybinding layer. Built on top, tuis.nvim [2] ships real plugins — Docker, K8s, Bitwarden, process manager — all as native Neovim buffer TUIs. No Electron, no separate app window, runs over SSH. [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
stronglikedan 5mo ago
> frameworks for tui development https://github.com/ratatui/awesome-ratatui https://github.com/ratatui/awesome-ratatui
gosub100 5mo ago
GL accelerated TUIs.

globular-toast 5mo ago

TUIs are just GUIs that use a grid of characters instead of pixels. They are strictly worse than true GUIs, by definition. The only thing I liked TUIs for is running over SSH, but can any of these newer ones really run over SSH with any kind of decent performance anyway? I think people are confused and think they like TUIs because they like them being keyboard driven etc. But this could all be done with a GUI. The other factor is probably just fashion. Similar to how some kids are now listening to music on cassette tapes, which are objectively worse than other media in almost all respects. The less cynical take is it's like vinyl: it does come with compromises but gives us back some of the things we lost over the years. The actual interesting text-based interface is the CLI. I've seen a few examples of TUIs that really should be a CLI and would be much more useful as such.

LAC-Tech 5mo ago

Questiom for TUI writers - in 2026 is there any terminal emulator that doesn't understand ecma 48 control codes?

henry28256 5mo ago

[flagged]

typon 5mo ago

Always pains me to see all this innovation and cool software work being applies towards making a machine that extracts money from retail investors and makes a few people extremely wealthy. What a depressing and colossal waste of time.

0xdeadbeefbabe 5mo ago

Wasn't able to follow install instructions for bonsai_term. Have you seen ncurses? It's really easy to install.

zashboy 4mo ago

Worth adding to the list: TUIs have found an unexpected new job as the "read" layer for AI agents — they already render exactly the state the agent needs (fleet health, live metrics, log tails) without a separate REST API, and the MCP server just maps that state to tool calls. The shared human/agent view is what makes it interesting. That's the direction we took with Servonaut, a server management TUI with a built-in MCP server: https://github.com/zb-ss/servonaut https://github.com/zb-ss/servonaut.