strace-ui, Bonsai_term과 터미널 UI의 르네상스

strace-ui, Bonsai_term, and the TUI renaissance May 26, 2026 | 10 min read Share on Facebook Share on Twitter Share on LinkedIn By: James Somers We’ve always found strace useful but somewhat hard to work with. Its output is often inscrutable, it’s hard to follow subprocesses or threads, and if you want to filter syscalls you have to rerun the trace with a flag for each one. What you want in debugging is a tool for exploring, refining, etc., but strace can make this difficult. Enter strace-ui, which turns strace into an interactive terminal UI: strace-ui assigns short IDs to PIDs to make them easier to scan, formats structs, and renders buffers as hexdumps instead of strings. It has some other nice features that you can’t see in the screenshot: Interactive filtering. Tracing an async OCaml process? Did you forget to pass -e '!futex,timerfd_settime,epoll_wait' ? Don’t worry: press h to hide any syscall you don’t care about. Trace a particular file-descriptor. Press > or < to jump to the next/previous syscall that referenced the same file descriptor, or press F to change your filter to only include syscalls that touch a given FD. (it’s slightly smarter than just numeric FD filtering: strace-ui tries to track FD re-use and follow across forks, but it doesn’t do a great job of that if you attach to a process that’s already opened FDs.) What even is rt_sigprocmask ? Press m to open the man page and find out. Subprocesses or threads are assigned short numeric labels, instead of showing you the raw pid, making it easier to follow a complex strace -f calls. (You can also filter by PID or exclude PIDs.) DNS resolution: strace’s --decode-fds=all will print file descriptors as 14<TCP:[55.55.555.555:12345->11.11.11.11:56789]>, which is great. strace-ui goes one step further and prints 14<TCP:[a-real-hostname:12345->another-hostname:56789]> , which makes it easier to see at a glance exactly what your process is doing. Ian Henry , a dev here, made strace-ui to scratch his own itch. In 2017, he’d gone looking for such a tool but never found it. Having had experience building interactive terminal UIs (including in OCaml, using lambda_term), he knew how difficult and unpleasant it could be. The idea percolated over the years, never feeling worth it, until recently when a few forces converged to make terminal UI development actually kind of delightful. Bonsai, a powerful framework for reactive UIs For years now we’ve been building web applications with OCaml in a functional style, using a library we developed called Bonsai , loosely inspired by Elm . A simple Bonsai component with a little interactivity looks like this: module Dice = struct let faces = ... let component ( graph @ local ) = let face , set_face = Bonsai . state ( List . hd_exn faces ) graph in let % arr face and set_face in {% html | < div > You rolled a #{ face } < button style = "" on_click =%{ fun _ -> let index = Random . int ( List . length faces ) in set_face ( List . nth_exn faces index )} > Roll the dice </ button > </ div > |} end Components are implemented as purely functional state machines, and are easily composable. Incrementalization inside the framework means that values don’t get recomputed until necessary. This applies to every value, not just the view. What’s neat about Bonsai is that it allows you to compose state and incrementality primitives a la carte. The same primitives that prevent re-rendering the entire page during user interaction can also be used to incrementalize an expensive business logic computation on a live-updating dataset. (If you’re used to React, imagine if everything used something very similar to hooks, and state was managed outside of the component hierarchy.) And because Bonsai is written in OCaml, it becomes possible to use the same language and types on both the backend and frontend. It’s hard to overstate the impact this has on keeping a large web app’s codebase manageable, especially when you make pervasive use of OCaml’s type system. Bonsai is not really a web framework So far we’ve actually been talking about Bonsai_web. Bonsai itself is agnostic to the frontend, because when you think about it, all UIs can fundamentally be expressed as stateful incremental computations, in which different components know how to render themselves as their underlying data changes. If Bonsai is a library for managing the lifecycle and scoping of state, with a layer on top for expressing the particulars of a given UI surface, you can see how the same underlying core can be adapted. And that is where Bonsai_term came from. When Ty Overby made Bonsai in 2019, the idea that it’d eventually end up being used for terminal apps was a running joke. In some ways the whole point of Bonsai was that at Jane Street we felt somewhat underpowered when it came to web development. Some of our most important apps were built on the ancient and somewhat difficult curses library, which lives up to its name. Terminal apps are fast and keyboard-centric, which we like, but the web also has a lot going for it. It’s hard to beat the ergonomics of clicking a hyperlink; and of course the web gives you a vast palette for constructing UIs, including charts and graphics that aren’t practical on the command line, and integrated help (via tooltips and the like). In the years after the release of Bonsai_web there was a huge flowering of web apps, including many that were ported directly from the terminal. But here we are in 2026 and it feels like another renaissance is afoot, this time in the opposite direction. Terminal UIs experience a comeback — the Claude Code effect? Bonsai_term began as a personal hobby project in the summer of 2024, when Jose Rodriguez—one of our devs—built it to write a manga reader with the kitty graphics protocol. It showed enough promise that he later made some ncdu-style tools for wider Jane Street use. In April 2025, Bonsai_term had enough traction that we started productionizing it in earnest. It so happened that AI agents were coming onto the scene, and it was the arrival of Claude Code in February 2025 that kicked everything into gear. It became clear fairly quickly that a well-made terminal app was winning out over full-featured IDEs, in large part because of the speed, simplicity, and portability of the terminal itself. Terminal emulators are everywhere and deeply integrated into editors; TUIs met devs where they already were. In the beginning was the command line , and so it remains—ubiquitous and always at hand. We doubled down on Bonsai_term, and pretty soon a feedback loop came into being. We developed our own Claude Code–ish tool, called AIDE, (which we built to maintain the freedom to choose between different model vendors, to suit our unusual development environment, and to better control the execution sandbox), which became both a demo of Bonsai_term and a partner in creating it. While building AIDE into a full-featured agent-harness, we threw off a rich library of UI components that other apps could then take advantage of. Developers who became acquainted with this unusually good TUI were pleased to discover that they could make their own terminal apps with just as much polish thanks to the new framework it was built in. Bonsai_term would feel familiar to anyone who’d ever done web development here, and it had the huge advantage of being especially amenable to AI assistance. It was actually somewhat of a mystery to us how good the models were at writing Bonsai_term code, given how relatively obscure it is and how it relies, for example, on OxCaml -only features. (We think it might have something to do with the testing story, discussed below.) Then, recently, with the advent of Bonsai_term and AI agents, Ian found he could make a working prototype in less than ten minutes. The prototype was useful enough to justify the ongoing time spent making it real. Notice how the 'expect' block in these tests contains a rendering of the actual UI Closing the loop with screens