I’m Using GPUI For Everything

Goodbye, Electron. Goodbye, Tori. Goodbye, desktop apps using web views. I'm a web guy. I love the Wes, but I'm building desktop apps with Rust, and I'm not looking back. In this episode, we're gonna be talking about GPUI, what the heck it is, how it can be, the desktop application development workflow of your dreams, and a little bit about how similar it is to React. We're gonna be looking at some code. We're gonna talking about some libraries. I'm gonna be showing some stuff I built. If you have not heard of GPU UI or this sounds interesting to you, this is the episode for you. We're gonna be going deep on GPU UI. It is sick. My name is Scott Tolinski. I'm a developer from Denver. With me, as always, is Wes Bos. What's up, Wes?

Very curious to hear what you have to say about this because I know that you were mister Tory for a while, and I know you dip into quite a few different things. This is from the folks at Zed. We should say that. I'll let Scott explain it. He knows a lot better. But very curious to see, is this something Scott is actually going to like, or is this just something Scott's really excited about and then he's gonna? Because you were really excited about Tory for a while, and then you're like, you know what? Maybe it isn't isn't it? Let people be excited about stuff, Wes. I'm excited about things. I'm glad you are because that's how we get good things. Right? Like, you dive in. You figure out what the edges are, and then the world is a better place. Yeah. Let even let's talk about that because so Electron

uses a Wes view. Electron uses, like, a Chrome instance, and then it does everything in TypeScript or Node to, you know, run your your actual, server side of things, your your desktop side of your back end. Yeah.

And and the sell for Tori was that, oh, it's Rust on the back end. Right? But the the benefits come from the fact that it's using your native Wes view. And now, Tori, you can use any web view you want now. You can use Chrome if you wanted to too. But the native web view part seemed like a major sell because you're not having to ship a browser web view with each app. One of the things that Electron gets, chunky with is that the apps are shipping an instance of Chromium with the app. And then, also, Chromium can get really costly, man, when you're when you're not working in it well. Now we've seen, like, some apps like Vercel Code use Electron very well.

In fact, if Versus Code is slow, it's usually a third party extension, not Versus Code itself. So Electron can work and can be very fast. But in my process here, I found that the the native WebView side of things is not it. Especially on macOS with Safari, the versions like, the the feature set sucks for desktop apps on WebKit Safari, like or or w k w k webkit? I think that's it. W k no. W k? WebKit WebView.

Web Wes whatever. ESLint

WebView. Whatever it is. Either way. W k webview. You're right. Yes. I just looked it up. W k WebView.

Not feature rich and not good for desktop applications and very unpredictable in terms of who has what features because you're not shipping a specific version. Right? With Electron, you can ship a version of your choice of Chrome

that you know the features will be there for every user Yeah. Who download. What most people do with these electron apps is they flip on some things that are either experimental or they'll modify Chromium in some way so that there is support for what they want. Right? Because there are inherent limitations of the web browser. So if you can sort of turn some of those things on, like, one example, HTML in Canvas, huge Yes. Huge one. Like, for what is it? Remotion is the, like, the JavaScript video editor. Right? They can render it out for you.

If they they couldn't do that if they were using the native WebView because that would be Safari in that case.

Then you have to turn on HTML on Canvas.

Yeah. Yeah. Totally. So enter GPU I. The Zed team, when we and and, actually, I will say, Wes, this is a pure coincidence. I'm wearing my Zed hoodie today. I did not do this on purpose. I'm very like, this makes me look like I'm I'm sponsored here, folks. This is not sponsored. They paid me no money. They did give me this sweatshirt, but only because we had talked about Zed in an Node, and they liked that. So we don't we don't take Scott. I've been seeing that more and more, Wes. Anytime we publish a video, people are like, you got paid to talk about StyleX, which is a open source CSS library from meta. Who cares? Why why would we get paid to talk about that? Yeah. That's crazy. That's pretty insane. Insane one to me. Well, let me tell you, like, congrats or, like like, clap to everybody who is

