# GPUI Kit: a Rust desktop framework that ships a styled UI system and a JavaScript extension host

> GPUI Kit layers 60+ styled components, unstyled behavior primitives and a JavaScript extension host on top of GPUI. It is built for Rust teams shipping commercial desktop apps, and it inherits GPUI's platform constraints.

**longbridge/gpui-kit** — Rust GUI components for building fantastic cross-platform desktop application by using GPUI.

- Repository: https://github.com/longbridge/gpui-kit
- Website: http://gpui-kit.com
- Stars: 15,272 · Forks: 953
- Language: Rust
- License: NOASSERTION
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/longbridge-gpui-kit

## What GPUI Kit solves, and which teams it is for

GPUI is the rendering foundation behind Zed's editor. It gives you a GPU-accelerated element tree in Rust and little else: no button, no table, no dock layout. A team starting a desktop product on GPUI writes those from scratch, and the writing is the expensive part.

GPUI Kit is that layer, extracted from a shipped product. The README states it has powered Longbridge Pro from day one and that the framework was extracted from the demands of a publicly shipped commercial application rather than designed in isolation. That provenance is the pitch: the components were not built to demo well, they were built because a trading desktop needed them.

The intended audience is narrow and specific. You are writing a native desktop application in Rust, you have already chosen GPUI (or are willing to), and you want forms, navigation, overlays, data tables, a code editor and a dock layout without assembling them yourself. The README claims 60+ UI components across forms, navigation, overlays, feedback and layout, plus virtual lists, data tables, a code editor, dock layout, Markdown and HTML rendering, and charts.

If you are building a small utility window, this is a large dependency for the job. If you are building a web app, GPUI Kit has nothing for you.

## Three crates, one dependency, and where behavior stops and styling starts

The architecture is the most interesting design decision in the project, and the README is explicit about it. There are three layers. `gpui-base` holds unstyled behavior, state and infrastructure. `gpui-component` is the complete styled UI system built on top. `gpui-shell` is a JavaScript runtime hosted by Rust, where capabilities are granted one at a time. The `gpui-kit` crate pins the matching GPUI release and re-exports GPUI, base, component and assets, so an application lists a single dependency.

The dividing line is stated as a rule: behavior belongs to the foundation, presentation belongs to the application. That means a team that wants its own visual language can depend on `gpui-base` and reuse the difficult interaction logic (focus handling, virtualized scrolling, drag behavior) while owning layout, styling and motion. A team that wants to ship faster takes `gpui-component` and keeps the application coherent with one visual and interaction system.

The README draws an analogy to the web ecosystem: GPUI maps to HTML plus Tailwind CSS, `gpui-base` maps to Base UI, and `gpui-component` maps to shadcn's styled component layer. The analogy is useful for understanding the split, though it is not a claim about code sharing.

The JavaScript layer is separate. `gpui-shell` lets a shipped Rust host load panels and business logic as scripts, with every capability granted explicitly. The README notes that JavaScript extension hosts add `gpui-shell` separately, and `gpui-component-shell` supplies the styled catalog. The examples directory backs this up with `examples/js_dock/`, `examples/js_story/` and `examples/js_todolist/`. Explicit capability grants are the right default for a host that loads third-party scripts, and the project treats it as a first-class layer rather than a plugin afterthought.

## Installing GPUI Kit and running the hello world example

GPUI Kit is published on crates.io, and the README's usage section gives the dependency line. The version in the README is `0.6`, and the workspace manifest pins the internal crates at `0.6.5`. The `gpui-kit` crate always brings in GPUI and `gpui-base`; `gpui-component` and the default icon set are on by default.

```toml
[dependencies]
gpui-kit = "0.6"
```

If you want only some layers, turn default features off. The README states that the `gpui-component` features (`inspector`, `decimal`, `tree-sitter`, and each `tree-sitter-<language>`) are available under the same names.

The basic example in the README imports the button module, the component module and the crate root, then implements `Render` for a unit struct. The listing is truncated mid-expression, so treat it as a shape rather than a complete program:

```rust
use gpui_kit::component::button::*;
use gpui_kit::component::*;
use gpui_kit::*;

pub struct HelloWorld;
impl Render for HelloWorld {
    fn render(&mut self, _: &mut Window, _: &mut Context<Self>) -> impl IntoElement {
        div()
            .v_flex()
    }
}
```

For a first real run, skip the truncated snippet. The repository has a runnable example at `examples/hello_world/`, and the workspace `Cargo.toml` lists it as a member, so from a checkout of the repository you can build and run it by package name:

```bash
cargo run -p hello_world
```

