There is some "experimental" support for code based UI composition in MAUI, but since XAML is it's primary focus, XAML probably leads design decisions.
I don't even understand why you say "hung up on", XAML is probably the only compiles-to-code UI API I've ever used that actually does what it says it does; I've used similar tools for other UI toolkits (Glade comes to mind), and they're trainwrecks, and I'd rather just use the API straight.
UI development tools aren't for programmers, they're for UI designers: UI designers are generally are bad programmers but good designers, but need to program somehow as part of their job, and UI design tools allow them to be part of the team without having to feel like they're second-class citizens.
You know what happens when we don't have working UI toolsets? UI designers do insane stuff like slap together some HTML, CSS, and JS, and don't care that the usability of that from either the end-user perspective or the programming perspective is absolutely awful.
Would you rather use Electron or would you rather use XAML? At least with XAML, it works, and when it doesn't work, it can be made to work. Electron is eternally unfixable.
IMO, UI development tools are often not good for anybody. Designers are much more productive using specialized UI design applications like Sketch, Figma, Adobe XD etc. Who is responsible implementing the design depends on the company/workflow.
> XAML is just a tool to allow you to describe UI API calls using XML in a way that flows well for both humans and external tooling.
Not in my experience. XML feels very unnatural to me. XML being natural for humans was a hype from twenty years ago that was never particularly true in practice. XML feels less natural (to me) than using a normal programming language to make same API calls. XML based UI development tools are also often very unreliable and clumsy.
Like Blend?
I've actually managed to make "UI in code" somewhat manageable by laying out my UI code in a tree mirroring the widget tree. One issue is waiting for rebuilds, another is difficulty navigating the "big picture" of my code, mapping between on-screen UI and code mentally or through an Inspect Element equivalent.
What do you think about QML?
There are some fluent extensions (for Xamarin.Forms and probably future MAUI) that help you build UI in declarative fashion with C#. Same extensions could be created for other frameworks.
https://devblogs.microsoft.com/xamarin/c-sharp-markup-for-xa...
https://github.com/VincentH-Net/CSharpForMarkup
For reusable custom widgets that can't be done with a static function, I create new classes with their own widget trees. Try to keep widgets composable and avoid inheritance if possible.
Hot reload is coming in .NET 6, so waiting for rebuild will soon be history.
I have no experience with QML so I can't really comment on that.
Maybe HTML?
With XAML I can make my ideas fly, with Web, despite doing Web since 1998, I rather let our designer do their magic with HTML, CSS, JavaScript, turning <div> into animated drop downs.
Issues with XAML:
- verbose
- static (not good fit for dynamic UIs)
- templating is unnecessarily complex
- contains code-like constructs (behaviors, convertors)
- being a separate language forces constant mental context switching when developing, which is bad for productivity. Tooling is more complex and breaks more often (like Intellisense issues)
The only good thing that XAML does is separates UI from the model, but you really don't need a separate language to do that.
What would you say are the benefits of XAML that warrant using another language for UI?
I think the main reason is they wanted a declarative language along side their imperative language. You don't necessarily need to recompile anything to get a layout drawn in an editor with XAML.
I like it because it's relatively easy to make half-decent-looking UI's that have excellent functionality. If you need bigger guns, there's some powerful libraries you can use for more polished UI's or you can roll your own with a lot of effort and a long learning curve. For corporate in-house apps, it's hard to beat WPF/XAML.
The same is simply NOT true for anything web-based. I see it is getting better with CSS grid. At least layout is becoming sane-r than the days of tables, flex-box, and bootstrap-everything. But you still have house-of-cards javascript library dependencies on a boat-load of complexity. I realize that the folks who do web-apps day-in-day-out see it differently.
I also remember the winform days when people could make ridiculously elaborate high-function UI's with breath-taking speed. These would look ugly and dated by today's standards (especially on today's high-resolution monitors), but that development speed, the ability to just execute what you want quickly, is sadly missing today. WPF/XAML comes close but that winforms speed is just gone. Unless you want to do winforms-- which you CAN if you really want to, along with wearing double-knit polyester pants with bell-bottoms.
I think the XAML stuff relates more to trying to make things move between devices more easily by using generic ideas like stretching, grid layouts, flows etc. I guess MS are still holding onto the write-once use anywhere ideal which has never made it particularly well in any stack.