The state (& future?) of XAML - A summary of a summary

Last week I gave a talk to a room full of .NET MAUI developers about "Rethinking UI Code".

The talks at the conference weren't recorded so I wrote up some of the key details for anyone not there but interested. 

That write-up became quite long, so here's the very short version (because I know you're busy):

• Everyone agrees that XAML has issues but loads of people still use it anyway.
• There are ways to make XAML much nicer to work with, but few realize this.
• Many of these improvements can be made by treating XAML like you would any other programming language.
• C# probably isn't the solution you want unless you want to rewrite everything you already have.
• I have lots of tools that can generate code and make XAML easier to work with.
• I've created a prototype of a language (I'm currently calling ENAMEL) that produces XAML and so sits on top of existing tools and toolchains. This language helps address many criticisms of working with XAML.
• I've done this as a way to encourage further discussion about what's possible and what the future might hold. (Not because I have answers. But because I have lots and lots of questions.) 

Now that you're intrigued, you can go and read the full version here or as a series on LinkedIn.

Modernizing Your Windows Applications with the Windows App SDK and WinUI - Review

 

Note. I was provided a copy of this book for review purposes. ;)

This is the best book on the Windows App SDK there is.

Ok, pull-quote provided (and yes, this is the only book on the topic I'm aware of); let's get into some details.

While there's lots of helpful information in the book, and I learned some things, I still have some confusion.

To be fair, much of this is the fault of the WinAppSDK and not the book. Some things just aren't clearly defined. Microsoft's documentation and video explainers haven't cleared things up for me. Therefore, it's not fair to pick on this book for not being able to clearly explain something that just isn't easily definable.

That the book seems to confuse WinUI3 and WinAppSDK (or use them interchangeably) in places seems par for the course when it comes to this distinction. :( 

Additionally, things in the book feel like padding to make the WinAppSDK seem like it contains more than it does. I assume they're not included to pad the book (which has over 500 pages) but rather to make the book give the impression that there is more in the WinAppSDK than there is. For example, WinML and AI aren't specific to the WinAppSDK, and so a chapter on them seems out of place, or at least unnecessary, here. Combined with the WinAppSDK features that warrant only a basic description but no real detail or insight from the author magnifies the issue for me.

This book does what many technical books try and do, that's trying to sell the technology. I doubt many people buy a technical book to see what's possible with the technology, as many websites will give you the comparison for free. What's much more useful (in my opinion) is examples that show real-world scenarios. Compared to basic demos or vague descriptions of what to do and then pointing to the official documentation for more details. Where a book can go beyond the basics and show gotchas and tips for things developers are likely to encounter, it's much more valuable and for longer.

One concern I had about the book was how up-to-date it could be given; how close it came out to the release of a significant update; how long it takes to write a book; and the fact I've taken several months to finish reading it.

This is always an issue of printed books, and it's noticeable here. References to ".NET 5 or above" as the version to target when .NET 5 was out of support when the book was released are potentially concerning. There are also things claimed in the book that I thought are no longer the case. I now need to go and check myself.

Many code examples also don't take advantage of the latest C# language features. This leads to code that isn't as concise as it could be and distracts from what the book is trying to teach/show. In a book that's supposed to be about modernization, this stands out.

So, what can I tell you if you want to read this book (and if you want to know everything you can about the WinAppSDK, you probably should)?

If you're going to clone the repo with the sample code, beware of the very long repository name. Avoid the root of a drive to avoid MAXPATH issues.

Use the sample code repository to look at the code samples. This will help avoid issues with inconsistently formatted (& indented) code, long code samples that span over pages, and the typos I noticed (hopefully now fixed in the repo.)

Don't skip chapters. Read the whole thing. It says early on that you can skip the chapters that aren't relevant. The theory is that if you have a background in WPF and don't know anything about WinForms, you can skip the Winforms chapter. However, the WPF chapter refers to comments in the WinForms chapter, and the UWP chapter refers to the WPF one. I started by skipping on to what was supposed to be relevant to me but found it made much more sense when I went back and read everything in order.

I wanted the section "Building a Future-Proof Architecture" to be more than a brief introduction to the MVVM pattern. I've seen (and inherited) some very poorly put-together solutions that used this pattern. It seems particularly odd to have/need this chapter for all the developers coming to WinAppSDK from WPF or UWP (or Xamarin.Forms.) Although I'd probably note such a chapter as conspicuous in its absence if it wasn't included.

Similarly, I was concerned about the frequent references to the "proper way" of doing things. Almost all development frameworks, platforms, and SDK are nuanced enough that there is no single way of doing something right for all situations and circumstances. But, at 500+ pages already, I assume there wasn't the space to go into more details. :(

I know this might come across as a negative review, but I don't think that's a result of the book. It probably says more about me and my opinion of using printed books to try and communicate information about a new technology that is changing rapidly and the need for a publisher to get books out quickly.

There's gold in there if you dig for it, though. Such as the advice against using the built-in localization functionality. I definitely learned things from this book.