Electron vs GPUI: What Discord's 290 MB Rust Rewrite Can and Cannot Prove
A screenshot can make a framework debate look settled. Discord's co-founder and CTO showed an early Windows build of a rewritten client using about 290 MB of memory, and suddenly the question became: was Electron the problem all along?
Not so fast. The screenshot is a real data point shared by Discord's leadership, but it is not a controlled benchmark. It does not tell us what the old client used under the same workload, which background tasks were running, or how the new build behaves during a busy voice call, screen share, or large server session. Discord has not published a repeatable performance comparison.
The news is still worth paying attention to. On November 4, 2026, Stanislav Vishnevskiy said Discord was moving its desktop client from Electron to Rust, with GPUI, the Rust UI framework developed by the Zed team. He said the company had used Rust since 2018 in infrastructure, voice technology, and parts of the existing client. He also said React Native would leave the mobile stack, while mobile would keep native interfaces and share app logic with desktop through Rust. The team hopes to put the new client into user testing soon, but no release date was announced. (Vishnevskiy's post on X)
That makes this a useful comparison, not a verdict. Electron and GPUI solve different problems. Electron makes it practical to ship desktop software with web technologies. GPUI gives a team more control over a Rust-based, GPU-accelerated interface, but it also asks that team to own more of the application stack.
The short version
- Choose Electron when a web team needs to ship a cross-platform desktop app quickly, reuse web skills and components, and rely on a mature ecosystem.
- Consider a native Rust UI such as GPUI when profiling shows that the current architecture is holding back a product, the team can support Rust and platform-specific work, and the product benefits from a more integrated native rendering stack.
- Do not choose either from one RAM screenshot. Compare equivalent builds under the same user actions, operating system, hardware, and measurement method.
- Consider Tauri separately. It uses Rust for the application backend and a system webview for HTML-based UI. It is not the same architectural choice as GPUI, and Discord's CTO explicitly said the rewrite uses GPUI, not Tauri. (Tauri architecture, Vishnevskiy's post)
Electron is a browser-shaped application platform
Electron is not simply “a website in a window.” Its process model inherits ideas from Chromium. An Electron application has a main process that manages the app lifecycle and windows, and renderer processes that display web content. Each BrowserWindow has a separate renderer. Electron's documentation explains that renderers behave much like web pages, while the main process runs in a Node.js environment and can access operating-system APIs. (Electron process model)
That architecture is a deliberate bargain. A team can use JavaScript, HTML, CSS, and its existing front-end framework to build for Windows, macOS, and Linux. The same browser technology that powers the web becomes the interface layer for a desktop product. Teams can move quickly, reuse knowledge, and build UI surfaces without requiring every contributor to understand native toolkits.
There is a cost. Chromium and Node.js are not free, and Electron applications carry a multi-process runtime. Several apps running side by side can each bring their own framework and rendering work. But that does not mean every Electron app is inherently wasteful or doomed to consume gigabytes. Electron's own performance guide emphasizes profiling the actual application, deferring expensive work, avoiding blocked processes, and reducing unnecessary dependencies. It notes that performance depends substantially on how the app is built. (Electron performance guide)
For Discord, the comparison is also not “Rust versus JavaScript” in a clean lab. The current client already contains Rust components, according to its CTO. The proposed change is about moving more of the client logic into Rust and replacing Electron's UI runtime with GPUI. The results will depend on what is moved, what remains web-based, how features are implemented, and how much work the new framework takes over.
GPUI changes the UI ownership model
GPUI is an open-source Rust UI framework created for Zed. Its project describes it as a GPU-accelerated framework with a hybrid immediate and retained rendering model. Zed's team says it built GPUI because it wanted control over the editor's interface and rendering approach. (GPUI project README, Zed 1.0 engineering post)
That direction can offer a different performance envelope. Instead of treating the product primarily as a web interface running inside a packaged browser runtime, a team can build UI and application behavior around its chosen Rust framework and native platform integrations. The potential benefits include tighter control of rendering, lower overhead for some workloads, and sharing business logic across desktop and mobile while retaining native mobile interfaces.
Those are possibilities, not automatic results. Discord's 290 MB figure comes from a single early-build screenshot. The number does not establish typical idle usage, peak usage, battery consumption, startup time across machines, memory while playing video, or stability under long sessions. Even the app state matters: the CTO said the screenshot build had two accounts open, but that still leaves many workload details unspecified. (Vishnevskiy's post on X)
There is also framework maturity to consider. GPUI's public README says the framework is in active development and pre-1.0, with breaking changes possible. Discord has said it maintains patches on top of GPUI and will consider upstreaming relevant changes. A large company can invest in a fork, employ framework specialists, and carry long-term maintenance costs that a small product team may not be able to absorb. (GPUI project README, Vishnevskiy's post on X)
That is the hidden comparison: Electron gives up some runtime efficiency in exchange for a mature web-based development model. GPUI can give the product team more control, but the team must take responsibility for a less mature and more specialized UI stack.
Electron vs GPUI, by decision axis
- Team skills: Electron fits teams with strong web engineering skills. GPUI requires meaningful Rust capability and willingness to learn the framework's UI model.
- Cross-platform consistency: Electron brings a consistent Chromium engine across supported desktop platforms. GPUI aims for a Rust-native interface, but platform behavior, accessibility, text rendering, and input details still need careful validation.
- Runtime footprint: Electron includes Chromium and Node.js components. A native Rust UI may avoid much of that browser runtime overhead. Actual app memory depends on implementation and workload, so benchmark instead of assuming.
- Development speed: Electron can reuse web components, libraries, and hiring pools. GPUI may deliver a better fit for a product with demanding interaction or rendering needs, but a rewrite adds migration and framework costs.
- Embedded web experiences: Discord's CTO said some experiences such as video and Activities will still use a native webview. A Rust rewrite does not imply that every part of the product stops using web technology. (Vishnevskiy's post on X)
- Long-term maintenance: Electron teams track Electron, Chromium, and Node.js updates. GPUI teams own more of the UI integration and may need to maintain patches. Neither route removes maintenance; it changes what the team maintains.
- Security boundaries: Electron's process model and security controls need correct configuration. Its official guidance recommends context isolation and renderer sandboxing. A native UI can reduce reliance on a browser renderer, but Rust does not eliminate bugs in networking, parsing, permissions, dependencies, or application logic. (Electron security guide, Electron sandbox guide)
Where Tauri fits, and where it does not
Tauri is an important option for teams that want to keep an HTML and JavaScript interface while using Rust for application logic and native capabilities. Its architecture uses the operating system's webview rather than shipping the same bundled browser runtime approach as Electron. That can reduce installer size, but it means behavior can vary with the webview available on each operating system. (Tauri architecture)
So the real menu is not a simple Electron-versus-Rust binary:
- Electron: bundled Chromium-based runtime with a web UI and Node.js main process.
- Tauri: web UI in a system webview, with Rust backend and message passing.
- GPUI: Rust UI framework with a more native, GPU-focused rendering approach.
Tauri may be a sensible middle ground when the team wants to reuse web UI skills and reduce runtime bundling. GPUI is a more substantial commitment to Rust as the interface layer. Discord's choice should not be misread as proof that Tauri failed. The company chose a different architecture for its own product and organizational needs.
What a fair benchmark should measure
A meaningful comparison should answer more than “how many megabytes does Task Manager show?” Before replacing a mature client, build the same test plan for old and new versions:
1. Define matching workloads. Test cold start, warm start, idle, a large server, multiple accounts, voice, video, screen sharing, and a realistic long session.
2. Use the same machine and operating system. Record hardware, OS version, display scaling, network conditions, and power mode.
3. Measure the whole application. Include child processes, helper processes, GPU use, and webview components. Do not compare one process from one architecture with a process tree from another.
4. Track more than memory. Record startup time, CPU, GPU, responsiveness during interaction, battery draw on laptops, crash rates, and update size.
5. Repeat and report distributions. One run can be noisy. Publish medians and ranges across repeated runs rather than selecting the best screenshot.
6. Check feature parity. Make sure both versions do the same work. A lightweight build that has not yet implemented every feature is not a like-for-like replacement.
7. Test accessibility and reliability. Keyboard navigation, screen readers, localization, multi-monitor behavior, and recovery after sleep matter as much as a low idle number.
8. Keep the measurements reproducible. Publish the test steps, version identifiers, and tooling so other teams can repeat the comparison.
This is the standard a framework debate needs. If a new build is faster and lighter while preserving the same feature set and reliability, that is strong evidence. A single screenshot is a promising hint, not the conclusion.
The practical verdict
Electron remains a rational choice for many desktop products. If the app's memory use is acceptable, the team ships quickly, and performance problems can be fixed through profiling and targeted optimization, a full rewrite may cost more than it returns. Electron's own guidance is to measure real bottlenecks, not optimize based on framework reputation alone. (Electron performance guide)
GPUI or another native Rust UI deserves a serious evaluation when the product has measured performance constraints, the team has Rust expertise, or the application needs a level of rendering control that its web-based architecture makes difficult. Discord has a distinctive scale, existing Rust experience, and an existing engineering investment in the language. Its decision is not a universal migration recipe.
The 290 MB screenshot is interesting because it demonstrates a real early build, not because it settles the debate. Watch for a public test, feature parity, repeated measurements, and the application's behavior under real voice, video, and multi-account use. Until then, treat the number as an early signal and keep Electron, Tauri, and GPUI in their proper architectural categories.
I write about software engineering, developer tools, and practical architecture. Subscribe if you want more source-checked comparisons and hands-on guides.
Have you shipped a desktop app with Electron, Tauri, or a native UI framework? What mattered most in your choice: team speed, runtime cost, or control over the interface?
Save the benchmark checklist for your next desktop architecture review.
Sources:
- Discord CTO Stanislav Vishnevskiy's November 4 post on X
- Electron process model documentation
- Electron performance documentation
- Electron security documentation
- Electron sandbox documentation
- Tauri architecture documentation
- GPUI project README
- Zed: Zed is 1.0
We open-sourced gpui-component, a desktop UI framework built on top of GPUI
We’ve been building gpui-component in the open — a Rust desktop framework used to build Longbridge Pro.
It is built on GPUI and includes 60+ UI components, virtualized data tables and lists, a dock layout system, Markdown and HTML rendering, charts, and a code editor with Tree-sitter and LSP support.
Why we built it
When people talk about desktop UI frameworks, the conversation often focuses on rendering widgets.
In our experience, drawing a button was rarely the difficult part.
The harder part was everything required around it to build an actual information-dense desktop application: focus handling, overlays, large datasets, persistent layouts, draggable panels, text editing, themes, and interactions that remain responsive under load.
We ran into these problems while building Longbridge Pro, a commercial desktop application. Instead of designing a component library in isolation, we gradually extracted and refined the systems we were already using in production.
That work became gpui-component.
It goes beyond a widget library, but it does not try to prescribe an application’s entire architecture. Our goal is to provide the difficult reusable parts while leaving applications room to own their design and structure.
What is included
The project currently includes more than 60 components covering forms, navigation, overlays, feedback, layout, data display, and editing.
A few parts may be especially interesting to developers building larger desktop applications:
- Virtualized data tables with fixed and resizable columns, sorting, cell selection, and support for hundreds of thousands of rows.
- Virtual lists that render only the visible range, including differently sized items.
- A code editor using a rope-backed text model, with Tree-sitter highlighting and LSP diagnostics, completion, and hover.
- A dock system with draggable tabs, nested splits, resizable panels, edge docks, freeform tiles, and serializable layouts.
- Cross-platform support for macOS, Windows, and Linux from one Rust codebase.
The framework is designed around workloads such as 120 FPS interfaces, very large tables, and files around 200K lines. These are the workloads we built and tested around, rather than a promise that every application will reach the same numbers on every machine.
Two layers instead of one
One design decision we made was to separate presentation from reusable behavior.
- gpui-component provides styled components, semantic themes, sizes, and interaction defaults.
- gpui-base provides lower-level behavior and infrastructure for teams that want to build their own visual system.
preview.redd.it
For example, an application can use the finished dock UI directly, or reuse the underlying layout model, drag-and-drop behavior, focus handling, and persistence while rendering the workspace in a completely different style.
The principle we have been working around is:
>Behavior belongs to the foundation. Presentation belongs to the application.
Technical stack
The main pieces are:
- Rust
- GPUI, the GPU-accelerated UI framework developed as part of Zed
- Tree-sitter for syntax highlighting
- LSP integration for editor diagnostics, completion, and hover
- A rope-backed text model for working with large documents
- Serde-compatible state for serializing dock layouts
- WebAssembly for interactive documentation previews
A minimal setup currently looks like this:
1. gpui = { git = "https://github.com/zed-industries/zed" }
2. gpui_platform = { git = "https://github.com/zed-industries/zed", features = ["font-kit"] }
3. gpui-component = { git = "https://github.com/longbridge/gpui-component" }
There are still rough edges, and we would rather hear about them than pretend the framework is finished.Questions, criticism, issues, and small test projects are all welcome.
2 points · 1 comment
Mentions
Electron vs GPUI: What Discord's 290 MB Rust Rewrite Can and Cannot Prove A screenshot can make a framework debate look settled. Discord's co-founder and CTO showed an early Windows build of a rewritten client using about 290 MB of memory, and suddenly the question became: was Electron the problem all along? Not so fast. The screenshot is a real data point shared by Discord's leadership, but it is not a controlled benchmark. It does not tell us what the old client used under the same workload, which background tasks were running, or how the new build behaves during a busy voice call, screen share, or large server session. Discord has not published a repeatable performance comparison. The news is still worth paying attention to. On November 4, 2026, Stanislav Vishnevskiy said Discord was moving its desktop client from Electron to Rust, with GPUI, the Rust UI framework developed by the Zed team. He said the company had used Rust since 2018 in infrastructure, voice technology, and parts of the existing client. He also said React Native would leave the mobile stack, while mobile would keep native interfaces and share app logic with desktop through Rust. The team hopes to put the new client into user testing soon, but no release date was announced. (Vishnevskiy's post on X) That makes this a useful comparison, not a verdict. Electron and GPUI solve different problems. Electron makes it practical to ship desktop software with web technologies. GPUI gives a team more control over a Rust-based, GPU-accelerated interface, but it also asks that team to own more of the application stack. The short version - Choose Electron when a web team needs to ship a cross-platform desktop app quickly, reuse web skills and components, and rely on a mature ecosystem. - Consider a native Rust UI such as GPUI when profiling shows that the current architecture is holding back a product, the team can support Rust and platform-specific work, and the product benefits from a more integrated native rendering stack. - Do not choose either from one RAM screenshot. Compare equivalent builds under the same user actions, operating system, hardware, and measurement method. - Consider Tauri separately. It uses Rust for the application backend and a system webview for HTML-based UI. It is not the same architectural choice as GPUI, and Discord's CTO explicitly said the rewrite uses GPUI, not Tauri. (Tauri architecture, Vishnevskiy's post) Electron is a browser-shaped application platform Electron is not simply “a website in a window.” Its process model inherits ideas from Chromium. An Electron application has a main process that manages the app lifecycle and windows, and renderer processes that display web content. Each BrowserWindow has a separate renderer. Electron's documentation explains that renderers behave much like web pages, while the main process runs in a Node.js environment and can access operating-system APIs. (Electron process model) That architecture is a deliberate bargain. A team can use JavaScript, HTML, CSS, and its existing front-end framework to build for Windows, macOS, and Linux. The same browser technology that powers the web becomes the interface layer for a desktop product. Teams can move quickly, reuse knowledge, and build UI surfaces without requiring every contributor to understand native toolkits. There is a cost. Chromium and Node.js are not free, and Electron applications carry a multi-process runtime. Several apps running side by side can each bring their own framework and rendering work. But that does not mean every Electron app is inherently wasteful or doomed to consume gigabytes. Electron's own performance guide emphasizes profiling the actual application, deferring expensive work, avoiding blocked processes, and reducing unnecessary dependencies. It notes that performance depends substantially on how the app is built. (Electron performance guide) For Discord, the comparison is also not “Rust versus JavaScript” in a clean lab. The current client already contains Rust components, according to its CTO. The proposed change is about moving more of the client logic into Rust and replacing Electron's UI runtime with GPUI. The results will depend on what is moved, what remains web-based, how features are implemented, and how much work the new framework takes over. GPUI changes the UI ownership model GPUI is an open-source Rust UI framework created for Zed. Its project describes it as a GPU-accelerated framework with a hybrid immediate and retained rendering model. Zed's team says it built GPUI because it wanted control over the editor's interface and rendering approach. (GPUI project README, Zed 1.0 engineering post) That direction can offer a different performance envelope. Instead of treating the product primarily as a web interface running inside a packaged browser runtime, a team can build UI and application behavior around its chosen Rust framework and native platform integrations. The potential benefits include tighter control of rendering, lower overhead for some workloads, and sharing business logic across desktop and mobile while retaining native mobile interfaces. Those are possibilities, not automatic results. Discord's 290 MB figure comes from a single early-build screenshot. The number does not establish typical idle usage, peak usage, battery consumption, startup time across machines, memory while playing video, or stability under long sessions. Even the app state matters: the CTO said the screenshot build had two accounts open, but that still leaves many workload details unspecified. (Vishnevskiy's post on X) There is also framework maturity to consider. GPUI's public README says the framework is in active development and pre-1.0, with breaking changes possible. Discord has said it maintains patches on top of GPUI and will consider upstreaming relevant changes. A large company can invest in a fork, employ framework specialists, and carry long-term maintenance costs that a small product team may not be able to absorb. (GPUI project README, Vishnevskiy's post on X) That is the hidden comparison: Electron gives up some runtime efficiency in exchange for a mature web-based development model. GPUI can give the product team more control, but the team must take responsibility for a less mature and more specialized UI stack. Electron vs GPUI, by decision axis - Team skills: Electron fits teams with strong web engineering skills. GPUI requires meaningful Rust capability and willingness to learn the framework's UI model. - Cross-platform consistency: Electron brings a consistent Chromium engine across supported desktop platforms. GPUI aims for a Rust-native interface, but platform behavior, accessibility, text rendering, and input details still need careful validation. - Runtime footprint: Electron includes Chromium and Node.js components. A native Rust UI may avoid much of that browser runtime overhead. Actual app memory depends on implementation and workload, so benchmark instead of assuming. - Development speed: Electron can reuse web components, libraries, and hiring pools. GPUI may deliver a better fit for a product with demanding interaction or rendering needs, but a rewrite adds migration and framework costs. - Embedded web experiences: Discord's CTO said some experiences such as video and Activities will still use a native webview. A Rust rewrite does not imply that every part of the product stops using web technology. (Vishnevskiy's post on X) - Long-term maintenance: Electron teams track Electron, Chromium, and Node.js updates. GPUI teams own more of the UI integration and may need to maintain patches. Neither route removes maintenance; it changes what the team maintains. - Security boundaries: Electron's process model and security controls need correct configuration. Its official guidance recommends context isolation and renderer sandboxing. A native UI can reduce reliance on a browser renderer, but Rust does not eliminate bugs in networking, parsing, permissions, dependencies, or application logic. (Electron security guide, Electron sandbox guide) Where Tauri fits, and where it does not Tauri is an important option for teams that want to keep an HTML and JavaScript interface while using Rust for application logic and native capabilities. Its architecture uses the operating system's webview rather than shipping the same bundled browser runtime approach as Electron. That can reduce installer size, but it means behavior can vary with the webview available on each operating system. (Tauri architecture) So the real menu is not a simple Electron-versus-Rust binary: - Electron: bundled Chromium-based runtime with a web UI and Node.js main process. - Tauri: web UI in a system webview, with Rust backend and message passing. - GPUI: Rust UI framework with a more native, GPU-focused rendering approach. Tauri may be a sensible middle ground when the team wants to reuse web UI skills and reduce runtime bundling. GPUI is a more substantial commitment to Rust as the interface layer. Discord's choice should not be misread as proof that Tauri failed. The company chose a different architecture for its own product and organizational needs. What a fair benchmark should measure A meaningful comparison should answer more than “how many megabytes does Task Manager show?” Before replacing a mature client, build the same test plan for old and new versions: 1. Define matching workloads. Test cold start, warm start, idle, a large server, multiple accounts, voice, video, screen sharing, and a realistic long session. 2. Use the same machine and operating system. Record hardware, OS version, display scaling, network conditions, and power mode. 3. Measure the whole application. Include child processes, helper processes, GPU use, and webview components. Do not compare one process from one architecture with a process tree from another. 4. Track more than memory. Record startup time, CPU, GPU, responsiveness during interaction, battery draw on laptops, crash rates, and update size. 5. Repeat and report distributions. One run can be noisy. Publish medians and ranges across repeated runs rather than selecting the best screenshot. 6. Check feature parity. Make sure both versions do the same work. A lightweight build that has not yet implemented every feature is not a like-for-like replacement. 7. Test accessibility and reliability. Keyboard navigation, screen readers, localization, multi-monitor behavior, and recovery after sleep matter as much as a low idle number. 8. Keep the measurements reproducible. Publish the test steps, version identifiers, and tooling so other teams can repeat the comparison. This is the standard a framework debate needs. If a new build is faster and lighter while preserving the same feature set and reliability, that is strong evidence. A single screenshot is a promising hint, not the conclusion. The practical verdict Electron remains a rational choice for many desktop products. If the app's memory use is acceptable, the team ships quickly, and performance problems can be fixed through profiling and targeted optimization, a full rewrite may cost more than it returns. Electron's own guidance is to measure real bottlenecks, not optimize based on framework reputation alone. (Electron performance guide) GPUI or another native Rust UI deserves a serious evaluation when the product has measured performance constraints, the team has Rust expertise, or the application needs a level of rendering control that its web-based architecture makes difficult. Discord has a distinctive scale, existing Rust experience, and an existing engineering investment in the language. Its decision is not a universal migration recipe. The 290 MB screenshot is interesting because it demonstrates a real early build, not because it settles the debate. Watch for a public test, feature parity, repeated measurements, and the application's behavior under real voice, video, and multi-account use. Until then, treat the number as an early signal and keep Electron, Tauri, and GPUI in their proper architectural categories. I write about software engineering, developer tools, and practical architecture. Subscribe if you want more source-checked comparisons and hands-on guides. Have you shipped a desktop app with Electron, Tauri, or a native UI framework? What mattered most in your choice: team speed, runtime cost, or control over the interface? Save the benchmark checklist for your next desktop architecture review. Sources: - Discord CTO Stanislav Vishnevskiy's November 4 post on X - Electron process model documentation - Electron performance documentation - Electron security documentation - Electron sandbox documentation - Tauri architecture documentation - GPUI project README - Zed: Zed is 1.0
GPUI has a single-paragraph accessibility section in their guide that defers to AccessKit[1] for everything, and points to a raw RS file for more info.[2] I haven’t tested it or written anything using GPUI, but I’d expect it to be considerably harder work, based on the maturity of the web stack in this area. My assumptions have definitely been proven wrong before though… Anyone from Discord working on accessibility want to chime in? [1] accesskit.dev [2] github.com/zed-industries/zed/blob/main/crates/gp…
Meanwhile Zed isn't really usable on machines without a GPU e.g. VDIs zed#17212 I don't know if we have a winner here.
コードエディタ Zed のハーネス思想↓ 最新の AI を信頼して、細かくルールで制御することを徹底排除 代わりに、「よく起きる失敗」だけを列挙させてる zed-industries/zed
To be clear, GPUI Kit is not the same as GPUI. I am not sure if Discord is using GPUI Kit, but accessibility natively is possible with either. It's reasonable to be concerned that Discord may not have focused on accessibility while rewriting. It's less reasonable to be concerned that it may be impossible to write accessible apps using GPUI, as that is now possible (github.com/zed-industries/zed/blob/main/crates/gp…) although this is a fairly recent addition. It's also less reasonable to assume that an app made with GPUI Kit will automatically be accessible. You still need to put effort into it.
AI が書いたコードの「なぜ」をコミット後に聞ける：Zed Delta で差分と会話を一緒に残す AI エージェントに直させたコードを後から読み返すと、なぜそう書いたのかは差分から推理するしかありません。 Zed エディタの開発元が出しているアプリ Delta（public beta）で、コミットの後に新しいセッションを開き、同じ会話の経緯を聞きました。新しいセッションは担当を分けて答えました。最初の実装とコミットは端末の Claude Code、コメントを受けた修正は Delta アプリの中のエージェントという答えです。 AI エージェントにコードを書かせている人向けで、試すならアプリと plugin を入れ、練習用のリポジトリで /delta setup を打ちます。 ! この記事の内容は動画でも解説しています。差分の行へのコメントを送ると、直したのはアプリの中のエージェントで、端末の Claude Code は動きませんでした。そう分かる場面を 6:44 から見られます（約11分）。 「なぜ」に、誰が何をしたかの3段で答えた Delta はエディタとは別のアプリで、AI エージェントと会話しながらコードを書いてもらう場所です。会話と、エージェントが触るファイルの作業用コピー、端末の出力を、スレッド（英語では thread）という単位で持ちます。アプリの中にもエージェントがいて、外からは plugin で Claude Code をつなげます。Delta は特定の AI の専用品ではなく、今回は一例として Claude Code で試しました。記録を担う DeltaDB を、公式サイトは次のように紹介しています。 The version control system that records every edit with the conversation behind it. （すべての編集を、その背後にある会話と一緒に記録するバージョン管理システム） 小さな店のページ（HTML・JS・CSS の4ファイル）で、次の順に頼みました。 順 頼んだ文 打った場所 動いたエージェント 1 お品書きに秋の季節限定を3品足して。限定の品には札を付けて、上のお知らせでも知らせて。コミットはまだしないで 端末 最初の Claude Code 2 札の色はお店の緑（--zunda）にそろえて Delta アプリの差分の行へのコメント アプリの中のエージェント 3 Delta のコメントを見て直して 端末 最初の Claude Code 4 ブランチを切ってコミットして 端末 最初の Claude Code 5 この札のところ、どういう経緯で今の形になったの？ 新しい端末で /delta join した後 開き直した Claude Code（別のセッション） 5番の答えを Delta アプリで開いた画面です。 答えたのは開き直した Claude Code で、「私」は最初の Claude Code の作業を指します。「Delta 側のエージェント」はアプリの中のエージェント、○○ はコメントを書いた人の名前を伏せた所です 開き直した Claude Code は別のセッションですが、スレッドの会話を文脈に持ち、最初の Claude Code の作業を「私」と呼んで答えました。各段は、実際の変更と合っていました。頼んでいない「秋限定」の文言と橙色を最初の Claude Code が決めたことも、答えに入っています。コメントが札ではなくお知らせの帯の行（style.css の35行目）に付いていたことや、直したのがアプリの中のエージェントだったことも分けて述べました。 Claude Code だけでも前の会話に戻って聞けますが、その記録はその機械の中にあります。Delta では、別のエージェントの直しも同じスレッドに入り、問答の続きが差分の横に並びます。 ただし、差分の行からその行を生んだ会話へ飛ぶ操作はありません。行の右クリックに出るのは Comment や Copy Link to This Position などで、差分と会話は並べて見る形です。 答えの全文（アプリの画面に続く「今の札」「気になる点」まで）「秋限定」の札は、3つの段階を経て今の形になりました。 1. 最初の実装（私） 「限定の品には札を付けて」という依頼を受けて、次のように作りました。 - menu.js: 限定の3品に limited: true という印を付けました。 - main.js: この印がある品だけ、品名の横に <span class="menu-tag">秋限定</span> を足すようにしました。「秋限定」という文言は私が決めたものです。 - style.css: 札の色は、秋らしさを出すために濃い橙色（#d84315）にしました。この色は --autumn という変数に入れ、お知らせの帯にも同じ色を使いました。 2. （名前）さんのコメントを受けた修正（Delta 側のエージェント） 「札の色はお店の緑（--zunda）にそろえて」というコメントが付きました。このコメントは、メニューの札の行ではなく、style.css 35行目のお知らせの帯の行に付いていました。そこで Delta 側のエージェントは、両方の意味に取って次のように直しました。 - メニューの札は --zunda にしました。 - お知らせの帯は --zunda-dark にしました。ヘッダーの背景がもともと --zunda なので、同じ色にすると帯が見えなくなるためです。 - 使わなくなった --autumn は消しました。 3. 確認とコミット（私） 「Delta のコメントを見て直して」と言われて確認すると、修正はもう入っていたので、私は何も変えていません。そのあと autumn-limited-menu ブランチに f4cc2fe としてコミットしました。 今の札 緑（--zunda）の地に白い文字で、小さめ（0.75rem）の「秋限定」と出ます。 気になる点 - 文言が固定: 「秋限定」は main.js に直接書いています。冬の限定品を出すときは、ここを書き換える必要があります。品ごとに札の文言を menu.js 側で持たせることもできます。 - 読みにくいかもしれない: 計算すると、白い文字と --zunda の明るさの差は約2.5:1 です。文字も小さいので、読みにくい可能性があります。--zunda-dark にすれば読みやすくなります。ブラウザでの見た目はまだ確認していません。 どちらか直したい点があれば言ってください。 手元で試す アプリと plugin を入れる アプリは delta.dev から入れ、Zed のアカウントでサインインします。対応するのは macOS 13 以降の Apple Silicon・Linux・Windows です。plugin は Claude Code 2.1.303 以降と Delta 0.22.0 以降で動きます。Delta はリモートでリポジトリを見分けるので、リモートの付いた練習リポをクローンして進めます。 git clone zun-tools/delta-sample cd delta-sample claude plugin marketplace add zed-industries/delta-claude claude plugin install delta@zed-industries 一人で使う Personal プランは $0 です。私は Personal のまま、Anthropic の API キーをアプリに入れました。入れる場所は初回画面の「Choose another LLM provider」です。端末の Claude Code はこのキーを使わず、コメントで直すときのアプリの中のエージェントが使います。キーはアカウント設定に保存されて端末間で同期されるので、専用のキーに上限を付けておくと安心です。Claude のサブスクでのサインインは、まだ Coming soon の表記です。 確認環境と、試していないこと 2026-10-30、Mac 1台。Delta 0.23.0・plugin delta@zed-industries 0.1.29（beta）・Claude Code 2.1.312。公式の記述は 2026-11-02 に確かめました 手順は各1回です。Claude Code は auto mode（許可を聞かずに進む）で動かしました。自分のリポジトリで同じようにするなら慎重に この版の画面の案内はハイフン付きの /delta-setup・/delta-join です。公式の表記どおり空白で打っても動きました 試していないこと: Linux と Windows、スレッドの共有とチームでの作業、別の機械で続けること、push とプルリク Edit > Revert Conversation to Cursor は実行していません。説明では会話とファイルが一緒に戻る機能で、確認の画面が出るところまで見ました 「試した後に片付ける」の節は公式の説明と claude plugin --help から書いたもので、実行していません ファイルから会話を探す delta thread search --edited-path は、plugin 経由の編集では空でした Delta も plugin も beta で、正式版の日付は出ていません。画面や動きは変わる可能性があります /delta setup で Private sync を選ぶ setup を済ませると、会話と未コミットの変更を含むコードが Delta のサーバーに保存されます。最初は練習リポで試してください。 リポジトリで Claude Code を起動し、次を打ちます。 /delta setup チームを聞かれたら Skip で進みます Private sync (every new session, only you see it until you share)（新しいセッションを全部同期し、共有するまで自分だけに見える）を選びます Your new setting starts with your next session. Sync this session privately too?（新しい設定は次のセッションから。このセッションも非公開で同期するか）と聞かれます。この記事の手順では Not now です /exit して起動し直します 画面の一番下の行が Delta · Not syncing から Delta · Syncing に変われば、同期が始まっています。plugin を入れただけでは Delta · Not set up のままです。 plugin はユーザー単位で入りますが、Private sync の設定は setup したリポジトリの .delta/settings.json に保存されます。setup していないリポジトリの動きは Manual と同じで、/delta share を打つまで同期されません。 頼んで、差分を会話の横に出す 起動し直した Claude Code に頼みます。 お品書きに秋の季節限定を3品足して。限定の品には札を付けて、上のお知らせでも知らせて。コミットはまだしないで この先の --autumn・35行目・+32 などは今回生成されたコードの値で、手元では変わることがあります。 Delta アプリの左の一覧からこのスレッドを開き、File > Review Changes を選びます。会話の右に Changes の欄が開き、変更したファイルの差分が並びます。私の環境では、はじめの比べる相手は origin/main でした。差分の上の Since … を押すと切り替えられます。 比べる相手 出るもの origin/main など 上流のブランチとの分かれ目からの変更 Last Commit まだコミットしていない変更 Last Turn エージェントの最後のターンが始まってからの編集 Last Commit に出るのは、最後のコミットの中身ではなく、そこから先のまだコミットしていない変更です。頼んだ直後は、origin/main でも Last Commit でも4ファイル +32 でした。 差分の行にコメントして直させる 差分から札の色を決めている行を探します。今回の生成コードでは .menu-tag の background の行でした。そのコードを選んで次の文を打ち、Cmd+Enter で送ります。 札の色はお店の緑（--zunda）にそろえて コメントが付いているのは .notice-season（お知らせの帯）の行です 私が選んだのは札の行ではなく、お知らせの帯の行でした。そのまま送ると、動いたのはアプリの中のエージェントです。 札は緑に、帯はヘッダーに溶けないよう濃い緑に。ずれた行の意味まで汲んだ返信です API キーの利用分がかかりました: この直しは、アプリに入れた Anthropic のキーで動きました 端末の Claude Code は動きませんでした: コメントと直しは、端末に同期で表示されただけです。端末で「Delta のコメントを見て直して」と頼むと、修正はもう入っていて何も直していない、と答えました コミットして、開き直して聞く 端末の Claude Code に「ブランチを切ってコミットして」と頼むと、次のコミットができました。 $ git log --oneline -1 f4cc2fe (HEAD -> autumn-limited-menu) 秋の季節限定メニューを3品追加 スレッドにコミットの項目は出ず、会話がそのまま続きました。比べる相手が Last Commit だと +0 の No changes に、origin/main だと4ファイル +31 になります。+32 から1行減ったのは、コメントの直しで --autumn の定義の行が消えたためです。 新しい端末で Claude Code を起動し、スレッドの ID を渡します。ID は、最初の Claude Code の一番下の行に出ているリンクの末尾にある thread_… です。 /delta join thread_… Moving to a new directory と聞かれたら Yes, move here を選びます。Delta が用意した作業用コピーへ移り、次の行が出ました。 Continuing a Delta thread: 18 earlier items are in Claude's context but not shown here. 前の18件は Claude の文脈に入っていて、ここには表示していない、という意味です。公式の説明でも、元の複製ではなく新しいセッションです（"It's a new Claude session, not a copy of the original one."）。スレッドの会話を文脈に持つ別のセッションに、次の文で聞きます。 この札のところ、どういう経緯で今の形になったの？ 答えは最初の節の画面のとおりで、この問答も同じスレッドの続きになります。アプリでは origin/main との差分の横に並びました。 試した後に片付ける やりたいこと 方法 同期を止める /delta setup で Manual を選び直す（新しいセッションから効きます） plugin を外す claude plugin uninstall delta@zed-industries API キーを外す アプリの Settings > LLM Providers スレッドを手元から消す 一覧の右クリックの Delete Locally。サーバーの履歴は消えません サーバーの記録を消す スレッドの内容の相談もアカウントごとの削除も、privacy@zed.dev へのメールです 記録の形と置き場 コミットの間を、会話ごと埋める 図の「粒」は、Delta の用語で delta です DeltaDB は編集・メッセージ・コメントを、delta として順に記録します。 Unlike a git commit, a delta is created continuously as work happens. （Git のコミットと違い、delta は作業のたびに作られる） コミットは Git に残り（"Commits stay in Git."）、ブランチもリモートも Git のままです。 何がどこに置かれるか リポジトリの中は手元で確かめた結果で、手元の写しとサーバーは公式ドキュメントの説明です。 置き場 中身 リポジトリの中 .delta/settings.json。スレッドを開くと .delta/clones/ と .delta/worktrees/ も増えました。どれも .git/info/exclude に入り、コミットに混ざりません 手元 暗号化されたキャッシュに置かれる、記録の写し Delta のサーバー コミットとファイルの中身、スレッドの delta、メタデータ。置き先は Cloudflare で、保存時に暗号化されます setup の直後はこう見えました。 $ git status --short --ignored !! .delta/ $ find .delta -maxdepth 2 .delta .delta/settings.json Private sync は「サーバーに乗らない」ではなく「自分にだけ見える」という意味です。サーバーに置いても共有にはなりません（"Storing a thread on our servers does not share it."）。学習にも使われません（"Delta does not use your code or conversations to train AI models."）。 自分のリポジトリで使うなら、秘密のファイルと送信先にも注意します。 .env のように Git が無視している未追跡のファイルは、記録も同期もされません すでに Git が追跡しているファイルは、.gitignore に足しても守られません アプリの中のエージェントを使うと、会話と引用したコードは Zed Cloud を通って選んだプロバイダへ送られます まとめ Delta は、AI エージェントが書いたコードと、それを生んだ会話をスレッドとして一緒に残します コミットの後でも /delta join で開き直して経緯を聞けて、今回は誰が何をしたかの3段で答えました 今回、アプリのコメントで動いたのはアプリの中のエージェントで、API キーの利用分がかかりました コードと会話は Private sync でも Delta のサーバーに乗るので、最初は練習リポで試します 今回は、直す場所を人が行で指し（その行はずれていました）、直す作業と経緯の説明はエージェントに任せました。あなたなら、どこまで任せますか。 動画で見たい方はこちら → youtu.be 端末の Claude Code が、コメントと直しを同期で見ていた場面から始まります。 参考リンク Delta 公式サイト DeltaDB Install Delta（動作環境） Claude Code plugin（setup・join・条件） Review & Sync Changes（比べる相手） Comments（差分へのコメント） Delta & Git（記録の対象・Git との関係） Data Storage（保存先） Privacy（学習に使わない） Models & Providers（API キー・Coming soon） 料金 zed-industries/delta-claude（plugin のリポジトリ） 練習リポ: zun-tools/delta-sample
Is there anyone at @zeddotdev that can help us approving our extension? It's been sitting there for a while extensions#8066 and users can't use our new features
We open-sourced gpui-component, a desktop UI framework built on top of GPUI We’ve been building gpui-component in the open — a Rust desktop framework used to build Longbridge Pro. It is built on GPUI and includes 60+ UI components, virtualized data tables and lists, a dock layout system, Markdown and HTML rendering, charts, and a code editor with Tree-sitter and LSP support. Why we built it When people talk about desktop UI frameworks, the conversation often focuses on rendering widgets. In our experience, drawing a button was rarely the difficult part. The harder part was everything required around it to build an actual information-dense desktop application: focus handling, overlays, large datasets, persistent layouts, draggable panels, text editing, themes, and interactions that remain responsive under load. We ran into these problems while building Longbridge Pro, a commercial desktop application. Instead of designing a component library in isolation, we gradually extracted and refined the systems we were already using in production. That work became gpui-component. It goes beyond a widget library, but it does not try to prescribe an application’s entire architecture. Our goal is to provide the difficult reusable parts while leaving applications room to own their design and structure. What is included The project currently includes more than 60 components covering forms, navigation, overlays, feedback, layout, data display, and editing. A few parts may be especially interesting to developers building larger desktop applications: - Virtualized data tables with fixed and resizable columns, sorting, cell selection, and support for hundreds of thousands of rows. - Virtual lists that render only the visible range, including differently sized items. - A code editor using a rope-backed text model, with Tree-sitter highlighting and LSP diagnostics, completion, and hover. - A dock system with draggable tabs, nested splits, resizable panels, edge docks, freeform tiles, and serializable layouts. - Cross-platform support for macOS, Windows, and Linux from one Rust codebase. The framework is designed around workloads such as 120 FPS interfaces, very large tables, and files around 200K lines. These are the workloads we built and tested around, rather than a promise that every application will reach the same numbers on every machine. Two layers instead of one One design decision we made was to separate presentation from reusable behavior. - gpui-component provides styled components, semantic themes, sizes, and interaction defaults. - gpui-base provides lower-level behavior and infrastructure for teams that want to build their own visual system. preview.redd.it For example, an application can use the finished dock UI directly, or reuse the underlying layout model, drag-and-drop behavior, focus handling, and persistence while rendering the workspace in a completely different style. The principle we have been working around is: >Behavior belongs to the foundation. Presentation belongs to the application. Technical stack The main pieces are: - Rust - GPUI, the GPU-accelerated UI framework developed as part of Zed - Tree-sitter for syntax highlighting - LSP integration for editor diagnostics, completion, and hover - A rope-backed text model for working with large documents - Serde-compatible state for serializing dock layouts - WebAssembly for interactive documentation previews A minimal setup currently looks like this: 1. gpui = { git = "https://github.com/zed-industries/zed" } 2. gpui_platform = { git = "https://github.com/zed-industries/zed", features = ["font-kit"] } 3. gpui-component = { git = "https://github.com/longbridge/gpui-component" } There are still rough edges, and we would rather hear about them than pretend the framework is finished.Questions, criticism, issues, and small test projects are all welcome.
you might enjoy learning more about this zed.dev in case it sparks new ideas ACP helps with agent interoperability and helps a lot of IDEs and ADEs integrate all the major harnesses seamlessly zed zed-industries/zed orca github.com/stablyai/orca/tree/main/src/main I haven't looked at the cli implementation but you can get very far with integrating a harness while not invoking the model directly via API
Hm, should work in GPUI, albeit I see recent reports of bugs here and there - zed#63774 - ahonn/gpui-nonactivating-ime-repro Whether it’ll work in my port, depends on: - does it work in kirahowe.github.io - would it work in gpuix-svelte? I’ll know by end of next week.