Blitz: Custom renderer (Skia?), Stylo (CSS parser), HarfRust (font shaping), Skrifa (font parsing), Fontique (font selection), Parley (line breaking) - as separate projects

Azul: WebRender 100% (CPU and GPU rendering), azul-css (minimal CSS parser), rust-fontconfig (a "minimal rewrite" of fontconfig), allsorts (font parsing / shaping), azul-text3 (line breaking / justification) - more-or-less monorepo

Dioxus: RSX macros, stores data and function implementation as strongly-typed data

Azul: Uses C function callbacks + "RefAny" type-erased dataset (some internal unsafe code)

Dioxus: Uses hot-patching for updating binary, uses macros, likely only ever Rust-only

Azul: Uses a DLL for faster link times, separate "HTML/CSS to Rust/C/Python compiler" step (separate optional build tool with live preview), no macros, C-API as first-class citizen

Dioxus: Funded by YC, not sure what the upsell is long-term (commercial support?)

Azul: Funded by donations (once it's ready enough to promote) and by my Maps4Print cartography startup (dogfooding)

For example, Azul uses a custom CSS parser because the CSSProperty is a C-compatible enum, so that later on you can compile your entire CSS to a const fn and use CSS strings without even doing any allocations. So even on that level, there's a technological-architectural difference between Azul and Stylo.

But the core point is more architecturally: Azuls architecture is built for de-coupling the user data from the function callbacks, because I see this as the Archilles heel that all GUI systems so far have failed at:

https://github.com/fschutt/azul/blob/master/doc/guide/02_App...

Dioxus however repeats this exact same pattern again, and even the Elm architecture doesn't really fix it. I didn't finish the document but basically there is a (1) "hierarchy of DOM elements" and a (2) "graph of UI data" and those two are not always the same - they can overlap, but the core assumption of many GUI toolkits is that (2) is a tree (it's a graph, really) and (2) is always in the same hierarchy as (1), which is why GUI programming is a pain, no matter what language / framework. Electron just makes the visual part easier, but then you still need React to deal with the pain of data model / view sync.

I can collaborate on the flex / grid solver ofc, but it's very hard to collaborate on anything else because the technologies used, the goals, the architecture, etc. are very different between Dioxus / Azul. Azul is more "monorepo-NIH integrated solution" (because I often got bug reports in 2019 that I couldn't fix because I didn't own the underlying crate, so I had to wait for the maintainers to do another release, etc. - I learned from that).

As a note, the layout engine is also now heavily vibe-coded (sorry not sorry), so I don't take credit - but feel free to take inspiration or copy code. Gemini says the solver3 code is a "textbook implementation", take that as you will. My idea was to build a "AI feedback loop" to semi-automatically put the HTML input, the debug messages (to see what code paths are hit), the source code and the final display list into a loop to let the AI auto-debug the layout engine. So that part of writing the HTML engine isn't really hard, assuming the plan works out. The hardest part is caching, scrolling, performance debugging, interactions between different systems, and especially supporting the C API. Layout is comparably simple.

- This first one includes Bevy inside a window setup by Dioxus Native (using a `<canvas>` element similar to how you might on the web). Here the event loop is controled by Dioxus Native and the Bevy game is rendered to a texture which is then included in Blitz's scene. https://github.com/DioxusLabs/dioxus/tree/main/examples/10-i...

- This second one does it the other way around and embeds a Dioxus Native document inside a window setup by Bevy. Here the event loop is controlled by Bevy and the Blitz document is rendered to a texture with which Bevy can then do whatever it likes (generally you might just render it on top of the games, but someone tried mapping it into 3d space https://github.com/rectalogic/bevy_blitz) https://github.com/DioxusLabs/dioxus/tree/main/examples/10-i...

The latter is probably what I would recommended for game UI.

Both approaches probably need more work (and Blitz could do with more complete event handling support) before I would consider them "production ready".

Time will tell if that will be a big problem or if more mainstream ways of doing things are better for a project intended to run everywhere!

What's interesting is seeing a few non-Apple WebKit browsers pop up, like Orion (Kagi) and Epiphany.

Call me cynical, but I don't see Ladybird or Servo do much beyond making a splash. Browser engines take an incredible amount of dev hours to maintain. Ladybird is hot now, but what about in a decade? Hype doesn't last that long and at that point the money and a chunk of the dev interest will have dried up.

Blink and WebKit both have massive corporations championing them, so those engines do not run that risk.

How big is Ladybird?

[1] I believe you can make Electron smaller by cutting parts of Chromium out, but the default is around 100 MB