suspicious because the amount of DMs that I get from people who are, like, planning a launch of Node crappy ass AI project and the amount of money Like, I just got a message from somebody. They're offering $1,500 just to quote tweet one of their launch posts. Like and most I'm not gonna do it because I tried I tried the product. It sucks. But, like like, a lot of people will be like, I buy I buy a new MacBook.

I do two of those. You know? And, like, a lot of people will sort of throw that throw that out the door. So good on you for thinking that type of stuff. But I I hope that my integrity is is worth a little bit more to you guys. You know? Like, I don't Yeah. I don't want you guys to stop watching because we're shills for something, except for Sanity, century dot io forward slash syntax. You should install it in your application.

Yes. And and that that's an important point. We do not accept money to talk about libraries, tools, whatever, except Wes Yarn, a part of Century, and that's it straight up. Yes.

So you can be confident about that. GPUI. They did give me this hoodie. It did not make me talk about Wes or GPUI. Okay. So GPUI is sick because, basically, it's a UI framework that is GPU accelerated. It is cross platform, so it runs on Mac, Linux, Windows, and even runs on the the the web and mobile, but we'll talk about that in a little bit because there that's not something maybe that I would do.

So you could think of it as like an electronatory.

You wouldn't use it with electronatory, but you would use it, instead of using electronatory to build a web view. Now why would you do that? Well, it is sick. It's fast. Like I said, it's GPU accelerated.

It is native all the way down from Rust rendering to the GPU, rendering to the GPU, rendering with the GPU.

Yes. So let let's get into it here a little bit about how this looks because, it's a very web and, dare I say, React like experience, which is gonna make, Wes developers happy.

Again, you aren't shipping a Wes view for this. You're not using the the DOM. You're using just these primitives.

Like like, to be clear, if anyone's sort 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 GPU UI text input, and then it converts it to, like, whatever the ESLint equivalent is. Like, they literally wrote the entire like, you start with a blank square, and then you you go up from there. You gotta 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, it feels, like I said, the very React like but I think that's an important point because, if you are building native native apps on desktop, mobile, or whatever, you're often using, like, default components and then modifying them, right, and styling them, etcetera, where this is like you're using the GPU Vercel of everything.

Now the the way that this works is that there's a a render just very 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 dot flex method on it for a flex Bos style thing and a dot 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 things like that. And the shorthand is very, I dare I say, tailwind like.

There's a lot of, like, helpers like text, XL, and stuff like that, text color. Imagine that. I actually like that, Wes. The text color is named text color and not just color.

That always bugged me about CSS.

Yeah. Oh my god. Oh, well, you could say, well, actually, it's because it also controls, like like, what, border and and several other things. But who cares? It should be text color. I agree. Yeah. You're right. You're right. It does. It does change the color of a lot of things. You're right. But, I think getting started in CSS text color was always a weird thing.

There's the concept of children. Like I said, it's very, very react like in its presentation when you look at it or at least react like in the sense of you have components, you have props, you have state, you have those types of things. So, I made a quick little application here. If you're watching on video, I have this pulled up. If you're watching on audio, we'll do our best to describe it. But, basically, you define a component with a struct. It has props very much similar to how you have props in TypeScript. In React, you're defining the props, the types of them. You have a render function where, again, you have things like divs, and then you can pass props into components.

The render for the counter, which is a component I have here, it is able to have a button with an on click, and then you have a new listener, and then you're incrementing the counter. This should all feel very similar to React. The big difference here and and maybe not the big difference because there's a lot of big differences here. But when you update state into something like that, you have to run Node,

And that notify is a method on the the general Oh, this is like Remix. Context. It's like Remix. I'm hoping you would say that. Right? It just you you call the update function yourself in in Remix where okay. I've done some stuff. I've mutated some variables.

Now I want

to rerender this specific piece so you explicitly do that. Is that what that's what Node is? Yes. Ex exactly, Wes. Okay. I was look. I I put this in here hoping that you would say it's, like, Remix, and I'm glad you bet. Really cool. You know? And in general, like, I I I'd know if you haven't used Rust before, some of this is gonna look very foreign or very intense. If you've written Rust before and you've written React, you're gonna be like, oh Oh, I get it. Because if you've done the two of them together, the little Rust things aren't going to be surprising, and then the React stuff is gonna stick out very, very obviously.

