I’m Using GPUI for Everything - CourtneyR.dev's 2nd Brain

I’m Using GPUI for Everything ![rw-book-cover](https://d34adp677peecb.cloudfront.net/static/images/article0.00998d930354.png) 🔗 **Source:** [I’m Using GPUI for Everything](https://www.youtube.com/watch?v=SdJXHYuRr48) > [!note]+ Document Notes > tags: [gpui, rust-desktop-apps, electron-alternatives, zed, developer-tools] > author: Scott Tolinsky, Wes Bos > source: Syntax (YouTube) > reference: https://www.youtube.com/watch?v=SdJXHYuRr48 > date created: 2026-09-30 08:33 > > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > # 🏷️ Title: I’m Using GPUI For Everything >  ## 🧭 Table of contents - [📝 Summary](#-summary) - [📖 Main content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning styles assessment](#-learning-styles-assessment) - [📊 Accessibility assessment](#-accessibility-assessment) - [🌍 DEIB assessment](#-deib-assessment) - [✅ Logical validity](#-logical-validity) - [🛡️ DARVO analysis](#️-darvo-analysis) - [🎯 Conclusion](#-conclusion) - [🔄 Refactor appendix](#-refactor-appendix--im-using-gpui-for-everything) ## 📝 Summary - **What happened.** Syntax published a 32:44 episode on 2026-09-30 (episode 1043 per the description) in which Scott Tolinsky explains why the show's hosts now build desktop apps with GPUI, the GPU-accelerated Rust UI framework from the Zed team, instead of Electron or Tauri. Wes Bos plays the skeptic and asks the questions: layout, extensibility, backend calls, downsides. The auto-captions write the framework as "GPUi", Tauri as "Tori", and Wes Bos as "West Boss". The description spells it GPUI, and this analysis follows the description outside quotes. - **The claim.** GPUI renders from Rust straight to the GPU with no web view and no DOM, so small desktop apps ship tiny and start fast. Scott cites a DaisyDisk update of "eight megs" as the size class to aim for (00:23:06) and says agents write GPUI code well enough that "GPUi is the way to go" for vibe-coded personal desktop software (00:31:47). - **The mechanism.** A component is a Rust struct with a `render` function. Elements are method chains (`div().flex()...`) that read like Tailwind utilities. State changes call `notify` to request a re-render, which Wes compares to Remix. A second `render once` variant covers static pieces such as badges. GPUI Kit, a component library, supplies the shadcn-style primitives, including a virtualized data table. - **Why it matters.** The episode names the concrete cost of web-view desktop apps (a bundled Chromium in Electron, inconsistent WKWebView features on macOS for Tauri) and shows one working alternative that keeps the React mental model. It also lists honest limits: no native widgets, no DOM, young ecosystem, no write-once-deploy-everywhere. - **Key stakeholders.** Scott Tolinsky and Wes Bos (hosts), the Zed team (GPUI maintainers), the GPUI Kit maintainer (Longbridge's component project per the on-air quote), the authors of the community fork the transcript renders as "GPU CE", and developers weighing Electron, Tauri, or native Rust UI. - **Risks and tradeoffs.** Every performance and size statement is anecdotal: no benchmark, no memory figure, no startup time. The hosts disclose a Zed hoodie gift (00:04:20) and a Sentry sponsorship (00:05:44), and Scott says on air that Scott is using Jev, a model from Type Safe AI, inside the File Bro app and in a GPUI testing project (00:24:34, 00:29:36). That tool is not disclosed as a relationship either way. The fork dispute is presented through one maintainer's quoted reply. - **Bottom line.** The fit is narrow and well argued: small, personal, desktop-only utilities where a 400 MB Electron footprint is the irritant. For cross-platform web reach, native-looking UI, or mature docs, the hosts themselves say GPUI is not the tool. ## 📖 Main content **The problem being solved.** The episode opens with a tour of web-view desktop stacks. Electron ships its own Chromium with each app, which gives you a known feature set and costs disk and RAM (00:01:29, 00:02:11). Tauri uses the operating system's web view, which avoids the download size but, per Scott, leaves macOS apps on WKWebView (the captions garble the name several times), which is "not featurerich" and unpredictable because the app doesn't pin a version (00:02:53). The hosts note that Electron apps often flip experimental Chromium flags; HTML-in-canvas for Remotion's video rendering is the example given (00:03:37). Scott also notes Tauri can use other web views; the critique is scoped to macOS. **What GPUI is.** Wes summarizes it accurately at 00:07:12: GPUI doesn't translate to native widgets the way some frameworks do. It is a from-scratch UI stack where text wrapping, borders, shadows, and everything else are implemented by the framework, drawn on the GPU. It runs on macOS, Linux, and Windows, with experimental web (via WebAssembly, no DOM) and mobile (Metal via WGPU on iOS) targets that Scott says he wouldn't use for production. **The programming model.** Components are structs with typed props. `render` builds a tree of element functions with chained style methods (`flex`, `flex column`, `text xl`, `text color`). Scott likes that `text color` is named for what it does; Wes agrees, noting the CSS `color` property also drives borders (00:08:42). Interaction uses listeners such as `on click`. Updating state requires an explicit `notify`, which Wes maps to Remix's manual re-render (00:10:12). Because the UI and the application logic both live in Rust, there is no RPC bridge between a front end and a back end (00:15:13). GPUI is only the UI layer, so architecture stays the developer's choice, in contrast to Electron's opinionated split. **Styling coverage, and what's unknown.** Scott has not hit walls with shadows, opacity, backgrounds, repeating backgrounds, or spring animations, and points to a rotating-SVG example in the docs (00:11:38). Two gaps surface live: the hosts find no grid layout, only flex (00:13:02), and Scott hasn't tried custom effects such as fancy borders (00:13:46). They also find examples but no reference docs. The "class bloat" of one method call per line is acknowledged; Scott says agents write it, so the verbosity matters less (00:12:20). **GPUI Kit.** The library that changed Scott's assessment. It covers accordions, alerts, dialogs, badges, carousels, combo box, command palette, inputs, pagination, popovers, and a data table with sorting and built-in virtualization (00:16:36 to 00:17:59). Scott compares it to shadcn for GPUI and treats it as the reason the framework became practical, since the alternative was building every component. **The fork dispute.** Scott inserts an aside at 00:18:44. Community members feel the Zed team adds only what Zed needs, so a fork the captions call "GPU CE" (likely GPUI-CE, verify the spelling against the repo) merges upstream and adds declarative style transitions, corner smoothing, background blur, and gradients on shadows and borders, per a Twitter user. The GPUI Kit maintainer declines to support it, partly because Kit pins a GPUI version, and argues that frameworks backed by real products (Zed for GPUI, Longbridge for the component library) sustain themselves. Scott takes no side and has only used upstream. **What Scott built.** Gendo, a dashboard of projects across Scott's Macs (the name is a caption rendering and unverified); Battle Mode, the app for the show's CSS tournament, tracked across three installs; File Bro, a Hazel-style file-automation tool that started in Electron and now does duplicate checking and deep file analysis directly in Rust; and Mr. Space, a window utility with pin-left, pin-right, and move-to-space shortcuts that uses macOS Spaces and has a GPUI settings window only (00:21:37 to 00:26:44). **Downsides named.** No native UI elements, so matching liquid glass on macOS or Windows-native looks means reimplementing them (00:27:28). No browser DOM, so AI testing needs computer-use rather than browser-use, though GPUI exposes a full accessibility tree and Scott built a Jev-driven test harness on it that needs a small GPUI patch (00:28:10, 00:29:36). Small ecosystem. No single codebase that ships to web, mobile, and desktop. Text scaling that browsers provide for free has to be built (00:26:44). **Contested or unverified.** The DaisyDisk "eight megs" and the guessed "267 megs" Electron equivalent (00:23:06) are anecdote and speculation. "It's fast" is asserted throughout without numbers. The claim that VS Code slowness is usually a third-party extension (00:02:11) is stated as experience. The sponsor-related and fork statements are quoted or self-reported. ## 🗒️ Notes #### ⏱️ [00:00:00](https://www.youtube.com/watch?v=SdJXHYuRr48&t=0) Cold open and the Electron versus Tauri setup - Scott announces a move from web-view apps to Rust desktop apps and promises code, libraries, and Scott's own apps. - Wes asks whether this is a lasting choice or a fresh enthusiasm, given Scott's past Tauri excitement. Scott's reply: let people be excited. > [!quote] [00:00:00] > Goodbye Electron. Goodbye Tori. Goodbye desktop apps using web views. #### ⏱️ [00:01:29](https://www.youtube.com/watch?v=SdJXHYuRr48&t=89) Why web-view stacks frustrate - Electron bundles Chromium per app; Tauri's pitch was Rust on the back end plus the native web view. - VS Code shows Electron can be fast; Scott says slowness there usually traces to third-party extensions (unsourced). - On macOS, WKWebView is described as thin on features and unpredictable, since the app can't pin its version. #### ⏱️ [00:03:37](https://www.youtube.com/watch?v=SdJXHYuRr48&t=217) Electron flags, and the sponsorship digression - Electron apps enable experimental features; HTML-in-canvas for Remotion-style rendering is the cited example. - Scott wears a Zed hoodie, says Zed gave it after a past episode, and says no money changed hands. - Both hosts describe unsolicited paid-promotion offers, including one quoted at $1,500 for a quote tweet (self-reported). > [!quote] [00:05:44] > We do not accept money to talk about libraries, tools, whatever. - Sponsor read: the hosts name Sentry as the exception. The description credits sentry.io/syntax; the captions render it "sentry.iosax". #### ⏱️ [00:05:44](https://www.youtube.com/watch?v=SdJXHYuRr48&t=344) What GPUI is - GPU-accelerated, cross-platform UI framework: macOS, Linux, Windows; web and mobile exist but aren't Scott's use case. - Replaces Electron's web view; is not something you'd run inside Electron. - Wes clarifies that GPUI is not a wrapper over native widgets. > [!quote] [00:07:12] > they've they've invented an entirely new way to do UI from scratch. #### ⏱️ [00:07:55](https://www.youtube.com/watch?v=SdJXHYuRr48&t=475) The render model and styling API - Declarative like React but method-based: a `div` function with `flex` and `flex column` methods. - Inline, Tailwind-like helpers (`text xl`, `text color`). - Components, props, and state map onto structs, typed fields, and a `render` function. #### ⏱️ [00:09:26](https://www.youtube.com/watch?v=SdJXHYuRr48&t=566) Counter demo, notify, and the Remix comparison - Scott narrates an on-screen counter component for audio listeners: struct, props, `render`, button `on click`, listener that increments. - State updates need an explicit call to `notify`, which Wes likens to Remix's manual update. > [!quote] [00:10:12] > when you update state into something like that, you have to run notify - `render` versus `render once` (for static items like badges) is compared with pure components and Babel macros. #### ⏱️ [00:11:38](https://www.youtube.com/watch?v=SdJXHYuRr48&t=698) CSS coverage, chaining verbosity, and the missing grid - Shadows, opacity, backgrounds, repeating backgrounds, and spring animations work in Scott's experience. - Method chaining produces long files; Scott says agents write them. - Hosts search the docs: examples exist, reference docs don't, and neither finds grid. > [!quote] [00:11:38] > This is Tailwind class bloat on steroids. #### ⏱️ [00:13:46](https://www.youtube.com/watch?v=SdJXHYuRr48&t=826) Backend calls and architecture - Wes asks how a click triggers video processing. Scott: the logic is in the same Rust program, so nothing needs to dispatch across a process boundary. - GPUI is the UI layer only; you attach it to an existing Rust app. > [!quote] [00:15:13] > you're eliminating the need for like a RPC layer there, right? #### ⏱️ [00:16:36](https://www.youtube.com/watch?v=SdJXHYuRr48&t=996) GPUI Kit - Component catalog: accordion, alert, dialog, badge, carousel, input, pagination, popover, combo box, command. - Data table with sorting and virtualization built in. Scott calls it the unlock. - Scott notes the look resembles Scott's own component set ("graffiti UI" in the captions; name unverified) and plans to port it with an agent. > [!quote] [00:17:18] > It feels very like shad CN of GPUI. #### ⏱️ [00:18:44](https://www.youtube.com/watch?v=SdJXHYuRr48&t=1124) The community fork aside - Fork tracks upstream and adds declarative transitions, corner smoothing ("squircles"), blur, and gradient shadows and borders, per a cited Twitter post. - GPUI Kit pins a GPUI version and won't support the fork. The maintainer's quoted argument: projects validated by real applications keep improving. > [!quote] [00:18:44] > community members feel like the Zed team, the team that created GPUi is only adding things to GPUi that serve them. - Scott has used only upstream GPUI and GPUI Kit and declines to judge the dispute. #### ⏱️ [00:20:54](https://www.youtube.com/watch?v=SdJXHYuRr48&t=1254) Scott's apps: Gendo and Battle Mode - A dashboard of every project on Scott's machines, with status across a MacBook Pro and Mac Mini, transfer, start, and open actions. - Battle Mode copies track versions across three installs. Plans include organizing Caddy domains. - Personal software, in Scott's words; fonts and polish are admittedly rough. #### ⏱️ [00:22:20](https://www.youtube.com/watch?v=SdJXHYuRr48&t=1340) The size and resource argument - Wes asks the why question. Scott's answer: small utilities where nobody should download something huge. - DaisyDisk updated at 8 MB, contrasted with a guessed 267 MB Electron equivalent (speculation, not measured). > [!quote] [00:23:06] > Eight megs when when's the last time you've downloaded an app that's been eight megs? - Scott is rebuilding the show's video recorder in GPUI to keep it lean. #### ⏱️ [00:24:34](https://www.youtube.com/watch?v=SdJXHYuRr48&t=1474) File Bro and Mr. Space - File Bro started in Electron and now runs duplicate detection and file analysis in Rust in-process. - Scott says Scott is already using Jev and will use it more for automation rules (vendor tool, relationship undisclosed). - Mr. Space pins windows and moves them across macOS Spaces; agents can drive it by prompt. - Only the settings window uses GPUI, showing partial adoption works. #### ⏱️ [00:26:44](https://www.youtube.com/watch?v=SdJXHYuRr48&t=1604) Downsides: scaling and non-native UI - Wes notes the settings window can't be resized the way a browser page can, so scaling must be built. - Largest downside per Scott: no native widgets, so liquid glass or Windows-native look is yours to rebuild. Scott sees that as a feature for full visual control. > [!quote] [00:27:28] > biggest downside one is the the non-native UI element. #### ⏱️ [00:28:10](https://www.youtube.com/watch?v=SdJXHYuRr48&t=1690) No DOM, but an accessibility tree - The web target renders through WebAssembly, not the real DOM. - GPUI apps expose a full accessibility tree, which Scott's Jev-driven testing project reads. > [!quote] [00:28:10] > there is a full-on accessibility tree in these apps - Ecosystem is young; GPUI Kit is the best library Scott found. Scott uses a Rust best-practices skill to keep agent output good. #### ⏱️ [00:29:36](https://www.youtube.com/watch?v=SdJXHYuRr48&t=1776) Platform lock-in and agent testing - Not a write-once, deploy-everywhere tool; you're committed to native desktop. - AI testing means computer use rather than browser use. Scott's harness needs a small GPUI patch and clicks via the accessibility tree without screenshots (early project, unverified by the transcript). > [!quote] [00:29:36] > you're pretty much locked into whatever you're doing. #### ⏱️ [00:30:18](https://www.youtube.com/watch?v=SdJXHYuRr48&t=1818) Mobile and bridges - GPUI mobile exists and is experimental; on iOS it draws through Metal via WGPU instead of converting to native controls, as React Native does. - Wes raises native-bridge needs: maps, NFC, file picker. Scott agrees bridges to Swift are possible. #### ⏱️ [00:31:47](https://www.youtube.com/watch?v=SdJXHYuRr48&t=1907) Verdict and sign-off - Scott wouldn't use GPUI for native mobile or web apps; does use it for personal desktop software. - Closing pitch to vibe coders, then a request for audience feedback. No sponsor read at the close. > [!quote] [00:31:47] > If if you're vibe coding desktop personal software, man, GPUi is the way to go if you're talking to me. ## 📚 References The transcript itself contains no links; the following come from the video description or are primary sources for named entities. - [I’m Using GPUI For Everything — Syntax](https://www.youtube.com/watch?v=SdJXHYuRr48): the source video, 32:44, uploaded 2026-09-30. - [Syntax episode 1043](https://syntax.fm/1043): the description's "all links" page. Scott says Scott will link the Rust best-practices skill and the Jev-driven GPUI testing project there (00:28:53, 00:30:18). Contents not checked here. - [Syntax newsletter](https://bit.ly/syntax_snackpack): description link; promotional, not a source for claims. - [Sentry for Syntax](https://sentry.io/syntax): the sponsor named in the description and, in garbled form, at 00:05:44. - [GPUI, inside the Zed repository](https://github.com/zed-industries/zed): primary source for the framework. The transcript gives no URL. - Tauri and Electron: the two web-view stacks compared. Primary sites: tauri.app and electronjs.org. - GPUI Kit and the Longbridge component library: the transcript's "GPUi Kit"; the quoted maintainer reply names Longbridge. Confirm the exact repository name before citing. - GPUI-CE: the captions' "GPU CE"; confirm spelling and repository. - Type Safe AI and Jev: named at 00:24:34 and 00:29:36 as a tool Scott uses. The captions write "Jev" and once "Jeff". - DaisyDisk, AeroSpace, Raycast, Hazel, Omarchy (captions: "Omargi"): third-party apps Scott names in passing. The caption spellings "Daisy Disc" and "Aerospace" are garbles of DaisyDisk and AeroSpace. - Remotion and StyleX: named at 00:03:37 and 00:04:20 as a rendering example and as an example of a library the hosts were accused of being paid to cover. ## 🗣️ Paraphrase Scott explains that Electron and Tauri both put a web view between the developer and the screen, and that each has a cost: Electron ships a whole Chromium in every app, while Tauri leans on an OS web view that Scott finds weak on macOS. GPUI removes the web view. Everything from text wrapping to shadows is drawn by the framework on the GPU, from Rust, so a settings window, a file tool, or a window manager can be a small native-feeling program without a browser inside it. The day-to-day experience borrows from the web. Components are structs with props, a render function returns a tree of elements, and style methods chain in a way that looks like Tailwind. State changes need an explicit notify call, and because the UI and the logic share a language, calls that would cross an RPC layer in Electron become ordinary function calls. GPUI Kit, a shadcn-like component library with a virtualized data table, is what makes starting a project realistic. The hosts are direct about limits. No native widgets, no DOM, no grid in what they found, thin docs, a young ecosystem, and a fork dispute that splits the community. Scott's own apps are small and personal, and Scott wouldn't choose GPUI for a web or native mobile product. For throwaway desktop utilities that agents help write, Scott calls it the best option. ## 📰 Newsletter **Small desktop tools without a browser inside.** This week Syntax looked at GPUI, the Rust UI framework behind the Zed editor, and Scott Tolinsky made the case that personal desktop utilities don't need a bundled Chromium. The pitch: React-shaped components, Tailwind-shaped styling, everything drawn on the GPU, and an 8 MB-class install. The honest part is the list of costs: no native widgets, no DOM, no grid layout in what the hosts found, and a young ecosystem. Why a WordPress reader might care: the episode is a clean example of picking a runtime for what the tool is. Playground, CLI helpers, and contributor utilities (a local environment manager, a file triager) often start life as Electron apps because that's familiar, and this episode is a prompt to ask whether the install size and memory cost earn their place. It is also a reminder that accessibility has to be designed in: GPUI exposes an accessibility tree, and the episode's closing caveats make clear that text scaling and native-widget behavior are yours to rebuild. Two disclosure notes: the hosts say they take no money to cover tools, name Sentry as their sponsor, and mention a Zed hoodie gift. Links: [the video](https://www.youtube.com/watch?v=SdJXHYuRr48), [episode page](https://syntax.fm/1043), [Zed](https://github.com/zed-industries/zed). ## ✅ Action items #### DevRel - Developer advocacy: where a demo needs a desktop companion, weigh a GPUI build against Electron and record install size and idle memory for both. The episode supplies the hypothesis (8 MB-class versus hundreds of MB) but no measurement. - Education: add a "choose your desktop runtime" comparison for devtools authors covering Electron (bundled Chromium), Tauri (OS web view, including the macOS WKWebView gaps raised at 00:02:53), and GPUI (no web view, no DOM). - Developer experience: the hosts report examples but no reference docs for GPUI (00:13:02). If Pantheon ships any Rust UI sample, publish a reference-style page, not only examples. Note the gap applies to upstream, not to our tooling. - Developer marketing: no direct action from this source; the hosts' disclosure pattern (hoodie gift, sponsor named, no paid coverage) is a usable model for community posts. - Community management: the fork dispute (00:18:44) is a live example of a maintainer refusing support for a community fork; track it as a case study, not a position. - Internal/external/cross-project: no direct action from this source; nearest relevance is pinning versions of UI libraries, since GPUI Kit pins a GPUI version. #### OSPO - Policy and governance: the fork dispute is a governance case (upstream steward versus community fork). Nothing to decide from this source; use it as a discussion example. - License compliance: no direct action from this source; GPUI and its libraries' licenses are not stated in the transcript. - Security management: no direct action from this source; the episode raises no security points. The accessibility-tree testing harness uses a GPUI patch (00:29:36), which would need review before any adoption. - Software inventory: if any internal tool moves to GPUI, record the GPUI and GPUI Kit version pair, because the Kit pins GPUI. - Developer support: no direct action from this source. - Community engagement: no direct action from this source. - Strategic alignment: no direct action from this source. #### Community - Maintainers: the quoted GPUI Kit maintainer argues projects backed by real products improve fastest (00:20:11). Worth reading as a perspective on who steers a framework. - Contributors: no direct action from this source. - Sponsors: no direct action from this source; nearest relevance is the hosts' explanation of why they reject paid coverage (00:05:44). - Ecosystem: no direct action from this source. #### WordPress - Core: no direct action from this source. The episode is about native desktop UI, not web publishing. - Core Performance: no direct action from this source; all performance claims are anecdotal. - Core AI: no direct action from this source; nearest relevance is the hosts' claim that agents write GPUI code well with a Rust best-practices skill (00:28:53), which is unmeasured. - **Core Program Team:** no direct action from this source. - Mobile: no direct action from this source. The episode calls GPUI mobile experimental, with Metal rendering on iOS. - Playground: no direct action from this source. The web target renders through WebAssembly with no DOM (00:28:10), so it isn't a Playground-style WordPress runtime. - Community: no direct action from this source. - Training: no direct action from this source. - Marketing: no direct action from this source. - Support: no direct action from this source. - Design: no direct action from this source; the episode's design point is that non-native UI trades platform consistency for full visual control (00:27:28). - Documentation: if a WordPress desktop-adjacent tool adopts any young framework, note the "examples but no reference docs" gap (00:13:02) in contributor docs. Not a requirement from this source. - Photos: no direct action from this source. - TV: no direct action from this source. - Polyglots: no direct action from this source. - Accessibility: the transcript says GPUI exposes an accessibility tree (00:28:10) and that text resizing is not free (00:26:44). Any WordPress-adjacent desktop tool built this way would need its own WCAG 1.4.4 and 4.1.2 check. - Meta: no direct action from this source. - CLI: no direct action from this source. - Hosting: no direct action from this source. - Tide: no direct action from this source. - Openverse: no direct action from this source. - Themes: no direct action from this source. - Plugins: no direct action from this source. #### The WPOCC - Programs: no direct action from this source. - Projects: no direct action from this source. - Funding experiments: no direct action from this source; the fork discussion touches framework sustainability but names no funding model. ### FAIR - Technical independence: no direct action from this source. The fork dispute concerns who controls a framework's direction. - Policies and covenants: no direct action from this source. - Productized governance artifacts: no direct action from this source. ## 🧪 Hypotheses 1. A GPUI build of a small desktop utility installs at under 25 MB, while an equivalent Electron build exceeds 150 MB, on macOS. 2. Idle memory for the GPUI build is under one third of the Electron equivalent after 10 minutes with the window open. 3. Agents produce compiling GPUI code for a defined component task on the first attempt at least 70% of the time when given a Rust best-practices skill, versus under 40% without it. 4. A GPUI app with a data table of 100,000 rows scrolls at 60 fps on an M-series Mac, using GPUI Kit's built-in virtualization. 5. Screen reader users complete a scripted task in a GPUI app at a success rate within 10 percentage points of the same task in an Electron app, given the exposed accessibility tree. 6. Missing grid layout adds under 10% to layout code for the screens Scott's apps use, because flex covers them. ## 📊 Methodology - **Design for H1 and H2.** Build one utility, such as a file-duplicate finder, in GPUI and Electron with the same feature list. Record installer size, installed size, idle RSS at 10 minutes, and cold-start time over 10 runs each on one machine. Report medians. Count the Tauri build as a third arm. - **Design for H3.** Fix 10 component tasks (button with counter, form with validation, table with sort, and so on). Run an agent 10 times per task with and without a Rust best-practices skill, using the same model and prompt. Score compile success and behavior against a checklist. - **Design for H4.** Generate 100,000 rows, render through GPUI Kit's data table, and measure frame times with a GPU profiler while scrolling a scripted path. Compare against a virtualized HTML table in Electron. - **Design for H5.** Recruit screen reader users for a scripted task (find a file, change a setting). Use macOS VoiceOver for both builds. Measure completion, time on task, and errors. Audit the accessibility tree for role and name coverage first. - **Design for H6.** Take three of Scott's public-style layouts and re-express them in flex only, counting lines added versus a grid equivalent in CSS. Flag layouts that need measurement code. - **Controls throughout.** Pin versions of GPUI, GPUI Kit, Electron, and Chromium. Disclose any vendor relationship. Pre-register pass thresholds. ## ❓ Questions - What are the measured install size and idle memory of Scott's GPUI apps versus their Electron predecessors, such as File Bro? - Does GPUI support grid layout, or is flex the only primitive? The hosts searched the docs at 00:13:02 and found none. - How does text scaling work in GPUI, and can apps honor the operating system's larger-text setting? - Which accessibility roles and names does the exposed tree provide, and does it work with VoiceOver and NVDA? - What differs between GPUI and the fork the captions call "GPU CE", and can a project switch back without rewrites? - How stable is the GPUI API between releases, given that GPUI Kit pins a GPUI version? - What does the small GPUI patch Scott mentions for the Jev-driven testing project change, and is it upstreamable? - Which Jev features does File Bro use, and how does that dependency affect an offline utility? ## 🔮 Future research - **Footprint benchmarks.** A public, reproducible comparison of GPUI, Electron, Tauri, and native toolkits on size, memory, and startup for the same small app would replace the anecdotes in this episode. - **Accessibility in custom-rendered UI.** GPUI draws its own widgets, so platform accessibility must be mapped by the framework. An audit against WCAG 2.2 and platform screen readers is missing from this source. - **Agent authoring quality for Rust UI.** The claim that agents write GPUI well (00:12:20, 00:31:47) has no test. A task suite would show where they fail. - **Fork governance.** The upstream versus community-fork split at 00:18:44 is a case for studying how framework steering affects ecosystem health. - **Testing without a DOM.** Accessibility-tree-driven testing for native UI is an early idea in the episode; its reliability compared with screenshot-based computer use is unmeasured. ## 💡 Implications - **Practice.** For desktop-only personal tools, dropping the web view is now a realistic option in Rust, at the cost of rebuilding what browsers give for free: text scaling, native file pickers, and platform look. - **Policy.** Teams adopting a young framework should record the version pair (GPUI and Kit) and an exit plan, since the maintainer of a key library has said they won't follow a community fork. - **Security.** The episode raises none. A custom renderer and a patched framework for testing are supply-chain surfaces worth a review. - **Education.** The React-to-GPUI mapping (structs as components, `render`, `notify`) is a teachable bridge for web developers entering Rust. - **Funding.** The quoted argument that frameworks backed by production use survive (Zed for GPUI) is a claim about sustainability worth testing against forks that lack an anchor product. - **Disclosure literacy.** The hosts disclose a gift and a sponsor but mention Jev usage without a relationship statement. The episode is a useful case for discussing what counts as disclosure. ## 🧠 Learning styles assessment - **Reading level estimate.** Flesch-Kincaid Grade Level on the transcript body is about grade 7 to 8, and Flesch Reading Ease is near 70. The register is spoken and casual. Rust, Tailwind, RPC, and WKWebView terms push effective comprehension to an intermediate web developer. #### 👀 Visual learners - Present: code on screen for the counter component, the docs' rotating-SVG example, GPUI Kit's component catalog, and Scott's running apps. - Improve: no architecture diagram comparing Electron, Tauri, and GPUI layers. Scott admits the text is too small in places (00:21:37). Add a one-slide layer diagram and larger fonts. #### 🔊 Aural learners - Present: the hosts describe on-screen code for audio listeners (00:09:26), which helps podcast consumers. - Improve: several descriptions are cut off ("Something's not loading for me," 00:17:18). A short recap of the three Rust-to-screen differences at the end would help. #### 🗣️ Verbal learners - Present: analogies carry the episode: Remix's manual update for `notify`, shadcn for GPUI Kit, Tailwind class bloat for method chaining, pure components and Babel macros for `render once`. - Improve: WGPU, Metal, WKWebView, and RPC go undefined. One clause each would help newcomers to Rust. #### 🧩 Kinesthetic learners - Present: Scott shows working apps and promises links to the skill and testing project. - Improve: no starter repository, no install command, and no step list in the transcript. A "your first GPUI window" checklist would convert watching into doing. #### 🧠 Logical learners - Present: a clear tradeoff structure: why web views hurt, what GPUI is, what it covers, what it lacks, who it's for. Wes's probing questions expose gaps directly. - Improve: the size and speed claims have no numbers. A table of measured size and memory for one app in each stack would satisfy this group. #### 🧑‍🤝‍🧑 Social learners - Present: two hosts in dialogue, with Wes asking the questions a viewer would ask. The close invites comments (00:31:47). - Improve: no pointer to a GPUI community channel or the fork's discussion venue. A link to where the dispute plays out would invite participation. #### 🧘‍♀️ Solitary learners - Present: self-contained 32-minute arc, rewatchable by topic. - Improve: no chapters, so solo viewers can't jump to the downsides segment. A reflection prompt such as "Which of your apps needs a browser?" would help. #### 🌿 Naturalistic learners - Present: nothing explicit. The smaller install and lower RAM argument implies a lighter footprint. - Improve: state the energy angle directly. Lower idle CPU and RAM in background utilities is a measurable environmental benefit the hosts don't claim. ## 📊 Accessibility assessment #### Screen reader semantics - Present: YouTube supplies player landmarks and a machine-readable auto transcript. The hosts describe the on-screen counter for listeners (00:09:26). - Improve: code and app windows carry information the narration only partly speaks. WCAG 2.2 AA 1.1.1 (Non-text Content) and 1.2.5 (Audio Description, Prerecorded) are not met for screen-shared code. #### Keyboard navigation - Present: the YouTube player is keyboard operable with visible focus, through the platform. - Improve: nothing in the video adds barriers. The episode discusses GPUI's accessibility tree (00:28:10) but doesn't demonstrate keyboard or screen reader use of the apps shown. 2.1.1 and 2.4.7 for those apps are unverified. #### Contrast and readability - Present: a dark editor theme is visible in the description of Scott's setup (00:27:28). Contrast is unverifiable from a transcript. - Improve: Scott says the fonts are small and the app text isn't enlargeable in the demo (00:21:37, 00:26:44). Small text risks 1.4.3 (Contrast Minimum) and 1.4.4 (Resize Text) in the apps themselves. #### Text resizing and reflow - Present: the player and captions resize independently. - Improve: burned-in app text can't reflow (1.4.4, 1.4.10). Wes raises the missing text-scaling point at 00:26:44 and the episode leaves it open. That is itself a content finding: GPUI apps have to implement scaling. #### Media and captions - Present: auto-generated captions exist, and there is a transcript. - Improve: captions mangle proper nouns: "Tori" for Tauri, "West Boss" for Wes Bos, "Daisy Disc", "Aerospace", "GPU CE", "sentry.iosax", and "Jeff" for Jev. This is a 1.2.2 (Captions, Prerecorded) gap in substance. No chapters are published, which affects 2.4.5 (Multiple Ways) for long videos. #### Forms and interactions - Present: none in the video. - Improve: the description puts the newsletter link in plain text, which is usable. No action needed here. #### Standards reference - Primary gaps against WCAG 2.2 AA: **1.2.2** (inaccurate captions), **1.2.5** (no audio description for on-screen code), **1.1.1** (code and UI shown visually only), **1.4.4** and **1.4.10** (text in apps and video doesn't resize or reflow), **2.4.5** (no chapters). Highest impact and cheapest fix: human-corrected captions for tool names. ## 🌍 DEIB assessment #### Cultural breadth - Present: references span macOS, Windows, Linux, and mobile targets, and multiple web and native ecosystems. - Improve: examples are English-language developer tools. No mention of right-to-left text, input method editors, or non-Latin text rendering, which matter for a framework that draws its own text. #### Inclusive language - Present: plain, conversational wording with contractions, second person addressed to listeners. - Improve: "Mr. Tori" (00:00:43) and "crappy ass AI project" (00:04:20) appear in profanity-adjacent banter; low severity. Swapping "sick" as praise for a concrete descriptor would carry more information and less slang. #### Neurodiversity support - Present: a predictable arc (problem, framework, code, libraries, apps, downsides, verdict). Wes's questions re-anchor the topic after tangents. - Improve: long digressions on sponsorship (00:03:37 to 00:05:44) and the fork dispute interrupt the main thread. Chapters would let viewers skip or find them. #### Representation - Present: two hosts in conversation, plus a quoted GPUI Kit maintainer and a cited Twitter user. - Improve: no GPUI maintainers or Zed team members speak. The fork's side is carried by a Twitter summary, and the other side by one quoted reply. #### Psychological safety - Present: good-natured banter and open admission of not knowing answers (00:13:46). Wes's skepticism is treated as useful. - Improve: the sponsorship aside frames suspicious viewers as right to be wary ("congrats to everybody who is suspicious"), which is reasonable but could read as discouraging questions if taken alone. The hosts do invite feedback at the close. ## ✅ Logical validity #### Strong reasoning - **Causal, 00:02:53.** Native web views vary by OS and version, so features aren't predictable for app authors. The mechanism (no pinned browser version) supports the conclusion for the macOS case named. - **Comparative, 00:15:13.** Because UI and logic share one Rust program, a process boundary and RPC layer disappear. This follows from the architecture and needs no benchmark. - **Scoped conclusion, 00:31:47.** Scott restricts the recommendation to personal desktop software and says no to web and native mobile, which matches the listed downsides at 00:27:28 and 00:29:36. - **Self-limiting disclosure, 00:13:02 and 00:13:46.** Scott and Wes publicly fail to find grid layout and admit not testing custom borders. Those admissions raise credibility in the surrounding claims. - **Balanced handling of a dispute, 00:20:54.** Scott states that Scott has only used upstream and doesn't adjudicate, which avoids claiming evidence Scott lacks. #### Fallacies - **Anecdotal evidence and unsupported quantification, 00:23:06.** "Eight megs when when's the last time you've downloaded an app that's been eight megs?" stands in for evidence about GPUI, but DaisyDisk's build stack isn't stated, and the Electron comparison is a guess ("probably some electron version ... 267 megs"). Fix: measure the same app in both stacks. - **Hasty generalization, 00:31:47.** "If if you're vibe coding desktop personal software, man, GPUi is the way to go" rests on Scott's own few apps, none benchmarked. Fix: state it as Scott's experience, with counts of apps built and what failed. - **False dichotomy by omission, 00:00:00.** The framing pits Electron and Tauri against GPUI. Other native routes (SwiftUI, Qt, other Rust UI crates) go unmentioned. Fix: name the alternatives or scope the claim to web-view stacks. - **Overgeneralized critique of Tauri, 00:02:53.** The WKWebView complaint applies to macOS, and Scott notes Tauri can use other web views. The "Goodbye Tori" headline line reads broader than the evidence. Fix: scope to macOS. - **Undisclosed interest, 00:24:34 and 00:29:36.** Scott says Scott is using Jev (Type Safe AI) in File Bro and in the GPUI testing project without stating any relationship. Whether one exists is unknown from this source. Fix: one line saying whether Jev is sponsored or paid-for. - **Appeal to pedigree, 00:16:36.** The Zed team's authorship and Longbridge's use are offered as a reason GPUI and its component library are good (00:20:11, quoted maintainer). Real-world use isn't a quality measure by itself. Fix: point to tests or user outcomes. - **Ambiguity from uncorrected captions, throughout.** "Tori", "GPU CE", "Gendo", and "graffiti UI" aren't reliable names. Fix: corrected captions and a links page. #### Tone of voice - Enthusiastic, conversational, and jokey, with Wes as a friendly interrogator. Contractions and second person throughout ("I'm a web guy," "let me show you"). Superlatives cluster at the open and close ("it is sick," "the way to go"), while the middle segments on styling gaps, downsides, and non-native UI are the most careful and include admissions of not knowing. The useful reading rule: trust the limits section more than the recommendations. ## 🛡️ DARVO analysis Not applicable to this source. DARVO (Deny, Attack, Reverse Victim and Offender) describes a response to an accusation, and this is a tool walkthrough with no accuser and no defensive posture. For completeness: **Deny.** Nothing is denied. The hosts volunteer limits (no grid, no native widgets, no DOM) and say they haven't tested some features. **Attack.** The GPUI Kit maintainer's quoted reply dismisses forks ("I don't think it's worth wasting time on them"), but it targets a project's value and isn't an attack on an accuser; the hosts relay it without endorsing it. **Reverse victim and offender.** No such move appears. The sponsorship digression at 00:04:20 answers viewer suspicion with a disclosure, not a reversal. ## 🎯 Conclusion The durable idea is that a web view is a choice with costs, and GPUI gives Rust developers a way to skip it for small desktop tools. The argument that holds without any benchmark is architectural: one language for UI and logic removes the RPC layer (00:15:13), and drawing on the GPU removes the bundled browser. GPUI Kit's component set is what makes the framework practical for someone who doesn't want to hand-build every control. What the source doesn't show: any number for size, memory, or speed; how accessibility behaves beyond the existence of a tree; how the fork dispute resolves. The hosts disclose a hoodie gift and a Sentry sponsorship, and say Scott uses Jev without stating a relationship. **Next steps for readers:** pick one small utility you'd otherwise build in Electron, build it in GPUI with GPUI Kit, and measure installer size, idle memory, and time to first window against the Electron version. Test text scaling and screen reader behavior before calling it shippable. Confirm the GPUI, GPUI Kit, and fork repository names against their own pages, since the captions garble several. ## 🔄 Refactor Appendix — I’m Using GPUI For Everything > Density: 2–5 Literature atoms (H3 pad), 0–3 Permanent candidates (H4 pad). > Emitted: 4 Literature, 2 Permanent. Resonance filter applied: the sponsorship digression > and the list of Scott's individual apps were dropped as low reuse. > > Konik claim-header rules: present tense, declarative, ≤10 words, searchable, unique. > > Atomicity: one declarative sentence per atom. "and"/"also" → split. > > Tag pool: #bmf · #addendum · #xref · #articleseed · #storystem · #share · #aphorisms ### 📚 Literature Split Pad #### [H1] GPUI draws its own UI instead of wrapping native widgets > [!quote] [00:07:12] > they've they've invented an entirely new way to do UI from scratch. **Context & use**: - 00:07:12, Wes correcting the assumption that GPUI converts to native controls. - This is the fact that explains every downside later: no native look, no DOM, scaling and pickers to be built by hand. **Tags**: #xref  #### [H2] One Rust program removes the RPC layer > [!quote] [00:15:13] > you're eliminating the need for like a RPC layer there, right? **Context & use**: - 00:15:13, answering how a click triggers backend work such as video processing. - Holds because UI and logic share a process. It's an architectural argument that needs no benchmark. **Tags**: #xref #articleseed  #### [H3] Non-native widgets are the biggest GPUI downside > [!quote] [00:27:28] > biggest downside one is the the non-native UI element. **Context & use**: - 00:27:28, the answer to Wes's request for downsides, right after the settings-window scaling problem. - Scott frames the same fact as an upside for full visual control, so record both readings together. **Tags**: #xref  #### [H4] GPUI exposes an accessibility tree despite no DOM > [!quote] [00:28:10] > there is a full-on accessibility tree in these apps **Context & use**: - 00:28:10, offered as the counterweight to "no browser DOM" and used by Scott's test harness. - The transcript doesn't show a screen reader using it. Treat it as a claim to verify. **Tags**: #xref #share  ### 🧠 Atomic Split Pad #### [P1] A web view is a cost to justify **Claim** (one sentence, Courtney's voice): For a small desktop-only tool, shipping a web view should need a reason, because it adds install size and memory that the tool's own logic doesn't need. **Evidence pointer**: [[#H1]] · [[#H2]] **Scope & conditions**: Holds for tools with one target platform, simple UI, and a developer comfortable in Rust. Breaks when you need web reach, native look, rich text editing, or mature docs and libraries. The episode gives no measurements, so the size and memory benefit is a hypothesis. **Links**: - [[Desktop runtime selection]] — because extends - [[Electron versus Tauri tradeoffs]] — because contrasts on where the browser comes from - [[Personal software]] — because applies-in small utilities built for one user  #### [P2] Custom-drawn UI owns accessibility **Claim** (one sentence, Courtney's voice): When a framework draws its own widgets, accessibility behavior such as text scaling and screen reader roles becomes the framework's and the app's job, not the platform's. **Evidence pointer**: [[#H3]] · [[#H4]] **Scope & conditions**: Applies to any renderer that bypasses native controls or the DOM. A good accessibility tree reduces the gap but doesn't remove it. The episode shows the tree exists and that resizing was missing in one settings window, but tests no assistive technology. **Links**: - [[Accessibility tree]] — because extends - [[WCAG 1.4.4 Resize Text]] — because evidence-for text scaling as a build-it-yourself requirement - [[Native widgets versus custom rendering]] — because contrasts on who supplies platform behavior  ### ✏️ Fleeting Queue - [F1] Confirm real names for caption garbles: GPUI-CE ("GPU CE"), Gendo, "graffiti UI", Longbridge's component library repo, https://www.youtube.com/watch?v=SdJXHYuRr48 #fleeting #inbox - [F2] Measure installer size and idle RAM for one small tool in GPUI versus Electron to test the "eight megs" framing at 00:23:06 #fleeting #inbox - [F3] Open question: does GPUI's accessibility tree work with VoiceOver and NVDA, and does it support OS text scaling? #fleeting #inbox - [F4] Check whether GPUI has grid layout; the hosts found only flex at 00:13:02 #fleeting #inbox - [F5] Article seed: "When your framework draws its own widgets, who owns accessibility?" #fleeting #inbox #articleseed - [F6] Read the Syntax episode 1043 links page for the Rust best-practices skill and the Jev-driven GPUI testing project #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] Verify GPUI-CE, GPUI Kit, and Longbridge repository names and licenses before citing this episode: research, 15 min #things - [ ] Build one small utility in GPUI with GPUI Kit and log size, idle memory, and text-scaling behavior: desktop runtime test #things  📄 **Full text:** [[Full Document Contents/Articles/I’m Using GPUI for Everything.md|I’m Using GPUI for Everything by Scott Tolinsky, Wes Bos]] ## Highlights - [00:07:12] of trying to place where this is in their thing. Like this is not something that converts it to native, you know, like it's not like you you use a GPUi text input and then it converts it to like whatever the Swift equivalent is. Like they literally wrote the entire like you start with a blank square and then you you go up from there. You got to implement like text wrapping and borders and shadows and like you have to implement literally everything because they've they've invented an entirely new way to do UI from scratch. >> Yes. And uh it feels like I said very react like but I think that's an important point because uh if you are building native native apps on desktop mobile or whatever you're often using like default components and then [00:07:55] modifying them right and styling them etc. where this is like you're using the GPUi version of everything. Now the the way that this works is that there's a a render just very s like a a render function similar like there is to react and everything is done in sort of like methods and functions rather than it is declarative like react but you're not using the same style of react bracket style component. So you would have like a div function with a flex method on it for a flexbox style thing and a flex column to do flex column. So the CSS ends up being very tailwind like in a way because you are really doing inline styles on individual divs or wrappers or ([View Highlight](https://read.readwise.io/read/01m3s5753mky5ar1tat2ec18q8)) - Note: [H1] GPUI draws its own UI instead of wrapping native widgets - Tags: atom/literature/h1 - [00:14:30] point like if you want to do things on like is there a backend or is all of your your logic just mixed together. So for say for example you wanted to like process a video um when somebody clicks on something normally in electron land uh you would use something which would call a function that lives on a backend right like some sort of RPC you'd have to implement it. Yeah it would dispatch that and then your your backend would then fire off that function. What does that look like >> in GPUi land? Well, it looks like you don't need you don't need GPUi to send a message to something else because it is just in the Rust code, right? Already there. [00:15:13] >> If you want to call a function that does something, you're already right there. Yeah. So, in that in that regard, you're eliminating the need for like a RPC layer there, right? And and again, GPUi is just the UI stuff. So how you use GPUi can be up to you. Yeah. >> Oh yeah. Your your actual implementation is like this is not like a full stack thing, right? You typically would >> it's a UI layer. Yes. >> Yeah. You would put this onto your existing Rust application or you would then choose how you want to architect it. Whereas something like Electron is a little bit more opinionated. >> Yes. Exactly. Uh one thing I thought was interesting about this Wes, there's two ([View Highlight](https://read.readwise.io/read/01m3s579hnkg4fzbct3z3bmw45)) - Note: [H2] One Rust program removes the RPC layer - Tags: atom/literature/h2 - [00:27:28] downsides there? >> The the biggest downside one is the the non-native UI element. So, like if you're going to be like, I want this to look really Mac native using liquid glass, but then on uh you know, Windows look, Windows native or whatever, like this isn't going to be the thing for you because you're going to need to reimplement liquid glass and GPU. Um, and and that could be a major downside to some people and it could be an upside to other people because maybe you want to have full control over how it looks. This is actually kind of west boss coded this this theme I got going on right here. >> Kind of looks cobalt 2y. >> Yeah. Um, I want to be able to have control over how it looks me personally. And that I mean you can it's not like you can with native apps, but like again I I don't want necessarily the cookie [00:28:10] cutter Mac app when I'm doing it. But either way, you're not using native UI elements. So that's a thing, right? Um, there's no browser DOM. So, even though there is a project for getting GPU apps running on the web, it's going to be doing so via WOM, I don't believe it's going to use the real DOM at all. I don't think that's possible really, unless there's like a translation layer. So, uh, as far as I've seen, GPUi just renders it with Wom instead. So, there's no browser DOM. That said, there is a full-on accessibility tree in these apps, Wes. And I actually use that accessibility tree in a Jev thing I built. I'll show and it's three. It's still young, right? You got GPUi uh kit as a component library, right? You have this as a component library, and there's ([View Highlight](https://read.readwise.io/read/01m3s57dvapsn28c7tt5jcnw26)) - Note: [H3] Non-native widgets are the biggest GPUI downside - Tags: atom/literature/h3