xilem VS QMetaObject crate for Rust

The web browser gives us an extremely frictionless development and deployment process. Our CI generates a fully deploy at a unique link for every commit which lets us open and test PRs with a single click. It deploys updates to users without needing to make them go through an updater. In these relatively early stages of our development process, the importance of the velocity that gives us cannot be understated. Plus, the ability for users to try it out in one second is quite helpful.

I've designed the whole architecture specifically to avoid the web UI "feeling like a web app" with the subtle latency of interacting with the site. I wrote all-custom UI components using the minimal amount of HTML and CSS to achieve the requirements instead of depending on an external component framework which always loves nesting dozens of `div`s inside each other to achieve what should be doable in one or two. And our highly-lightweight JS which calls into Rust (Wasm) lets it keep the slow logic out of slow JS. And we are using Svelte to move most of the frontend DOM management logic from runtime to compile time. This architecture really helps us keep performance levels as close as possible to feeling native despite using the web for its GUI rendering; and I believe it has succeeded at feeling responsive by comparison to most other web apps you use (even Slack, for example, which shouldn't be nearly as complex).

Web lets us build fast, deploy the latest version to users fast, leverage prevalent developer experience with HTML/CSS for creating GUIs, and avoid getting stuck in a box with Rust's currently-immature GUI ecosystem. That's the tradeoff we had to make early on, and it was a good decision. But we will eventually move towards a fully native version...

In the short term, we plan to use [Tauri](https://tauri.app/) which is sort of a hybrid between Electron and a native application. It uses the OS's webview to shrink the shipped binary to only a few megabytes and reuse shared memory resources with other webviews at runtime. It also runs all our Rust code natively instead of through WebAssembly so all the business logic in Graphite runs natively and only the thin UI layer becomes dependent on web tech for the GUI display.

In the long term, we plan to rewrite the entire GUI in [Xilem](https://github.com/linebender/xilem) which is the up-and-coming Rust GUI that I believe will finally get everything right, including performance (which is something many desktop GUI frameworks are actually bad it, and sometimes even worse than web). We'll still deploy a web version but at that point, it will become native-first.

Hopefully that roadmap and explanation of the architectural decisions clears up any worries about the short and long term state of our GUI.

That said, Xilem is very close to that idea, but it's in its very early stages and nowhere near Flutter's capabilities.

xilem#62 demonstrates how Xilem's reactive layer can target DOM nodes.

Inspired by Xilem, Leptos and rui, Floem aims to be a high performance declarative UI library with minimal effort from the user.

There are a number of up-and-coming Rust-based frameworks in this niche:

- https://github.com/iced-rs/iced (probably the most usable today)

- https://github.com/vizia/vizia

- https://github.com/marc2332/freya

- https://github.com/linebender/xilem (currently very incomplete but exciting because it's from a team with a strong track record)

What is also exciting to me is that the Rust GUI ecosystem is in many cases building itself up with modular libraries. So while we have umpteen competing frameworks they are to a large degree all building and collaborating on the same foundations. For example, we have:

- https://github.com/rust-windowing/winit (cross-platform window creation)

- https://github.com/gfx-rs/wgpu (abstraction on top of vulkan/metal/dx12)

- https://github.com/linebender/vello (a canvas like imperative drawing API on top of wgpu)

- https://github.com/DioxusLabs/taffy (UI layout algorithms)

- https://github.com/pop-os/cosmic-text (text rendering and editing)

- https://github.com/AccessKit/accesskit (cross-platform accessibility APIs)

In many cases there a see https://blessed.rs/crates#section-graphics-subsection-gui for a more complete list of frameworks and foundational libraries)

Yeah, Druid is being replaced by Xilem, but unfortunately Xilem isn't ready yet. So that whole project's in a bit of an awkward in-between phase where there isn't really any toolkit that can be recommended.

Third, we are discontinuing Druid proper. Years of experience has shown that people can struggle with the Druid data architecture and we can do better. This layer will be replaced by a new project called Xilem. We have spent a lot of time thinking about it and this decision was not taken lightly. You can read a more detailed post about the Xilem architecture but the gist of it is that we've found at a way to code UI in Rust that feels a lot more effortless than previous attempts. Xilem will look very intuitive to those familiar with state of the art toolkits such as SwiftUI, Flutter, and React, while at the same time being idiomatic Rust. Also we plan to port as many widgets from Druid to Xilem as possible, which should give the project a reasonable timeline to v0.1. Hopefully later this year.

You can use Rust with QML[1].

QML is actually pretty amazing. I've been building my block editor[2] view entirely in QML while the model is in C++. This separation of logic and presentation works great. And yes, there are some crashes sometimes (that I find quite easy to debug thanks to the built-in debugger), but take for example a similar app that's built with Rust and Dart[3], in my testing there were still memory leaks that caused my computer to hang. It's better to know you have a bug than for it to be hidden from you.

I agree with parent commenter, saying these cross-platform frameworks will end up supporting the least common denominator set of features. But I found with external open source libraries, the community is catching up very fast. For example, you want the awesome translucency macOS apps have for your Qt app? Here you go[4]. Many such cases. It's also pretty straightforward to add your own custom OS-dependent code, especially so, if someone already open sourced his approach. I recently wanted to move the traffic light buttons on macOS for my app, but couldn't figure the Objective-C code for that. I ended up looking at either Tauri or Electron source code and found my answer.

[1] https://github.com/woboq/qmetaobject-rs

[2] https://www.get-plume.com/

[3] https://www.appflowy.io/

[4] https://github.com/stdware/qwindowkit

I just used qmetaobject-rs and my experience with Qt/QML. There's the QML book from Qt if you're just starting, which is pretty nice https://www.qt.io/product/qt6/qml-book

qmetaobject is probably the most mature Qt Rust binding at the moment. It uses the cpp crate to embed C++ inline in Rust to create its bindings. There are some people using it and it does get some maintenance, but it's not under active development since the original author is now working on Slint.

The bindings currently use the git version of qttypes since I had to merge some upstream changes that are needed for these bindings. So they are not ready for prime time just yet.

There are a bunch of bindings with different language, but even the ones that are officially supported like PySide will still be second class citizen and awkward to use.

Automated binding generation will never give you idiomatic API in whatever language. And if you want an idiomatic library that wraps Qt, it's going to take a huge amount of work.

Which is why I think restricting to QML makes sense because that's a much smaller API surface. That was the ambition behind my previous crate that exposes QML to rust: https://github.com/woboq/qmetaobject-rs/

But now I've moved on to another GUI project: Slint https://github.com/slint-ui/slint

Whisperfish does this with Qt: https://github.com/woboq/qmetaobject-rs/issues/102

What do you want to know? It's pretty easy thanks to the amazing work of guys behind qmetaobject-rs.

This is probably the portion that I found the most difficult. The README of qmetaobject-rs gives us a basic idea of the build script, so I started with that. Here is my starting script