Evaluating Rust's Azul Crate

Introduction

As part of the effort to survey Rust's current desktop GUI crate offers, I opted to evaluate each target as a separate blog post. I originally had them all in one blog post, but that got very long, very fast.

So today, we'll be focusing on evaluating the Azul crate. If you want to play with it and form your own opinions before reading mine, you can find out more on their GitHub page, especially the wiki. I found that their webiste and crates.io listing to be not well maintained, so I wouldn't recommend starting there if you're looking for documentation.

Testing Starter Code

The first thing I noticed is that the guides suggest you link to their GitHub project instead of a specific version number. In my admittedly limited Rust experience, that implies that the crate is not yet stable. IMPORTANT: At the time of writing this, the version number listed on crates.io appears to be out of date. The sample code from the wiki's Getting Started section failed to compile whether the azul dependency was listed as azul = { git = "https://github.com/maps4print/azul" } or azul = "0.1.0" but had significantly more errors to work out in the former.

As implied above, I find it helpful to start any crate evaluation by compiling their provided starter code to see if that compiles cleanly. Unfortunately, the minimal starter code fails this test. For posterity, I will post the code and error I received below.

extern crate azul;

use azul::prelude::*;

struct MyDataModel { }

impl Layout for MyDataModel {
    fn layout(&self, _: LayoutInfo) -> Dom {
        Dom::div()
    }
}

fn main() {
    let mut app = App::new(MyDataModel { }, AppConfig::default()).unwrap();
    let window = app.create_window(WindowCreateOptions::default(), css::native()).unwrap();
    app.run(window).unwrap();
}

λ cargo run
   Compiling webrender_api v0.60.0
error[E0433]: failed to resolve: could not find `IoReader` in `bincode`
   --> C:\Users\JR\.cargo\registry\src\github.com-1ecc6299db9ec823\webrender_api-0.60.0\src\display_list.rs:270:35
    |
270 |             let reader = bincode::IoReader::new(UnsafeReader::new(&mut self.data));
    |                                   ^^^^^^^^ not found in `bincode`
    |
help: consider importing this struct
    |
5   | use bincode::de::read::IoReader;
    |

error: aborting due to previous error

For more information about this error, try `rustc --explain E0433`.
error: could not compile `webrender_api`

To learn more, run the command again with --verbose.

We can be generous and say that the compilation problem lies with the webrender_api crate, but I also hold any project responsible for the dependencies it opts to use. A quick check shows that I am not the only person experience this issue. How frustrating, but at least some people have found some workarounds - so let's try them out:

1. One user suggested that switching your GitHub dependency to the wip branch would resolve this issue. Sadly, this did not work for me on either my Windows or OSX machines - using stable and nightly toolchains. Instead, it spit out an error involving the include_bytes! macro. I could invest time looking into this, but since a wip branch is inherently unstable, I figure it would be more productive to try one of the other fixes.
2. The next recommendation suggests changing the webrender dependency to a wildcard in cargo/azul/Cargo.toml. That changed nothing. I noticed that webrender was actually on version 0.61.0. Setting the dependency to that literal also had no impact. This wouldn't have been ideal anyways. I don't want to have to vendor 198MB of dependencies just to adjust one line on a Cargo.toml anyways.
3. Another user suggested a forked fix listed here. Sadly, after re-vendoring and changing my dependency configuration, that didn't fix it.

Tabling

At this point, I'm tabling the azul evaluation to try other crates. There's so many options available that it is not worth investing in more time trying to get azul's own sample code to work. It's a shame, because the model they have for their framework seems perfectly reasonable. That said, it relies on a web rendering library for a desktop application. I likely would have picked something else on principle.