A former Zed employee started a fork of GPUI and then wrote a post admitting he was becoming less sure it should exist. I read it twice.
That sentence is the whole story. A framework that people loved enough to fork, and then a quiet confession that loving it might not be enough.
GPUI powers Zed, the Rust editor from the creators of Atom and Electron. When the Zed team open-sourced the UI framework under the editor, developers treated it like a gift. Here was the thing that made Zed feel alive, in your hands.
Then it got complicated in a very ordinary way.
what gpui actually does
Here's a question people always ask: why does anyone care about a UI framework?
The pitch is simple. Electron wraps a whole Chromium and Node runtime around your app.
GPUI skips all that and paints directly to the GPU, like a game. Metal on Mac, Vulkan or WGPU elsewhere.
The numbers people keep repeating: 120 FPS, input latency around 2ms against Electron's 12ms+, and 150 to 300MB of RAM where an Electron editor sits at 650MB to a gigabyte.
Add the developer experience. Writing desktop UI in Rust used to be a war with the borrow checker.
GPUI offers React-style state and a styling API that reads like Tailwind. For people who had spent years fighting this, it looked like the end of a long argument.
the framework that made native feel possible again.
That is a lot of hope to put in a renderer.
the pause
What actually happens when a company open-sources the guts of its product is predictable. The community assumes the framework has a roadmap. The company assumes the community knows it is really about the editor.
In 2026, Zed paused GPUI development for non-Zed use cases. Features that did not help the editor got closed.
Custom shaders. Community pull requests. The work that only existed to make other people's apps better.
It was not sabotage. It was focus. Zed is a business, and the framework is a tool inside it.
I get the decision. I have watched teams drown trying to serve their product and their platform at once. Saying no to outside requests is how a small company survives.
But the community had already built plans on it. And the closure notices stung because the requesters had been told, implicitly, that this thing was for them.
the fork that admits doubt
I used to think a fork solved this. Take the code, add a maintainer, done.
The gpui-ce project, the Community Edition, was started by a former Zed employee specifically to strip the editor bias out and ship stable releases. It sounded like the obvious fix.
Then he wrote that he was "becoming somewhat more" skeptical of it. Community members on Hacker News pointed out the same thing: the fork had very little merged activity after it launched.
The fork asked the question the original avoided. Who maintains this, and why?
Nobody wants to hear that the fix is also tired.
A Discord server full of Rust developers spent a week arguing about whether gpui-ce counted as a real project or just a bookmark. That argument is the ecosystem in miniature.
the ecosystem that grew around the gap
Most tutorials tell you to just use GPUI directly. The honest advice is don't.
Vanilla GPUI has thin documentation and a moving API. A crate that works today can break on the next Zed release, because the framework lives inside the editor's monorepo and changes for the editor's reasons. One of the loudest complaints: the gpui_platform split shipped to shave minutes off Zed's own compile times, not to help outside developers.
So the community built layers.
- gpui-ce, to freeze the core
- gpui-component and GPUI Kit, giving 75+ ready components with Shadcn-style syntax
- a GPUI Fork Map, tracking how the public API drifts across derivatives so your Cargo.toml stops surprising you
The Fork Map is the telling one. Rather than one framework, people now compare API surface across a half-dozen derivatives just to know if their app still builds. When the ecosystem needs a map, it is a forest.
Accessibility changed too. For years the loudest knock was zero screen-reader support.
Community layers now bundle AccessKit, which pipes a real accessibility tree into the platform readers. I did not expect that gap to close this fast.
| Electron | GPUI native | |
|---|---|---|
| Memory at idle | 650MB+ | 150-300MB |
| Input latency | 12ms+ | ~2ms |
| Ecosystem | Mature | Fragmented |
| Accessibility | Built in | Via community forks |
The table looks like a win. It is also why people keep getting burned.
the redis app that worked
The counterexample matters. Some apps shipped and felt great.
Redis and database clients built on GPUI run fast and look sharp. Hobbyists hacked it onto iOS and Android just to see if it would go.
And the Syntax podcast, whose hosts are not shy about hype, titled an episode "I'm Using GPUI For Everything." That is the level of enthusiasm the framework earned.
That is the strange part of this whole thing. The evidence that GPUI works is real. The evidence that GPUI is safe to build on is the part that keeps slipping.
I have watched a lot of frameworks live and die this way. The technology is almost never the problem. The maintenance promise is.
I hit this myself. I spent a weekend building a small log viewer on GPUI, and by Sunday it was beautiful. Smooth, quiet, barely a flicker.
Then the upstream repo moved and my pinned commit drifted. Every fix I patched in was a fix I would re-apply next month.
I shipped my viewer on Iced instead. It felt worse and took half the time.
the honest part
Most people should not build a product on GPUI right now.
And i mean that plainly, because the hype is loud and the disappointment is quiet. The loud posts are the cool demos. The quiet ones are the people who shipped too early and got stuck maintaining a fork of a fork.
If you are making an internal tool, a dashboard, or a fast dev utility, and you enjoy Rust, it is genuinely fun. The performance is not hype. Your app will feel good.
If you need a stable API, real documentation, working IME and accessibility without forks, and a framework that does not break every six weeks, use Iced, Slint, Dioxus, or just ship Tauri and move on. Nobody on Hacker News will call you a coward. They are all saying the same thing.
The loudest misconception is that open source means cared for. Zed open-sourced GPUI, and Zed still gets to decide where its engineers spend their time. Those are different things, and the gap between them is where every disappointed fork lives.
what i keep coming back to
Zed built something beautiful and then chose its own product over the community around it. Both of those are reasonable. That is what makes it sting.
The framework that was supposed to kill Electron is alive and fast. It just belongs to an editor, and it always did.
i keep the gpui-ce tab open. I am not sure i should.
Top comments (0)