With the announcement the end of last week that Microsoft is decoupling Avalon from Longhorn and will make it backward compatible with WinXP and Win2k3 Server, I’m sure there are some out there that wonder what my take on it. First off, let’s get this straight, XAML does not equal Avalon. Yes you can use XAML to wire up Avalon objects, but XAML is there to wire up .Net objects, not just Avalon .Net objects. So what is my take on the news? Happiness and concern. I’m happy about the news because I will get to share the Avalon love with users of WinXP. I’m deeply concerned, because of the whole backward compatibility scene. IMHO, most initial impressions of Avalon will be via Avalon on XP, and that concerns me. I’m sure (but I have no inside info) that there will be some things that will not work on WinXP, and the phrase, “well, that would work if you were on Longhorn” is not one that either developers or users will be happy with. Either make it 100% backward compatible, or don’t bother. A 3rd party implementing XAML on WinXP can get away with that excuse, but not Microsoft, since in the customer’s eye they own the OS, so they can change it to work with XAML. The other thing that concerns me is the marketing aspects of Longhorn. For a year now we have heard all about WinFS and Avalon, and they were the 2 primary reasons for upgrading to Longhorn. Now that those perks have been removed the “why upgrade to Longhorn?” question needs a new answer and quick.
So, now that we have settled the XAML on WinXP issue, let’s get to the heart of the matter, why should developers care about XAML now? I’ve discussed this with a number of my colleagues, and here is my take on the problems with embracing XAML. Declarative programming (and that is what XAML is about) is all about reusing objects, not recoding them, and that has been the holy grail for programmers for decades now. You basically declare your facts (the state of the objects) and let the environment handle the details (think SOA). But almost all of the developers out there have been trained in procedural languages, not declarative ones, so we have created a procedural coding mindset, and until we (the community) do a better job getting developers to think declaratively, 80% of all Windows programmers will not truly understand XAML. If you don’t believe me, take a look at the average web developer. How many web developers out there really understand CSS and use it to layout their web pages? Is CSS a bit complex? Sure, but the big issue most web developers have with CSS is giving up the control of exactly where the UI elements should be placed, and trusting in the rendering engine to place it correctly. The same thing can be said for the majority of developers that use XSLT. How many times have you seen an xsl:for-each loop in XSLT when the xsl:apply-templates recursion style is a much better way to go? It’s all about control. The developer is much more comfortable controlling the looping, rather than turning that control over to the development environment. Luke, Trust the Force!
Short of sending everyone back to school, what can we (the community) do to prepare for XAML?
- Reevaluate the way you build/design systems. Question everything.
- Learn a new programming language (from the ground up). VB coders, you may want to learn C#, C# coders pick up Java (and it’s framework), C++, learn VB.Net.
- Don’t just transfer your bad habits to the new language, embrace the new language and re-learn your coding style. Then apply it to your main language of choice.
- Blog about your self-discoveries. It will help you, and others learn and grow as devlopers.
Oh, and if you want to learn about how we got to XAML, go back into pre-history and read Dino Esposito’s Element Behaviors in Internet Explorer 5.5 on MSDN. If you want some more examples (including ones with vector graphics), check out my Bar Graph and Angular Gauge examples, still available on my old website YettiePlanet. Then we have to go out and preach to the masses (via user groups and your local workplace).