Work studies / Teardown
How VS Code’s terminal keeps up with a flood of output
How does a terminal in a web page stay smooth, and small, when a program prints thousands of lines a second?
VS Code’s terminal, which is built on xterm.js, stays smooth even when a program floods it with output. I’ll dig into how, then spend a week building a terminal pane that stays smooth and keeps its memory use under a hard ceiling.
- Format
- Teardown
- What I’ll build
- A terminal pane that draws on the GPU, updates the screen at most once a frame, tells a noisy program to wait instead of holding everything in memory, and still works with a screen reader.
- What I’ll reuse
- A terminal pane with a fixed memory ceiling, for an app that runs several command-line programs side by side.
- Used by
- Bezl
- Status
- Planned · Nov 2026
What I’ll look at
How xterm.js turns a stream of output into a grid of characters, and when it switches to drawing with WebGL. How it batches output so the screen only updates once a frame. How it tells the program on the other end to pause when the screen falls behind. How much history it keeps, and what that costs. And how it stays usable with a screen reader.
I’ll compare all of this with Ghostty, a native terminal whose engine can also run without a window.
My guess
I think it never draws more than once a frame, however fast output comes in, and only draws the rows you can see. Memory probably stays flat because older lines are packed tightly and dropped past a limit, and because it pushes back on the program instead of queuing everything.
How I’ll prove it
I’ll stream 100 MB of output through four panes at once and check that none of it is lost, the screen holds 60 frames a second, and memory stays under a fixed ceiling both at rest and during the burst.
An earlier test of mine lost nothing but used far more memory than it should. So the ceiling, and what pushing back does to the program, matter most.