So

have they reimplemented most of what we expect from CSS? You know? Like, I I saw flex. I saw, obviously, padding, borders, text color, focus.

So I think have they just basically reimplemented

everything that you need? So far, I've I I've been able to do the stuff that I wanna do, as far as, like, shadows, opacities, textures, backgrounds, repeating backgrounds, and stuff like that. I'm sure I will hit edges as I try to do crazier stuff. But, you know, like, as far as, like, animations, here's an example in their docs for doing a rotating SVG.

Let me find this.

And then the in the syntax, I will say, folks, if you are, like, coming from a React and HTML world and you're just chaining a bunch of methods for things, like, this is Tailwind class bloat on crack. Can you say that? Tailwind

class bloat on steroids. We'll see. Because it's it's one per line, and you're chaining it. Almost like like jQuery chaining your methods. Yes. So you get big old long files.

It doesn't necessarily matter that much to me because agents are often writing this stuff to me, and I find it to do a good job. There's, like, with spring, to have spring animations, things like that. So in my experience, it's been very full featured for the types of things I wanna do in CSS. Now does it do everything in CSS? I can't imagine that it does. But,

so far, I'll show you some actual Does it have with it. Is is it have Flexbox and Grid or or Grid? Or what's the layout thing? Because that's the one thing about React Native JS that they don't have CSS Grid implemented. Right? You gotta do everything in Flexbox. Yeah.

Where's Grid? Grid. Grid. Grid. Grid. Grid. I'm trying to the docs here, what I need is a big old reference docs

JS what I need. The doc there doesn't seem to be docs. There's just a bunch of examples.

I have mostly used flex to do everything. So well, that's a good question about grid versus flex. Yeah. I'm seeing just flex everywhere.

Yeah. Me too. I'm not seeing any grid. So that's a bit of a limitation.

I guess. But, I mean, it's still like I don't know. Before CSS Grid, you were doing everything in. Yeah. We were able to do a lot of these things. There's they're probably, like, something like a subgrid or whatever you'd run into be like, this is kinda I'm sure they're But They're some things.

Also measure things, and and you're in the the Rust code. Right? So you could probably do a lot of the stuff programmatically.

Or Yeah. Like, here here's the other question JS, can you implement your own things?

Like, if you wanted to have a Sanity border. See, Wes, I knew you would ask me a bunch of questions that would stump me. I've the apps that I've built I'll show you. The apps that I've built have been very vanilla looking. So Okay. I mean, I've I've I've styled them to a degree, but you're always wanting to push it into place a fancy board. You haven't even Okay. Well, here here's another Wes. Yeah. Is like, obviously, handles

layout, handles styles, handles events. Like, we saw like, when you click on things, you can do things. It handles state. At what point, like, if you want to do things on like, is there a back end, or is all of your your logic just mixed together? So for say, for example, you wanted to, like, process a video, when somebody clicks on something. Normally, in electron land, you would use something which you would call a function that lives on a back end. Right? Like, some sort of It does look at dispatch. Implemented. Yeah. It would dispatch that, and then your your back end 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 Rust code. Right? Already there. If you wanna 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, GPU UI is just the UI stuff. So how you use GPU UI 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.

One thing I thought was interesting about this, Wes, there's two different types of render in in this. There's a render and a render once. So, like, a render once could be used for, like, badges and more, like, static stuff that doesn't need updating. What Wes, like, the wasn't there, like, a React version of that before that doesn't have state? Was that pure component, or am I, like Yeah. Going nuts? You could, like like, memoize it. You can obviously still rerender a memoize component. But or,

yeah. What was it? There was something in Babel as well where you could just, like, precompute it at at, like, build time. So that's another one where you just don't have any logic. It's just at build time, you figure out what the HTML would be to be rendered. It's been so long. I forgot.

