GPUI vs React vs Flutter

Someone told me a React app ran better than the same app built with GPUI. GPUI is the Rust framework behind the Zed editor. The app was an agent harness, the kind where a model streams text into a long transcript.

My first reaction was, that can't be right. JavaScript is a scripting language running inside a browser. Rust compiles to machine code and has no garbage collector. How would the browser win?

Turns out it can. For this kind of app, it sometimes has. And it's got nothing to do with JavaScript being faster than Rust. To see why, I'm going to ask one question of three stacks: React, Flutter and GPUI.

All the work for a frame has to fit inside that beat. If it fits, motion looks smooth.

If it runs long, the screen has nothing new to show. So it shows the old frame again, and you see a stutter. That's a dropped frame.

Faster screens are less forgiving. Work that was fine at 60 hertz can miss every second beat at 120.

The rest of this page is really about fitting inside that bar.

First, describe. Your code says what the UI should look like right now. In React, that's your components. In Flutter, it's build. In GPUI, it's render.

Second, lay out. Work out the size and position of every box.

Third, paint. No pixels yet, just a list of drawing commands.

Fourth, raster. Turn those commands into pixels, usually on the GPU.

Fifth, composite. Put the finished pieces together on screen.

Each verb keeps its colour for the rest of the page. And really, the stacks only differ in two ways: which thread does each verb, and what's kept from the frame before.

The main thread runs your JavaScript, then style, layout and paint. Each of those is incremental, so if one line of text changes, the engine only redoes that line.

Then there's the bit Flutter and GPUI have nothing like. A second thread, the compositor, owns scrolling and simple animations. It can make new frames from the saved tiles without asking the main thread at all.

And raster happens somewhere else again, in a separate GPU process.

So say the spinner ticks. If it's a CSS animation that only rotates, it costs your code nothing. The compositor turns it.

A new token dirties one paragraph. React re-renders that one message, the browser reuses its neighbours, and only the tiles under the change get drawn again.

Now I'm going to block the main thread. The compositor's strip keeps gliding. The other one freezes, and so does the highlight on these words.

That's the big structural difference. In Flutter and GPUI, which are up next, your code runs on every scroll frame. In the browser, it doesn't.

Dart does describe, lay out and paint on one thread. And this is the first thing that's changed recently. Since 2025, that thread is the platform's main thread. The separate UI thread is gone, on every platform.

The recorded pictures then go over to the raster thread, which turns them into pixels. The two threads overlap, so Dart can start the next frame while the last one is still being drawn.

The second change. Impeller is now the default renderer everywhere except the web, and Impeller has no raster cache. So Flutter remembers its trees and its recorded pictures, but it doesn't remember pixels. They're drawn again on every frame.

So what does a change cost here? Say the spinner ticks. Only the dirty element rebuilds. Layout stops at the nearest relayout boundary, and paint stops at the nearest repaint boundary.

Now a new token lands in a message. That message rebuilds and gets laid out again. Its neighbours aren't touched.

So Flutter sits in the middle. It remembers structure, and redoes pixels.

And it all happens on the main thread. Describe, lay out, paint, and even writing the commands for the GPU.

That sounds reckless. But the last step is tiny. GPUI only draws about eight kinds of shape, with hand-written shaders, in a few batched draw calls. One of Zed's engineers says drawing a frame takes less than a millisecond. Most of the time goes on building the tree.

So what's remembered? Your state, shaped lines of text, and an atlas of glyphs and icons. Not much else.

Now the cost. Notify is GPUI's version of set state. It marks the view dirty, and every one of its ancestors. Then the window redraws from the root, and every view renders again.

The escape hatch is the cached view. It's the closest thing GPUI has to React's memo. Wrap a view in it, and GPUI skips render, layout and paint for that view, and replays its shapes from the last frame.

But the cache is fragile. It needs a definite size, and it misses if the view moves. Watch a token wrap onto a new line. Every message above it shifts, and every one of them misses.

Scrolling's the same story. A scroll is a notify, so every scroll frame runs your code on the main thread.

For an editor, that bet pays off. Zed's editor lays out only the visible lines, by hand. For other apps, the caching is on you.

But look at where a browser frame's time actually goes. In a standard benchmark, creating a thousand table rows takes about 20 milliseconds in plain JavaScript. Less than two of those are script.

The other eighteen are the engine's own style, layout and paint, and that's native code. With React, the script takes about six.

React does fall behind when it has a lot to diff. Ten thousand rows take it twice as long as plain JavaScript.

So the language is rarely the bottleneck. The caches are. Electron's real cost is somewhere else entirely: memory and start-up time.

Watch the message grow. React's cost stays flat, because the browser's work follows the size of the change. Naive GPUI climbs, because it lays out the whole message on every frame.

And the spinner makes it worse. It forces a redraw sixty times a second, so GPUI pays the full cost even when no text arrives.

Now let's apply the fixes. First, virtualise inside the message, so only the blocks on screen get laid out.

Second, cache the finished blocks, and only parse the one that's still streaming.

Third, cache syntax highlighting, instead of running it on every frame.

Fourth, put the spinner in its own small view.

With all four, GPUI is flat and fast. None of that needed a different language. It needed the caches the browser gives React for free.

It depends what you measure. React in the browser usually wins smooth scrolling while the app is busy, and idle processor use when something's animating.

GPUI usually wins cold start, idle memory, binary size, and keystroke latency in an editor.

And for frame time while streaming, or memory in a really long session, the winner is whoever did the caching work. The browser just does more of it by default.

So, React and the browser remember almost everything. Flutter remembers trees and pictures, and splits raster off. GPUI remembers the least, on one thread.