While it's rich capabilities enable you to implement everything you can dream of, doesn't the same hold for JS desktop apps? (+ they are cross platform)
I don't see the use case anymore...
It is brittle because XAML itself is a compiled language without the ability to step through or debug well, which means runtime errors in the object tree usually causes the entire app to crash with very abstract error messages.
it is complex because the language is supposed to be an object tree building mechanism and thus needs to be quite generic.
It is verbose because of the underlying abstracted data model. e.g dependency properties etc.
Compared to HTML, where the 'evolutionary' pressure to create a workable compromise is much higher.
I used to think XAML could be better if architected well, but the missing ecosystem and usage around it made it so, that HTML was and still is massively more productive.
This is absolutely untrue. Xaml errors can be caught like any other error, and most errors get swallowed rather than crash the application (which can cause some debugging headaches when things aren't rendering as you expect).
> I used to think XAML could be better if architected well, but the missing ecosystem and usage around it made it so, that HTML was and still is massively more productive.
I don't think html is massively more productive. I'm not even saying that WPF is so much better, but start debugging any reasonably large react application and you're just as likely to get into an unproductive quagmire.
On the other hand, the layout model of WPF is a lot easier than mastering html+css.
JS desktop apps still mostly don't work without embedding a browser like electron and that ranges from annoying (e.g. for size/memory reasons) to impossible (for things like a plugin where you have a constrained environment, need to launch instantly etc).
The middle ground is desktop js using system browsers, but it's pretty painful to do too.
When WPF came out there were quite a few very cool open source projects that built on top of it because it's really easy to extend WPF and build components for it. But then every two or three years MS announced a new framework so most of these efforts died out. When you look at commercial third party suppliers like Developer Express they have the same component in three or four flavors. this must be a huge and expensive effort to maintain.
I think the various name changes have been extremely confusing and created the perception of more "resets" than actually happened at the code and API level. They dropped the ball by not bothering to have a good compatibility and migration story across WPF->Silverlight->WinUI, but since Windows 8 they've been pretty good about maintaining continuity for WinRT APIs
So Microsoft learned how lazy devs are and how ignoring such advises contributed to bad perception of GUI apps, e.g. Swing, and forced everyone to code the right way.
It is relatively easy to turn async code into sync, if really required.
MS's market was full of amateur-hour developers because their platform (WP7) was weak and lagging behind, thus incapable of attracting the top tier of devs. And then they poured gasoline on that fire with a barrage of silly incentives that were ignored by pros but attracted even more beginners. Now, to put a cherry on that fine mess, they attempted to remedy their bad business decisions with a technical solution that damaged the one asset they really had - an advanced and ahead-of-the curve app-development story. One own goal after another, really.
https://blogs.msdn.microsoft.com/windowsappdev/2012/03/20/ke...
As for the rest, I only agree it was a big mistake not to have a proper migration path.
However, WinRT was anyway the result of Synfosky's team (aka WinDev) being on the winning side, after they won over Longhorn, so not so much .NET love was going on back then.
And we had to wait for iteractive releases of Windows 10 slowly fix all those mistakes.
Whatever their reasoning was it was just plain dumb, heavy handed and unrealistic.
They don't feel like the product that would come if DevDiv did their best to produce a sane UI framework. They feel rushed, semi-overlapping, half-finished.
I imagine it should be possible to make just one more xaml framework which is cross platform, and much better than WPF (and it's derivatives), and much better than the js alternative (Because of deployment, not least).
I'm not sure if there is any incentive for ms to put their weight behind it however.
Please elaborate?
You can add a design time view model to get compile time warnings(and autocomplete) about incorrect bindings.
Thank you. I've never been able to figure out if web layout is as terrible as it seems, or if I'm just missing something.
Once you spend the 20 minutes to learn the WPF layout algorithm, you can reason about why every element is located where it is, down to the pixel. To get there with HTML/CSS, I feel like I would have to memorize and recall a huge list of ad-hoc rules, and their combinatorial interactions. Usually I just give up and accept the mysterious 3-pixel gaps that seem to crop up randomly, and I don't even attempt complex layouts.
Maybe if Silverlight hadn't been such a deadend.