And then there's a babble macros. That's what they were called. Macros. Yes. And then there's also just this typical render where the component has state state changes and then context Node Wes and update rather than. Like, that function's more like kind of like remix or react like you expect there. So, folks out there might be looking at this and being like, great. Now I gotta reimplement every single React thing or find on on on, you know, whatever. Well, fear not. There's something called GPUiKit, which JS been a, man, the very best thing for me in this. So GPUiKit is a component library, and this thing has so many components in here from accordions, alerts, dialogues, bubbles, badges, carousels, dialogues. I mean, just like anything that you could possibly Node, it feels very like Shad c n of GPUI.

Something's not loading for me, but I've been using this thing to great success on every single GPU project I've been doing. I've been using GPU kit and then using that as a basis to, style my stuff GitHub. Because it it just gives you these primitives that are actually nice and extendable.

They're not too designed, but they're just designed enough to look decent.

You know? Input, output, pagination, popover, combo box, command, input, all the stuff you'd expect, all the pieces that you'd expect to, be able to use

in an application. Interestingly enough, Wes, it looks the the kimonos look very similar to my graffiti UI stuff, which means that I, like, have a lot of thoughts on how to style it. Stick an agent on that to this afternoon and get everything ported over.

Yeah. That's a good point. Yeah.

But it does. It gives you the primitives, all the input types and stuff you need. And one thing that I really loved was the the data table and, like, virtualization out of the box and everything like that into this. You know, like, sorting and tables just work and are nice and easy. Like, when I think of GPUI before GPUIKit, I was thinking, okay. Now I gotta build every component. And to me, this is the major unlock with this thing because there's just so much in here, and it's all really good. So if I need something, I I just got it right here. Hey. Real quick here. I wanted to, mention, because we don't talk about it in this episode, about GPUi CE or the community edition. Now the community around GPUI is a bit fragmented at the moment because, Sanity members feel like the zed team, the team that created GPUI, is only adding things to GPUi that serve them.

So there is a fork of GPUi that brings in all of the changes from GPUi.

And according to a user on Twitter here, Cameron Campbell, CE has some cool features not present in GPU UI, like declarative style transitions, corner smoothing, AKA squircles, blur, background blur, gradient support on shadows and borders. And, honestly, all of this stuff sounds awesome.

However, I do wanna highlight that in the conversation about GPUYKit, which is a library that, we talk about extensively in this Node. The creator of GPUYKit or the maintainer of GPUYKit says, in this in terms of not supporting, GPUICE CE strictly as even like a flag because GPUiKit has a version pin for GPUi.

So they say, I was never optimistic about them from the beginning. These projects create problems without fixing them. I don't think it's worth wasting time on them. Only projects validated by real world applications will generate continuous real world demand and drive the framework's improvement.

GPUI has zed. GPUI component has Longbridge.

These frameworks weren't created out of thin air. They were built upon real world project needs, which is why they have achieved their current success.

Just like my initial choice of GPUI, I was drawn to the way that zed team works and GPUI's design philosophy. Currently, GPUI JS indeed facing slightly slower process due to Zed's knees, but it's actually been continuously improving. Basically, they are saying that this is why they will Scott support the GPU YCE, I e, it's just a community fork, and, they don't want to add, things into their application. Now whether or not these points are valid or not, some people disagree on all of that.

It's still a conversation that's being held and one we don't really get into in this episode because I have really personally only stuck so far with GPU y as well as the GPU y kit side of things. Just wanted to clear that up for anybody who wanted to understand a little bit more about the situation. Here, let me show you some apps that I've built with this. I've built a few apps with this. One of this is called Gendo, and it shows every project that's on I wish I could make these bigger. I don't have the font size, and there's some ugly stuff about these. Shows every project that's on my Mac or my MacBook Pro. And then for things like this one, it's a they this is battle mode, which is the the app we did for our our CSS tournament. It shows the version of okay. I actually have three copies of this on the computers I have. I have two copies on my MacBook Pro and then one on my Mac mini. So, basically, it's it's here for me to be able to and then I can see, like, the the status of all of them, and I can transfer them. I can star them. I can open it and stuff like that. This is an app I'm just working on for myself because now that I have multiple computers running multiple dev process and stuff like that, it's getting tough to keep track of everything, the versions, which one's up to date, what's where, what's everything like there. So, like, one of the things I'm gonna be doing is, organizing things and making it a little bit more of, like, here's a system. I mean, even managing caddy domains and stuff like that. So I built this little app. It's it's nice. It's it's just a little personal software here. Again, it's gonna connect to any computer I have in the network. I also built file oh, yes. Continue. I Scott a question, though. So, like, people are probably asking, like, like, why would we wanna do that? We we answered the fact that, like like, obviously, Chrome and whatever, that's they're they're, like, hogs, and they're they're fairly large applications as well. Right? Yes. But, like like, this is perfect for

