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
Strace-ui, Bonsai_term, and the TUI renaissance
71–80 of 91 posts
Re: Strace-ui, Bonsai_term, and the TUI renaissance
#72I 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 ca…
To be fair to Jetbrains, users would get charged API prices if they built their own integration. Zed recently added support for terminal sessions in the agent chat history for precisely this reason. Blame Anthropic.
Re: Strace-ui, Bonsai_term, and the TUI renaissance
#73Slightly 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
Re: Strace-ui, Bonsai_term, and the TUI renaissance
#74The 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.
- It opens to the editor mode rather than the gameplay mode on launch
- It makes a .run/ directory next to the executable if one doesn't already exist
- It makes a timestamped directory within .run/ for this current debug run
- It automatically records stdout to stdout.txt, stderr to stderr.txt, and a crash.txt if the game crashes, in the directory for this run
- When the “take debug screenshot” function is invoked (which can be done by pressing F12), it saves a timestamped (based on time since executable launched) screenshot in the directory for this run
- Editor actions and 3D camera movements are recorded to playback.txt in the directory for this run
With all of this in place, I can do a debug build, run the game, do something in the editor, and take one or more screenshots where things went wrong. Then, Codex can see the log files and screenshots and try to diagnose the problem. When attempting to fix the problem, it can automatically recompile the debug build and rerun it with a launch option that plays back the latest recording file, which does the same sequence of editor actions/camera movements and takes screenshots at the same points in the process. Then it can compare this to the initial recorded run and see what needs to be fixed.
We could be having a GUI renaissance right now but for various primarily aesthetic reasons people are churning out TUIs, and personally I think it's a huge mistake.
Re: Strace-ui, Bonsai_term, and the TUI renaissance
#75Re: Strace-ui, Bonsai_term, and the TUI renaissance
#76I 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 ca…
It's because of AI agents. People can talk about the other benefits all they want, but this is the real reason. Agents can use TUIs natively with basic written instructions, which is why they are exploding in popularity.
Re: Strace-ui, Bonsai_term, and the TUI renaissance
#77Earlier quoted context omitted.
> 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. I might be missing something here, but wouldn't any UI toolkit that doesn't live within a WebView work?
Yes, and of those, my impression is that there are niche ones that look OK, game engines that look great but take a lot of work, and then there's just TUIs, which look retrocool and run blazing fast, and are really easy to write.
Re: Strace-ui, Bonsai_term, and the TUI renaissance
#78The 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.
Re: Strace-ui, Bonsai_term, and the TUI renaissance
#79Interesting 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://terminaltrove.com/explore/ https://github.com/rothgar/awesome-tuis But I think we will swing back to using GUIs when we find a performant way of making th…
I agree. The only reason I use TUI is because GUI are very slow with electron. The only software that is as fast as TUI is the Zed IDE. Apparently they use Rust + their own built GUI toolkit with GPU rendering. And apparently it's tightly coupled with Zed.
Re: Strace-ui, Bonsai_term, and the TUI renaissance
#80Interesting 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://terminaltrove.com/explore/ https://github.com/rothgar/awesome-tuis But I think we will swing back to using GUIs when we find a performant way of making th…
> I think mostly this renaissance is partly due to the current bloat of Electron GUIs. I think it's mostly due to the CLI being much more powerful than a full-blown IDE: when you try to make everything simple (in a menu, accessible with one mouse-click or a shortcut), then semi-advanced things (which haven't been thought of in the IDE) become impossible. They also compose way more easily with the network: it's much e…
But TUIs can't solve that either? The ability to pipe CLI commands together when using a tool non-interactively is orthogonal to what UI is used interactively.