I am very excited about the advances that XAML has made in the Windows 10 Universal Windows Platform (UWP) and I think a lot of that has to do with the Windows Shell team and the Office team embracing XAML for building their apps. The Windows Shell team especially is so focused on performance when it comes to fluidity of animations, CPU pressure, and memory pressure. The fact that a ton of UI in the Windows 10 desktop is using XAML is a testament to how far it has come, and clearly the Windows Shell team was very demanding, and that makes it better for everyone. I don’t even know how pervasive XAML is in Windows 10, but I have heard it is used for the Start Menu, Action Center, and the Date/Time popup, and I can see first hand that it is used for the Settings dialog, the Edge browser, the Store app, Xbox app, and a lot more.
This is quite a departure from when Windows 8 was launching and Steven Sinofsky and Julie Larson-Green were on stage and told everyone to use WinJS to build your apps, and the Store app, Bing apps, and many others were using WinJS. This came on the heels of the death of Silverlight, and XAML was DOA, much to the chagrin of C# and .NET developers feeling like they were being left behind. Many of the people on the stage back then are gone, including Steven Sinofsky and Jensen Harris, and others have changed positions such as Dean Hachamovitch and Julie Larson-Green. The new regime seems much more XAML friendly, which isn’t a big surprise since Terry Myerson is running the show and he was in charge of Windows Phone which primarily used XAML as its app platform.
Disclaimer: This next part is based on things that some of the presenters said at the BUILD conference, and I have heard none of it first hand one on one, so I take them at their word, and I apologize if I get it wrong.
One of the big complaints the internal teams had about XAML was that data binding was slow and memory intensive. XAML data binding uses Reflection at run time, which is very flexible but has some overhead. So the internal teams went back to the Windows SDK team and asked for help. At first they thought their recommendation might be to tell them to not use data binding, and wire everything up by hand (back to the standard operating procedures of the Windows Forms days). They finally came up with a better idea. To remove the overhead of Reflection, both from a performance and memory perspective, they came up with a way to move a lot of that overhead to compile time, using code generation. With this, compiled bindings were born. The performance benefits of using code to wire up data mapping, and the productivity benefits of data binding. Fortunately we all get the benefits, and these compiled bindings are now the preferred way to do data binding in Windows 10 UWP apps. I sincerely hope we see these in WPF too in the near future.
Another complaint was about the rigidity of Grid and StackPanel layout, and especially when it comes to responsive design. The solution to this one came from the Android layout system, and the RelativePanel was born. Instead of manipulating grid columns and rows and similar properties, now the location of elements can be defined by their relation to other elements, and this is so much easier to understand and use.
Additionally for responsive design (Microsoft calls it Adaptive UI), the very powerful and flexible (but sometimes very verbose) Visual State system of XAML has been streamlined and tailored to responsive design needs. Now you can easily trigger on screen size and use Setters to respond appropriately. New built in controls like the SplitView also help make it easier to make a UI that will work across multiple form factors.
In conclusion, if XAML is now good enough for the internal Microsoft teams, I am excited to see what we as app developers can make with it. It’s a new day for XAML and the future seems bright in Windows 10.