tiny, u little utilities where you don't wanna have to ask somebody to download an absolutely massive thing. Like, I just updated DaisyDisk, which is a little app I use on my computer to scan, find out like, I I Wes out of space, and I need to find out where is the space being taken up. Right? And DaisyDisk just updated itself eight megs. Eight megs. So when when's the last time you've downloaded an app that's been eight megs? That's tiny.

Very happy about that. And, like, versus, like, somebody there's probably some electron version of DaisyDisk that's a 267 megs.

And, every time you have to update the thing, it's just this massive thing sit on your computer. I I have probably, like not to mention RAM and resources of just these things running in the background.

Yeah. Totally. And and I I 100% agree.

It's a little desktop app, and I want it to be thin. I want it to be light. I want it to be, fast. I want it to be all those things. I don't wanna have, for every little idea I have, I don't wanna have a separate Chromium instance running. And this takes it from something where I would have to have that to something that I don't very, very quickly because we're able to make it look good and fast. I'm actually, redoing my video recorder right now because I want that to be as lean as possible. Right? So moving that into to this would be really nice. Another one that I have is Filebro, and Filebro is an app that does, like, file automations a la Hazel.

So, basically, hey. If this screenshot is like this and the name starts with this, then move it into here. I'm gonna use well, I am already using Jev, but I'm gonna be using Jev even more in this bad Bos. And it's gonna be able to set up automation. So, again, something you want to have running, but something you want to be very nice and fast, like file duplication checkers.

This is all just temp check test data. But this is like file duplication checking and, like, merging of files and stuff like that. So to me, this is like a perfect use case for this type of thing. Right? A nice small personal utility app that I want to be I don't want to run. Like okay. So Filebro, I will say, originally, was an electron. Right? And now it's like I can have all this duplication checking. I can do deep analysis of files. I can do all of that just directly in Rust in the application, and I found it to be very nice.

So this is Filebro. I've also been working on a window utility library because I just make too many things. Right? This is mister mister space. I was tired of you know, like, aerospace came out, and aerospace is great. It's a window manager that locks everything in, but I found it to be, like the automatic window locking in. I find that to be relatively obnoxious in daily use. What I really wanted was something more that I could say, alright. Here's a shortcut. Pin to the left. Pin to the right. And, obviously, like, in here, you can see command failed. Obviously, Raycast does that very Wes, but I also wanted the ability to send things to different spaces, send things like, in Omarji, you you have your window. You can send it to space number two. You can pnpm send it to space number three, or I wanna be able to automatically have every window I have automatically fit into the the desktop at once. Right? Like, those types of functionality. I'm not gonna have that in, Raycast the way I want it to be or develop these layouts. So I built this little app, and it uses macOS native spaces. So, like, I can send something to another space in here. It's really pretty slick.

And agents can use this too, by the way. I could I could prompt an agent saying to send a window someplace, and it's gonna know how to do that. So it it it's pretty cool little app, but just like little fun things that I've been building with GPUI. And the cool thing about this app is that I only use GPUI, Wes, to do the settings menu. So I have, the setting this is just the settings menu. So this doesn't have to be open for the app to run. So you can use GPUI to build, like, full on things or just little nice looking settings menus. Right? So Wow. Yeah.

