iamnbutler
I could see more components being shipped first party if the community took over gpui, or for some crazy reason a team was funded to develop gpui full time, but developing baseline components is an immense amount of work, both to create an maintain.
Buttons (any div can be a button), clipboard, scroll views (div, list, uniform_list) should all already be in gpui.
gpui will support web eventually - we always planned it, and i've tinkered with some folks on the team on it a bit. The problem is the crate needs to split into core/web/native (and maybe mobile?) as web needs a new executor and native has a number of deps that won't play nice with wasm...
someone did get a very claude-driven demo of gpui on the web up (you can find it in the discord somewhere.)
I would love that too though, a true cross platform solution.
> How was it like working at Zed? Any reason for leaving?
Working at Zed was great. I was employee #4 (#1 after the founders) - it was fun, often hard - Nathan & co helped me learn Rust and I fell in love with it.
I wanted to do something pretty specific (tl;dr, basically skunkworks type work) which was the reason I left.
There are always pros and cons to every role, but I appreciate that Zed is building from the ground up. DeltaDB will be very exciting - we were sitting on our hands waiting for it for a lot of the really exciting things we wanted to do with Zed.
Having to take on investors is never awesome - but as much as I don't like it, I do doubt Zed would never have existed without them.
But yeah, getting paid to design and write rust UI every day was a blast.
Focus ebbs and flows at Zed, they'll be back on it before long.
I've written quite a lot of rust UI code for Zed over the past few years so I'm mostly familiar with the pros and cons of gpui, but I haven't spent much time with Iced, Dioxus, Xilem, etc.
Lots of gpui was built with build Zed/a text editor in mind directly, and as folks have mentioned here, it is hard for Zed Industries to justify work on gpui that is purely for the community. Nathan is usually pretty pragmatic around not optimizing early, and gpui is generally serving Zed's needs at the moment (from what I know, I haven't worked on Zed since July)
I do think ZI would generally benefit if gpui did get pulled out of Zed if there was a community that was passionate about taking it over... but that is time and effort in itself.
We started building zed in zed using it's collaboration in early 2021. Collaboration has always been part of it's DNA. Nearly everything at zed is written in pairs over collab.
I shared this with the team. I need to spend some time in Cursor to understand their mental model, it seems a lot of folks have come to enjoy using it.
We do also have extensibility planned for the assistant, you can see a taste of it in the slash command code if you want to check it out.
AFAIK you can use `/workflow` with some other models other than Claude, but I can't speak to which off the top of my head.
Cursor is great – We explored an alternate approach to our assistant similar to theirs as well, but in the end we found we wanted to lean into what we think our super power is: Transforming text.
So we leaned into it heavily. Zed's assistant is completely designed around retrieving, editing and managing text to create a "context"[0]. That context can be used to have conversations, similar to any assistant chatbot, but can also be used to power transformations right in your code[1], in your terminal, when writing prompts in the Prompt Library...
The goal is for context to be highly hackable. You can use the /prompt command to create nested prompts, use globs in the /file command to dynamically import files in a context or prompt... We even expose the underlying prompt templates that power things like the inline assistant so you can override them[2].
This approach doesn't give us the _simplest_ or most approachable assistant, but we think it gives us and everyone else the tools to create the assistant experience that is actually useful to them. We try to build the things we want, then share it with everyone else.
TL;DR: Everything is text because text is familiar and it puts you in control.
[0]: https://zed.dev/docs/assistant/contexts.html
[1]: https://zed.dev/docs/assistant/inline-assistant
[2]: https://zed.dev/docs/assistant/prompting#overriding-template...
We don't have side-by-side diffs yet, but once we do I'll make sure it works here :)
For example, you can do /file *.rs to load all of the rust files in your project into context.
Here is a simple but real example I used a while back:
"/file zed/crates/gpui/src/text_system.rs
I have a font I want to check if it exists on the system. I currently have a &'static str.
Is there something in here that will help me do that?"
I haven't interfaced with the lower level TextSystem that much, so rather than dig through 800 lines of code, I was able to instantly find `is_font_available()` and do what I needed to do.
You can even edit the prompt after the fact if the diff doesn't show what you want and regenerate without having to start all over.
There is lots of room for improvement of course, but I’d love to hear what your desired search experience is.
Some of these things will likely be made more general and have dedicated gpui elements built for them (button, input…)
I think not rushing to cover everything right out the gates is giving us the time to feel out apis that feel good to write and work well for us. Hopefully in the near future that translates to a UI library that is awesome for the whole rust community to use.
We’ve slowly been building out gpui to be super ergonomic and fluid for us to build the kind of UI we need to.
As a designer that just picked up Rust last February it’s been really nice to have something that is so comfortable to work with without compromising our performance goals.
Let us know if so - they should just work™, but would love to know if that is not the case.
At least these days we order the themes by dark then light... Themes used to be grouped by name, so you would get rainbow flashbanged moving down the list!
This wasn't our intended behavior for this.
A team member just dug into our implementation of LSHandlerRank and it looks like we are using "Default". Apple's definition of the "Default" rank is this: "This app is an opener of files of this type; this value is also used if no rank is specified".
From our team member's investigation it looks like VSCode doesn't set any LSHandlerRank (which in theory from the definition above should be the same rank, but from your experience that doesn't seem correct.) Sublime uses uses "Alternate" as it's LSHandlerRank, which its definition is "this app is a secondary viewer of files of this type".
We will audit what other editors set and discuss if it makes sense to change the rank we are using.
Thanks for pointing this out.
I was actually pretty surprised when we did our measurements, and would say those numbers don't match the perceived performance (oe the feed. I haven't experienced an app that feels more fluid for basic things like scrolling before Zed – Obviously I have bias, but that is my 2c!
Sorry for the hassle.
You should be able to open stupidly big files and shouldn't experience much to any lag. Nathan has a demo he likes to give opening one one of those huge json files and searching, using multiple cursors, etc. It is pretty cool to watch.
For now, people pairing/collaboratively writing Rust is our focus, and we are pulling people in that fit that criteria!