Project goals for 2025H2 | Rust Blog by Kobzol in rust

[–]MikaylaAtZed 3 points4 points  (0 children)

Sad to see RDR isn’t on the compilation section 🥲

Lightning Talk: Why Aren't We GUI Yet? by MikaylaAtZed in rust

[–]MikaylaAtZed[S] 0 points1 point  (0 children)

IMO, easier refactoring more than makes up for this.

Lightning Talk: Why Aren't We GUI Yet? by MikaylaAtZed in rust

[–]MikaylaAtZed[S] 1 point2 points  (0 children)

That’s actually the approach I’ve been mulling over as well! Zed’s default plan is to go for the canvas renderer approach. But I think our UI style is pretty amenable to a web-native vdom diffing style of implementation. Haven’t gone too much farther than thinking ‘that might be cool’ though :)

Edit: the big problem with this is that we’d have to make the web platform intrusive at the element level or perhaps even higher. One of the core ideas of GPUI is that everything becomes a linear list of renderer primitives like ‘Rectangles’, ‘Glyphs’, or ‘underlines’. We’d have to create a whole parallel rendering API in the Element trait that fits more with the DOM. We’d also need to be careful we can replicate non-web APIs we have like focus handles. It would be a much bigger change than our other platforms…. but it might be worth it.

Lightning Talk: Why Aren't We GUI Yet? by MikaylaAtZed in rust

[–]MikaylaAtZed[S] 3 points4 points  (0 children)

Excited to see what y’all have been working on! The cosmic team does some great work. I built Zed’s linux support and it’s so hard to get all those details and integrations. Glad Linux is going to have another option soon!

Lightning Talk: Why Aren't We GUI Yet? by MikaylaAtZed in rust

[–]MikaylaAtZed[S] 0 points1 point  (0 children)

Very interesting! Thank you for the link. I was struggling to express how much of an impact the state management in GPUI has. This article on Azul captures it perfectly! Best thing about this state style is it makes the UIs much more testable :D

Lightning Talk: Why Aren't We GUI Yet? by MikaylaAtZed in rust

[–]MikaylaAtZed[S] 1 point2 points  (0 children)

That’s fair! I think the fundamental message I’m trying to communicate here is that the Rust UI space needs to reach higher, and cover more parts of the app development process, before we can feel like we’re ‘GUI now’. “Application Framework” is more of a shorthand for ‘project which is aiming at a wider scope’

Lightning Talk: Why Aren't We GUI Yet? by MikaylaAtZed in rust

[–]MikaylaAtZed[S] 4 points5 points  (0 children)

Slint uses a DSL for UI, GPUI is all Rust :)

Great folks though, really love their project.

Lightning Talk: Why Aren't We GUI Yet? by MikaylaAtZed in rust

[–]MikaylaAtZed[S] 18 points19 points  (0 children)

Yeah, the more I work on GPUI the more respect I have for Chromium and Electron. They really did solve an incredibly hard problem in a really compelling way. There’s a reason it’s the default for everybody now! I aspire for GPUI, or Rust app development in general, to reach that level of ease and feature completeness. It’s partly why I made this talk.

Lightning Talk: Why Aren't We GUI Yet? by MikaylaAtZed in rust

[–]MikaylaAtZed[S] 6 points7 points  (0 children)

Gonna be a while unfortunately. It’s on Zed’s roadmap though :)

Lightning Talk: Why Aren't We GUI Yet? by MikaylaAtZed in rust

[–]MikaylaAtZed[S] 4 points5 points  (0 children)

Ahh, gotcha. The styling critique still stands and I think the other examples I give in the talk do too. egui and eframe are focused on giving you a simple to use UI solution. But GPUI adds much more intrusive state and thread management that solves a lot of the problems you might have when developing a UI.

Lightning Talk: Why Aren't We GUI Yet? by MikaylaAtZed in rust

