Thank you! I have mostly worked on web apps before this. I built the same app with Tauri before deciding to move to GPUI and a pure rust UI.
Pros:
- GPUI is heavily inspired by Tailwind, which made me productive pretty quickly.
- I love the tight coupling between the Rust structs and the rendering. Makes for nice and reusable components similar to Svelte.
- It's obviously purpose built for performance/latency and it shows. I haven't optimized Loungy at all, but it feels way smoother than the previous Tauri version.
Cons:
- GPUI is very obviously still in it's infancy. There isn't even a text input!
- There is no animation system. This is a huge drawback compared to CSS/Svelte
- There is no global hotkey API like in Tauri. But I could just take the hotkey crate by the Tauri guys and make it work for GPUI.
> Initially I wrote it using Tauri as I am familiar with web technologies, but quickly got fed up with moving info from rust side to the webview
Could you elaborate on this part? As I recall, communication between webview and the node.js backend was my main gripe with Electron as well. Sounds like it hasn't been solved in Tauri.
I mean it's fine for the most part, but I had to serialize/deserialize a lot because I wanted to keep all the business logic in Rust. Also there was some very noticable latency after serializing in Rust -> moving state to the Webview. However I am not ruling out that I just failed to follow Tauri best practices.
A different question, what was it about Raycast's extension model that frustrated you enough that you built this? I've authored/contributed to quite a few extensions at this point, and have had a remarkably good experience with it.
I agree for 99% of extensions their model is amazing. And I wouldn't expect me to come up with a better one any time soon.
The problem is that I want to do more in my launcher. Two examples:
- I wasn't happy with the official bitwarden extension, because going through the clipboard and copy/pasting individual items felt cumbersome. They also only supported one vault even though I asked about this years ago [0]! In raycast I wrote my own bitwarden extension that hooked into Hammerspoon and used the AX spoon to autofill credentials. That felt very hacky though so in my own launcher I am using the accessibility API directly through swift-rs.
- I wanted to build my own keyboard centric matrix chat client into raycast. I got pretty far, but in the end I was just too limited by the available components. Also I discovered that once your extensions heap reaches 100 MiB, it just gets killed. That basically made it impossible to just load the matrix-sdk including crypto.
In the end I just didn't want to keep investing time in some proprietary software that doesn't allow me to do what I want to do :)
mm, right. crypto is indeed WASM - either libolm (which is only 150KB of WASM) or vodozemac (our new rust impl, which is 5.5MB of WASM unstripped). Neither use much heap though - probably only a few 100KB.
The main heap management trick for matrix-js-sdk would be to turn on (experimental) sliding sync mode, which means that it only syncs the rooms it cares about - so O(1) with number of rooms, rather than O(N). However, i'm guessing you probably weren't testing with a large account?
Oh I was definitely testing with a large account and I was also using sliding sync. It doesn’t matter though. I moved on to the rust sdk with this project and it’s awesome :)
Having tried both Alfred and Raycast, I prefer Alfred since I can create custom searches without having to setup an entire new extension - all it takes is creating a shell command that can return JSON in a specific format.
Not to take away anything from this project (which looks pretty cool), but for folks using KDE on Linux you have a similar launcher built in called Krunner (Try Alt+F2). It is pretty well integrated and has a nice ecosystem of plugins.
Posting this primarily because I frequently run into people who use kde but have never used krunner.
I found Krunner entirely by accident after switching from Windows. PowerToys has a quick launcher that's triggered with Alt+Space. Used the shortcut out of habit after switching to a KDE environment, and was pleasantly surprised to see a similar interface pop up!
As an extremely heavy Alfred user I'd love to see a fully open source alternative (Raycast is a full no for me due to the subscription). I'd definitely donate towards development if it gets a bit further along.
GPUI is looking more and more interesting by the day. I haven't had the chance to dig into it. Can anyone with experience comment some more on how it compares to other UI frameworks? Seems like it's a really compelling alternative to things out there. On the surface, seems almost like a rust variant of Qt, but not having to deal with C++ potentially makes it much more widely applicable.
Author here: it is definitely still early and a lot of what you would expect from an GUI framework is missing. It just gives you the bare minimum of building blocks.
You can think of it like building a website with exclusively <div> <img> and <svg> :)
Thanks for the reply! That makes a lot of sense given where it is right now. Hopefully it will flesh out over time, but I'll definitely be giving it a look!
It seems that Warp.dev also might be using GPUI - at least that was my impression based on their website [0] (I might be wrong though). Which is a good think that another popular project is consuming such crate.
[0]
"... we partnered with Nathan Sobo, co-founder of the Atom text editor, who had already started building a Rust UI framework that was loosely inspired by Flutter"
I think they started out using GPUI, but might have diverged. They mention flutter and GPUI v1 was Flutter inspired. GPUI v2 which is what's not released to the public isn't Flutter inspired anymore.
I wouldn't take a bet in using GPUI at this moment. Not just because it is limited to MacOS (the developers promised a cross-platform release in the future). I haven't seen any commitment regarding stability. There's not even online docs or a version available on crates.io yet. They might make changes without regard for stability. Are they going to make breaking changes while they're modifying their Zed editor simultaneously within the same mono repo? The Zed team, presumably preoccupied with their own editor, might not prioritize needs for other use cases.
Author here: well aware of all of that. I am in close contact with the Zed team on their Discord and they are aware of this project (they even shouted it out on their Twitter).
If there are going to be breaking changes, I can live with that as this is not a commercial project.
No but I saw the author of AccessKit voicing on Zed discord that he would like to help implement it into GPUI and Mikayla from the Zed team being very enthusiastic about it.
First I thought "well, zed is just another editor, pfff" but the more news I see about it, the more it gets relevant.
Especially the GPUI because it gets an alternative to Electron and Taurin.
And rust..
It's nowhere near an alternative to a full blown web-browser yet, much less when it's still macOS-only. Tauri and Electron offer so much that is taken for granted when building GUI applications.
GPUI, by all indications, looks like it's potentially got legs as a UI framework - the team behind it seem driven and I overall do like their approach. I'm not downing on GPUI and I do hope it succeeds, let's just avoid the hyperbole.
>Managing to break cross-platform compatibility is no small feat
Neither GUI, nor application paths and standards are built in to rust.
I’m as critical of the rust fanboyism as anyone. I don’t see a specific purpose for this app that, as far as I can tell, already exists and is built in to MacOS, indicating that it’s an example being “upvoted for rust” (not saying “don’t build things”. Practice and fun are perfectly valid reasons to build something that exists). But you could at least bring valid points.
Notes for people trying to run this:
- it is MacOS only
- the window bounds are hardcoded for my system, because GPUI lacks a way to center a fixed size window
- the accessibility is pretty much non-existent. GPUI doesn’t provide an accessible text input yet, so this is a hacky minimal implementation.
If there are any questions about this project or developing with GPUI, feel free to ask!