It's only relevant because it explains why this WinUI3 is still using XAML, even though XAML is extremely painful to work with (it's verbose; it mixes content, presentation/style and behaviour in the same XAML document (they learned nothing from HTML+CSS... which makes sense because WPF was designed around 2003 when IE6 was at the peak of its dominance), the built-in layout controls are anemic and have now fallen way-behind CSS's layout functionality, and so on and so forth.
What Microsoft should do is snapshot a recent revision of CSS and make that the basis for the style and layout of XML or JSON-based structured documents, and then extend it where appropriate. Like it or not, eventually all layout systems are all going to become alike in the end (be it a desktop GUI system, web-page HTML+CSS, WPF/Jupiter/XAML, Qt, Apple's constraint-based layout system, etc) - it feels like a waste of resources to build yet another layout system (or in this case: trying to squeeze more life out of XAML and whatever WPF's latest descendant is called). Remember that using CSS does not mean having to use a web-browser engine, or using JavaScript, or even HTML - CSS was designed from the start to be agnostic to the types of documents and environments it's used in.
You can definitely move templates and styles to other files and reference them from there. You can do that to pretty much any XAML element. XAML is actually a compilable-to-ILR markup unlike HTML/CSS/JSON that need to be interpreted.
I don't see how HTML/CSS does anything any better, XAML is verbose, but the tooling takes care of most of it.
>I don't see how HTML/CSS does anything any better, XAML is verbose, but the tooling takes care of most of it.
CSS's modules for layout are far more advanced than WPF/XAML/WinUI. Never-mind the more brain-dead aspects of WPF/XAML/UWP like `<border>`, WinUI only has <Canvas> (absolutely positioned elements), <StackPanel> (similar to CSS's flex-box, or normal block layout), and <Grid> (which is much closer to HTML <table> than CSS `display: grid;` in terms of capabilities) - all other layout systems have to be done by hand - which requires a deep understanding of WPF/XAML's layout system internals - and who wants to invest the time in that when there's still uncertainty about the supported lifespan of WinUI?
I've noticed that Microsoft only commits to supporting a UI framework when at least one of their major products relies on it (which explains why WinJS became irrelevant, _fast_, while MFC and WPF are clearly here to stay (I note that Microsoft has only one major product relying on WPF: Visual Studio - literally everything else uses some non-public UI platform like DirectUI (Office) or MFC.
Only a small number of programs and utilities that ship as part of Windows uses WPF. Windows has more WinForms-based GUIs in it than WPF-based GUIs.
It’s a far cry from the Longhorn demos of 2003 that showed the entire Windows UI been made with WPF, and Explorer itself hosting third-party applications’ WPF components.
Yeah, I meant WinUI/UWP XAML. Starting with 8.1 it's been the standard for any new or overhauled Windows shell UI, along with the built-in apps. As you mentioned, this was the original intention for WPF, and the failure of this plan (which the Windows team largely attributed to the dependency on .NET) was the main reason WinUI/UWP and WinRT came about in the first place (as basically a do-over of the Longhorn plans, but ditching the .NET dependency to build on COM instead). So it succeeded at getting Windows to adopt it (at least for a while - apparently in 10X they are starting to use web tech for shell pieces like the new Start menu, although I think the actual window manager itself is still XAML based), while WPF failed.