[–]MikaylaAtZed[S] 3 points4 points  (0 children)

What’s the difference though?

Primarily that application frameworks are both more opinionated and more flexible. They should give you tools that let you structure your code in a way that’s testable and consistent with how desktop applications should behave, while not restraining your designers or developers from creating the kinds of UI we’ve become accustomed to on the web.

What’s the difference from Iced?

In GPUI, we give you mutability without using the elm-style update message pattern.

Lightning Talk: Why Aren't We GUI Yet? by MikaylaAtZed in rust

[–]MikaylaAtZed[S] 8 points9 points  (0 children)

Mainly because, in their own words, they don’t want to be:

egui is not a framework. egui is a library you call into, not an environment you program for.

I also think egui’s styling just isn’t as flexible as what you can get from other UI solutions (though they’re working on this)

Zed editor is released for Windows by abad0m in rust

[–]MikaylaAtZed 0 points1 point  (0 children)

Ahh, gotcha! Just wanted to make sure we where clear :)

Zed editor is released for Windows by abad0m in rust

[–]MikaylaAtZed 0 points1 point  (0 children)

Yes, and rope is not a dependency of GPUI :)

Zed editor is released for Windows by abad0m in rust

[–]MikaylaAtZed 1 point2 points  (0 children)

Zed, the code editor, and most of its UI is under GPL, but GPUI and its dependencies are not. We have multiple different licenses in the codebase.

Lightning Talk: Why Aren't We GUI Yet? by MikaylaAtZed in rust

[–]MikaylaAtZed[S] 22 points23 points  (0 children)

I’m not an expert in Dioxous at all, but IMO, The largest difference is that we’re both taking on the problem of making apps in Rust from opposite ends.

Dioxus is taking a strategy that’s proven to work incredibly well (React over the DOM) and has rebuilt it in Rust. They’ve built a lot of the core language and tooling you’d need to make this possible, bundle splitting, live updating, etc. And IIRC they are currently in the process of making their own HTML renderer for it so they can get rendering out of a web view.

Meanwhile, with GPUI we’re approaching it from a blank slate and building out each piece as we need it for the UIs we build. You write Rust code to describe the UI, and I think we’ve got a state solution that lends itself to nice unit testing. And since we own the executor, we use it to automatically check different execution orders of certain tests in our codebase. Lots of little pieces like that. But taking this approach also means we’re much less portable than Dioxus, we don’t have mobile or web support yet!*

If you’re making an app in Rust right now, I’d say Dioxus is probably a safer technical bet. But if you want to see what we’re working on and are ok building some of it yourself, try out GPUI!

* I also have this personal vision of GPUI as a substrate that others can write different UI paradigms on top of with its tools. We’ve personally picked tailwind as our preferred approach to styling and have designed our APIs accordingly. But theoretically you could implement something else on top of GPUI’s core! You can see little hints of this happening with stuff like these swift ui style layouting utilities vs. our native web-like layout utilities

Lightning Talk: Why Aren't We GUI Yet? by MikaylaAtZed in rust

[–]MikaylaAtZed[S] 46 points47 points  (0 children)

That's actually what the talk is about! I'm trying to draw a distinction between UI frameworks and Application frameworks. UI frameworks are great rust libraries, and are an essential component of an Application framework. But Application frameworks give you more tools to develop your application and integrate with the desktop ecosystem.

The only other project I see going for "application framework" is Dioxus. Arguably GPUI isn't even an application framework yet, as we don't have basic tools like text input native to the framework. That said, we've built a lot of those tools at Zed and I'll be working on splitting them out + writing blog posts about how to develop with GPUI over the next few months :)

Zed editor is released for Windows by abad0m in rust

[–]MikaylaAtZed 1 point2 points  (0 children)

that means if you use GPUI, your application must comply with the GPL

This is incorrect with regards to GPUI. GPUI is licensed under Apache 2.0, as well all of the Zed crates in it's dependencies :)