back
14 comments
I'm looking forward to seeing how this pans out. I've been working on some WGPU based rendering code the last year or so, and in lieu of any truly decent UI libraries on the Rust side (no offence to the existing players) I ended up going the Electron route, since my code was already compiling to WASM anyway. I also explored going the imgui and Qt routes, but Electron felt the most fully featured and easy to use. Still, it's Electron.

I'm happy to see that Xilem is not blindly copying JS/Swift ideas (or 'adapting' them, as Raph says :)) but applying them in a way that feels very Rust native. They've been experimenting a lot the last few years and I really hope we're finally getting to that point where we go beyond experiments and into something useable!

Since you're using Rust, did you consider using Tauri instead of full-on Electron?
Yes, but at that time Tauri did not have support for WebGPU on MacOS. Also, the Electron community is substantially larger and since this is mostly a personal project speed of development and easy access to community forums were more important to me than things like install size.
There is also Slint
Well sure, there are a lot of different options. But I wanted to pick a toolkit where there were already a lot of UI components available and I would haven't to hand roll a lot of them manually.

For instance, my UI contains a node graph. Since I was using Electron I could simply use react-flow [0]. As part of my research I also implemented node graphs in both imgui and Qt and, while certainly possible, it is a lot of work to get all the interaction nuances right.

The main drawback of using Electron was having to do a lot of interop work, of course, but as long as I was mostly working on the UI side I had all the benefits of hot reloading, existing design systems to pick and choose (I ultimately picked Mantine [1]), etc.

[0] https://reactflow.dev/ [1] https://mantine.dev/

which is mainly designed for microcontrollers and doesn't support most accessibility or power-user features on desktop. For example their input fields are incredibly basic and seem to be entirely written in their high-level DSL which is foolishly ambitious.
There is accessibility using the Qt backend and I started working on accesskit integration, which should cover the rest of the backends. Yes, more work needs to be done there, but the architecture has proven that it works. Any help with accessibility is welcome, especially as I lack the experience of having to rely on accessibility features. I might miss some things that will be show-stoppers for people reliant on accessibility. Of course any help is appreciated, too ;-)

All the text handling code is done in Rust (or C++, depending on the backend you pick). Just the basic navigation between elements and such is done in our DSL. But yes, we need more widgets and more features for some of the existing ones. We are working on that...

Is there going to be a new "halo" project for Xilem, the way Druid was partially codeveloped with Runebender? I suppose Runebender itself might get ported to Xilem?
What's the status of Vello? Will we see a stable version by the end of the year?

Also, it'd be interesting to see how it stacks up against the new Rive renderer, which also seems to be promising in bringing vector graphics to the GPU workspace.

Vello is progressing well, it's most of what I spend my time on these days. I can't promise a date for a stable version, but I would say that for the most part we're on our roadmap.

I'm also interested in quantitative comparisons with the Rive renderer. My personal feeling is that the compute shader approach is more scalable than pixel local storage, but the latter does seem to perform nicely especially on Apple Silicon GPUs.

> Vello is progressing well, it's most of what I spend my time on these days. I can't promise a date for a stable version, but I would say that for the most part we're on our roadmap.

That's fantastic to hear! Really looking forward to it.