From the Azul maintainer:
I don’t know if Azul is the right choice for amethyst - but if you want to use Azul for developing a game engine, please render the game in a seperate window . Which would solve the “Vulkan, DirectX, etc.” issue - you can render whatever API you want in your window and communicate between the editor and the game via a channel or via IPC. And for shipping the game, you simply disable the editor and let the game run as a standalone executable. You don’t need to port webrender to every backend API. And don’t use Azul for rendering the in-game UI, this would destroy performance (and lead to bugs because Azul may not clean up OpenGL state). Azul is currently too slow to be injected into a game loop, plus it is retained-mode (i.e. it only redraws when necessary), so it would be good to use for the editor UI, but not the game UI.
At least in my experience, it makes little sense to bikeshed which UI framework to use - try to build a prototype instead. Experiment. See how far you get with Azul, OrbTk, GTK, Qt, etc. in a weekend and then you’ll have a better understanding of which framework fits your usecase better. I.e. just build the most basic game editor you can imagine, try to render a list of game objects, a tree view, the actual game, a list of assets, a code editor, etc. And then record how long it takes to code each component and see which framework is best. Then, and only then you’ll be able to estimate how long it’ll take for each framework implement a game engine editor in. You can argue about the merits and drawbacks of each approach until the cows go home, but that won’t lead to anything in the end. Often you only run into issues when you’re building it, so my best advice is to just build a simple prototype of the same UI in each framework, that’s really all I can say.
In your position, I’d wait a year or so and try to focus on other issues - unless you are set to use GTK or Qt, there is currently no “mature” UI toolkit in pure-Rust.
As a general comment to the statements in that quote, I’m evaluating frameworks not based on how ergonomic they are, but rather based on what potential they carry for the future, both in terms of features and maintenance on the editor.
My take on Azul is basically that it’s awesome that it uses webrender with all it’s benefits in terms of layouting, styling and more. My concerns are that we won’t be able to see it run on Vulkan any time soon, that the rendering model may not work for us currently when we want to render every frame and that the application state could eventually become a little bit unwieldy especially as Azul seems to have quite strict requirements of what can be on the heap.