It's cool. As what about, like, downsides? Obviously, you just showed one, which is that you can you couldn't increase the size of it, because, like, that's something that comes for free, with the browser. Right? And you obviously need to implement some sort of scaling. I'm I'm sure maybe that exists, but you have to then hook it up. Right? Sanity other downsides there?

The the biggest downside one is the the nonnative UI element. So, like, if you're gonna be like, oh, I want this to look really Mac native using liquid glass, but then on, you know, Windows Windows native or whatever, like, this isn't gonna be the thing for you because you're gonna need to reimplement liquid glass and GPU UI.

And and that could be a major downside to some people, and it could be an upside to other people because maybe you wanna have full control over how it looks. This is actually kind of Wes Bos coated, this this theme I got going right here. Cobalt two y. Yep.

I wanna 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 I don't want necessarily the cookie cutter Mac app when I'm doing it. But either way, you're not using native UI elements. So that's a thing. Right? There's no browser DOM. So even though there is a project for getting GPU apps running on the web, it's gonna be doing so via WASM.

I don't believe it's gonna use the real DOM at all. I don't think that's possible, really, unless there's, like, a translation layer. So, as far as I've seen, GPUI just renders it with Wasm 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. Oh, awesome. And then it's three. It's still young. Right? You got GPU UI, kit as a component library. Right? You have this as a component library, and there's a couple others too. This is the best one that I found, but it's still very young.

So the fact that this exists in this extent is is pretty sick. But because it's so young, you Node, you'll be less resources or whatever. I have found that AI does a pretty good job of of writing this.

I will say that. I use a Rust best practices skill to make my AI do a good job of this. I'll link this up in the thing, and, overall, that's been fine.

But the the the biggest downsides are really again, it's it's not a write once deploy everywhere platform in that sense. Right? You're not gonna get a React native style native app out of this JS well as a web app JS well as a desktop app.

You're pretty much locked into whatever you're doing. And, primarily, I'm using this for native desktop app stuff. On the same frame as the, it's not using the DOM. It's not using that. If you want AI to test your apps, you're gonna be looking at a computer use rather than, like, a browser use type of situation.

However, I did create a JEV driven native GPUI testing project here. It requires a small patch to GPUI and just a, a little bit to your harness here, but it uses JEV to computer use via the accessibility tree in GPUI to be able to go through and click and do all that stuff Sanity doesn't have to take screenshots to test your application.

So I'll I'll link this up here. Again, this is very early, and, it's working for me. But, again, early small project. So if you're looking to build, like, fast desktop apps, maybe cross platform, you don't care about either deploying to the web or you're willing to put up with some headaches there, I think GPUI is a good choice. I've mentioned mobile a few times. There is GPUI mobile. It does exist. It seems to work.

It is experimental.

You're rendering everything with, like, metal via WGPU on Bos, so it's not using it's not like a conversion layer like React Sanity, But people have it working here. There's docs and examples of it working. You're giving you're you're you're not getting to use all that native iOS good stuff, but it works. You'd have to, like

I I would imagine there's, like, a lot of bridges you would have to build in order to like, same with React Native. You know? Anytime you wanna use any of the native UIs, whether it's it's maps or, like, NFC or, any even just, like, the file picker. The one thing that drives me nuts in some of these, like, apps that are not built natively is that, like, they just, like here's a file picker. It's just a a listing of every folder you've ever had, and, like, there's I don't have any of my shortcuts. None of my favorites are in there, and it's just it's impossible to find what I'm looking for. So there is a bit of a trade off there, but you can I'm certainly sure you can you can write bridges to the native ESLint

Yes. There.

So would I use this to to do a native mobile app? No. Would I use this to do a web app? No. But I'm using this a lot to do personal software, desktop apps, stuff that I I don't wanna have just a 400 electron app on my computer for. I think a lot of people can recognize that as being a cool use case for this. So, again, agents are good at Rust. I've at least JS far as I found, agents are good at this. If if you're vibe coding desktop personal software, then GPU y is the way to go if you're talking to me.

Beautiful. Alright. Thanks for schooling us. Let us know down below if you want to use GPU wire or if you plan to use it, what your thoughts are. We'd love to hear it.

Peace.