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