What you should see is a window rendered by GPUI with the example's content. The repository also ships `examples/ai_recipes/`, which the README calls an executable application recipe and AI-assisted development acceptance checks, described as a tested starting point with verification commands. That file is the better second stop than the README snippet, because it is meant to be run rather than read. The README does not document a rollback or downgrade procedure for the crate.

## Data tables, virtual lists and the editor: what the framework actually carries

The feature list is where GPUI Kit separates itself from a component gallery. Data tables are described as supporting virtual scrolling, fixed and resizable columns, sorting, and cell selection across hundreds of thousands of rows. Virtual lists render only the visible range, including lists whose items have different sizes. The code editor is claimed to hold stable performance at 200K lines with Tree-sitter highlighting and LSP diagnostics, completion and hover. Dock layout covers resizable panels, draggable tabs, nested splits and edge docks, and the README says the whole arrangement is serializable.

Those are the features that decide adoption, because they are the ones nobody wants to write twice. A virtualized table with variable row heights is weeks of work. A serializable dock layout that survives a restart is more. The repository structure supports the claims with `examples/dock/`, `examples/editor/`, `examples/table_in_scrollable/`, `examples/large-text/` and `examples/markdown_table/`.

The performance numbers in the README (120 FPS, 200K lines, hundreds of thousands of rows) are the project's own claims. The repository includes `crates/fps` and `examples/fps_monitor/`, so there is a way to observe frame rate yourself, but the README does not publish a benchmark methodology or the hardware behind those figures. Treat them as targets the project aims at, not as measurements you can rely on for your workload.

The `tree-sitter` feature is opt-in, and so is each `tree-sitter-<language>` feature. That matters for build time and binary size: a team that wants the editor without a dozen grammars can leave them off.

## The JavaScript extension host is the sharpest edge

`gpui-shell` embeds a JavaScript runtime in the Rust host so that a shipped application can load panels and business logic as scripts. The README frames the benefit as letting contributors extend the product without a fork or a release. That is a real benefit for a product with an ecosystem, and a real cost for a product without one.

The cost is the trust boundary. The README says every capability is granted explicitly, which is the correct design: the host decides what a script can touch rather than handing it an ambient environment. But the README does not document the capability list, the sandboxing model, or what happens when a script misbehaves. The repository contains `crates/shell/rquickjs-compat`, which tells you the runtime lineage, and the examples `examples/js_dock/`, `examples/js_story/` and `examples/js_todolist/` show the intended use. None of that substitutes for a security model written down.

If your application has no plugin story, do not add this layer. It expands the surface you have to test and the failure modes you have to reason about, in exchange for extensibility you may never use. If you do need it, the explicit-grant design is the right starting point, and the examples are where to learn the actual API surface.

## Limitations, and when GPUI Kit is the wrong tool

The platform claim needs care. The README says one Rust codebase ships to macOS, Windows and Linux. There is no mobile or web target in that list, and the repository confirms the desktop framing with a `crates/webview` crate and `examples/webview/`. If you need an Android or iOS build, this framework does not offer one; the related search terms around mobile and Android do not correspond to anything the project documents.

GPUI itself is the second constraint, and the larger one. GPUI Kit pins the matching GPUI release and re-exports it, which means your upgrade cadence is tied to a rendering library that is developed alongside an editor. A GPUI breaking change becomes a GPUI Kit change becomes your change. The project mitigates this by pinning, not by insulating you.

The third limitation is documentation depth. The README is a good map and a poor manual. It gives one truncated code sample, a dependency line, and pointers to `docs/ARCHITECTURE.md`, `crates/base/README.md`, the website and the examples. Questions a new user will actually have, such as the exact capability list for `gpui-shell` or the theme schema, are answered in files the README only links to. The repository root does contain `.theme-schema.json` and `themes/`, so theming is machine-described somewhere, but the README does not explain it.

Finally, the licence. The GitHub metadata reports NOASSERTION while the repository root contains `LICENSE-APACHE`. That is a discrepancy a company's legal review will notice, and the README does not resolve it.

Where it is the wrong tool: a small internal utility, a CLI with a window, a cross-platform app that must also run in a browser, or any team unwilling to track GPUI's release cadence.

## Alternatives: what changes if you leave GPUI

The nearest alternative in spirit is not a Rust project at all. The README itself points at shadcn and Base UI as the web analogue, and the comparison is instructive: shadcn distributes component source that you copy into your project and own, while GPUI Kit distributes crates you depend on and upgrade. If owning the source of your components matters more than upgrade convenience, the shadcn model is the one to imitate, and `gpui-base` is the closest GPUI Kit gets to it, since it hands you behavior and leaves presentation to you.

