before i decide to making it i went shopping on crates.io first, here is my feeling:
egui: easy to write, no architecture to fight, just call and draw. but i have issue with the state management. iced: i am really not good with Elm's style. gpui: in the last two years, it has less documents, i need to find the example at the Zed's source code. dioxus: it's cross platform and declarative ui style but with macro, also i have to "fighting" wtih my IDE when i missing one '}'. slint: i need to learn another DSL for writting the UI, but their hot-reload is really nice.
My development is started when i found skia-safe at crates.io, but later on i meet the problem with cross-platform compilation, so i decide to write my own render engine using wgpu.
After almost one year of development, i have get the benefit from the Rust's trait and type system, my ui can be declare with builder pattern like this:
I really satisfy with building pattern, i have using it to build my first website into WebAssembly and rendering inside the H5Canvas powered by WebGPU or WebGL.
What was your problem with Xilem? Well, currently no full-time developers and financial support, but I still think it has strong foundations, e.g. Vello for drawing, Parley for text.
Might be a serious omission. Xilem was created by thoughtful design, I think its predecessor was Druid and others. Its main author Raph Levien is very smart and productive. But he recently moved to Australia, working for a new company. And I think a few other workers, which have been paid to work on Xilem in the Past, are not any longer paid. So further development of Xilem might be insecure. Still, whoever is interested in creating one more Rust GUI toolkit might benefit from studying Xilem and its components. I used Xilem as one of my chess GUIs, see GitHub - StefanSalewski/xilem-chess: First Xilem GUI for the tiny salewski chess engine · GitHub
Wow, it supports Android. I'll try it once it's stable because GPUI doesn't support Android yet
Is the incremental compile speed fast? For the convenience of editing the appearance because it requires viewing the results
I have an extreme idea to achieve a pleasant development experience for quickly viewing the edit result without purchasing a high end device. For the development process, transpile the code into HTML, CSS, and JavaScript. This will provide instant JavaScript compilation speed. The flow is as follows
Create a custom CLI to automate this. The CLI will do the following:
First, run cargo check
Then, transpile the user's Rust code into HTML, CSS, and JavaScript. The transpile speed is very fast, even with just one thread (I have created a transpiler project, it runs fast), much faster than creating a binary
Then, run the transpiled code (HTML, CSS, JS) so the user can see it on the web. This will also be very fast, even near instant
The difficulty is how to transpile Rust code that doesn't have 1:1 support from the JavaScript side. For example, if the user logic uses a spawn thread, you can change it to a spawn JS worker, but for third party library code, you can't know what kind of functionality the user will use to find similarities. However, it's possible if it's just UI
The incremental compile speed is slightly long at first compile and it's around 2-3 seconds after that. I also provide the CLI tools for automated process too. it would look like this:
also the app it's self is lightweight and render using native graphic API, so it no need any browser. for android just need the `adb` and pair with device is ready.
What kind of machine specifications did you use to test it? The CPU, RAM, and OS
My extreme idea is only for the development process. For release builds, it's the same as compiling a normal Rust system to native without a browser. Because my bottleneck for creating a GUI in Rust is incremental compile speed, and very fast speed is essential for an enjoyable UI editing process. With that idea, the user can also see the UI result without setup, since all platforms support web out of the box. But there's part that doesn't have a suitable equivalent, as I mentioned earlier
Also, I like the CLI feature. The doctor command is obviously very helpful in finding the cause of problems. You can also add the setup command, which will install and setup platform dependencies, save them to the passed folder, and then automatically add them to the Path variable. This makes it very easy to get started, for example, the user just run
cli setup the_folder_name
For those who already have some OS dependencies but are missing something, you may able to add 'cli fix setup' to complete cli doctor
mostly no need any dependencies if you are building app for your platform, unless you are targetting mobile. also the `setup` may corrupt the user's development environment. so i prefer let user setting that manually. also user just press `r` to rebuild and run the app.
What I mean dependencies is like, Android SDK, and configuring it to make it work with your framework
The setup command is setup from scratch without any existing Android dev setup, like downloading Android SDK, Android platform tool from scratch and then configuring the bridge like path setup, etc. It does not corrupt anything because there is no existing setup to corrupt in the first place
The command fix is to auto fix if some deps are missing based on the command doctor. It is possible to do this without corrupting the setup, because this is just an indirect runner for the normal Android setup fix
The Source code of it you can find at https://github.com/Cottons29/rust-forum, currently is too early stage for RustForum. i am just testing my framework by building it.