Within Rust, the meaningful alternative is building directly on GPUI with no kit at all. You get the same rendering foundation, no third layer to track, and no opinion about your component API. You also write the virtualized table, the dock layout and the editor integration yourself, which is the work GPUI Kit exists to remove. The choice is between owning that code and inheriting its release schedule.

A third path is a different Rust GUI toolkit entirely, which trades GPUI's GPU-accelerated element model for a different rendering and layout approach. That is a larger decision than a component library, and the README does not compare GPUI Kit to any of them, so the comparison has to come from your own requirements rather than from this project's documentation.

## Maintenance, upgrades and the licence question

The repository is not archived, and the last push was on 2026-09-21, the same day as the v0.6.6 release. Before that, v0.6.4 landed on 2026-09-18 and v0.6.2 on 2026-09-18. That is a rapid release cadence, which cuts both ways: fixes arrive quickly, and version numbers move under you.

The workspace manifest shows why the cadence matters. The internal crates (`gpui-kit`, `gpui-component`, `gpui-base`, `gpui-component-macros`, `gpui-kit-assets`, `gpui-fps`, `gpui-shell`, `gpui-wry`, `gpui-component-shell`) are all versioned together at `0.6.5`, and `gpui-kit` pins the matching GPUI release. A single dependency line in your `Cargo.toml` therefore controls a coordinated set of pinned versions. Upgrading is straightforward when the versions move together; it is the GPUI pin underneath that determines whether the upgrade is routine or a porting exercise.

The workspace also sets `publish = false` at the workspace level, so the internal crates are not individually published from this manifest. The README's crates.io badge and the `gpui-kit = "0.6"` dependency line indicate the umbrella crate is the published artifact.

On licensing, the repository root contains `LICENSE-APACHE`, but the GitHub metadata reports NOASSERTION and the README does not state the licence. Those two facts do not agree, and this article cannot resolve which governs. If you are shipping commercially, have someone read `LICENSE-APACHE` and confirm it is the intended licence before you depend on the crate. That is a factual gap in the project's own metadata, not a judgement about its terms.

## Conclusion

Adopt GPUI Kit if you are building a Rust desktop product and want styled components plus a JavaScript extension path without forking the framework; the repository is public and the last push was on 2026-09-21. Do not adopt it if you need a documented, permissive licence today: the GitHub metadata reports NOASSERTION, and although LICENSE-APACHE sits at the repository root, the README does not state the licence. Before committing, run cargo run -p hello_world on every platform you intend to ship, and read examples/ai_recipes/README.md for the acceptance checks the project itself names.

## FAQ

### What is GPUI Kit and what is it built on?

GPUI Kit is a Rust desktop application framework that combines a styled UI system with data, layout and editing capabilities, built on GPUI. The README describes it as layering `gpui-base` for unstyled behavior and `gpui-component` for the styled UI system underneath a single `gpui-kit` crate.

### Is GPUI Kit open source?

The repository is public and not archived, and the README links to docs.rs, crates.io and a documentation site. The GitHub metadata reports NOASSERTION for the licence while the repository root contains LICENSE-APACHE, and the README does not state which applies.

### Is GPUI Kit the UI framework that Zed uses?

GPUI Kit is built on GPUI, the rendering foundation, and pins the matching GPUI release while re-exporting it. The README positions GPUI Kit as the application layer above GPUI rather than as the rendering library itself.

### How do I install GPUI Kit in a Rust project?

Add the single dependency line `gpui-kit = "0.6"` to your Cargo.toml. The README states that this always brings in GPUI and `gpui-base`, with `gpui-component` and the default icon set enabled by default, and that you can turn default features off to keep only the layers you use.

### Can GPUI Kit build mobile or web applications?

The README states that one Rust codebase ships to macOS, Windows and Linux, and does not list a mobile or browser target. The repository contains a `crates/webview` crate and an `examples/webview/` example, but those embed web content in a desktop app rather than compiling the framework for the web.

### What does gpui-shell do in GPUI Kit?

`gpui-shell` is a JavaScript runtime hosted by Rust that lets a shipped application load panels and business logic as scripts, with every capability granted explicitly. The README says extension hosts add `gpui-shell` separately, and `gpui-component-shell` supplies the styled catalog for that layer.

## Sources

- [Issues](https://github.com/longbridge/gpui-kit/issues)
- [longbridge/gpui-kit on GitHub](https://github.com/longbridge/gpui-kit)
- [Project website](http://gpui-kit.com)
- [README](https://github.com/longbridge/gpui-kit/blob/main/README.md)
- [Releases](https://github.com/longbridge/gpui-kit/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/longbridge-gpui-kit