XAML or HTML?

Introduction (Windows 8)

Microsoft claims that Windows 8 is selling pretty well - some analysts claim the opposite. In the end it will not matter what a company or a bunch of external people will claim, but if people are willing to consider the change worth a look. There are some strong arguments in favor of Windows 8 - and I will just name a few of them:

• The system boots a lot faster.
• The system handles resources (memory, CPU) much better, resulting in more performance and a longer battery lifetime.
• With Windows 8 essential tools are already integrated like an ISO (or image) mounter.
• The task manager has been improved and there are new dialogs with useful options like the new copy / move dialog.
• Of course IE 10 is already included out of the box, which is just enough for the modern web (IE 9 on the other hand is such an outdated browser that I consider it as useful as IE 7).
• The possibility of syncing all your settings in combination with a live ID. This simplifies a lot of processes and I can imagine that this will be strengthened even more in the future (like Skydrive being integrated completely and not as an external program).

This all being said I never mentioned the new start screen (formerly start menu). In my opinion this is also a plus, since I realized that I only used the start menu for searching (enter a search query and press enter once I typed in enough letters such that has been just a single result). Therefore I focused completely on a little fraction of the screen. Thus the results had also just a tiny bit of space, making large result sets pretty much impossible to investigate. Now this is all much better. Also the overall overview is great and I get a lot of information presented right away.

But now that's it! There are also disadvantages and I will not write any line about those. In general all my hates are mostly in the direction, that the "two worlds" have been implemented as such, but under one cover. I have my own ideas on how it should have been done. In my opinion that mix is what keeps people from buying Windows 8. There are much smoother possibilities and I will never understand why Microsoft had to do it in such a dramatic way.

I will now give just one option for improving the whole thing. Let the taskbar (from the desktop - in Windows 7 it has been renamed to superbar) STAY on the bottom of the screen (or in whatever position the user placed it) and stop making it desktop only. The desktop is one of the great advantages of the Windows system - why making it just another app instead of extending it? Why do Metro apps (YES - I call them that way, the same as I call JavaScript that way and not ECMAScript) need the full screen? A little bit of "chrome" wouldn't be a bad thing.

The right UI description language

Now to the topic... So basically we have three options:

1. Write a C++ app with XAML for the user interface.
2. Write a C# or VB app with XAML for the user interface.
3. Write a JavaScript app with HTML + CSS for the user interface.

The first options seems to be the way to go for performance sensitive applications like 3D graphics or extensive numerical computations. The second option should make porting existing LOB applications easy. The third option should make existing HTML5 web applications easy. Right?

Well, I would not focus on the language so much. For instance one can make a pretty cool 3D game just by writing all the necessary code in a (written in VC++) library and calling that library with some managed C# code. The same thing is possible with JavaScript (however, since JavaScript itself is already slower than C#, one should really find out if this is the way to go).

This leaves us behind with an ethnic question: HTML or XAML? In my opinion XAML is definitely NOT the way to go in such a scenario. I have my reasons for this:

• Only a subset of the XAML from WPF has been ported (Metro XAML is more like Silverlight XAML).
• There are some severe errors in the implementation. Just to mention one (which was driving me crazy for like 2 hours): Bindings with custom objects have to be done with the source type being set to object instead of the real (more specialized) type. There was no binding exception or whatsoever occurring, which made finding the error really hard.
• Some basic controls are missing in the XAML stack - like a DateTime picker.
• I dislike the ViewState manager. The implementation of this seems sloppy and requires too much code.

Those are just a few of the arguments. But I know that some people are highly in love with C# (as I am) and regarding a speed comparison (and also a development cycle), C# is the language to go. But wait a minute! What do we want to achieve?

Separation of concerns

The answer here should be: separation of concerns. So in such a context is does not matter if we actual do HTML with CSS or XAML. Also it does not matter if we specify some UI related code in JavaScript or C#, because we still want to separate our UI from the actual code. Therefore I propose the following:

• Write the actual model code and everything related in its own library - this one should be testable and contain all the model information. The library is written in C#.
• Create another library to create the wrapping of the (required) external functions from the model library to the UI.
• For the UI use HTML and CSS. The code behind will be done with JavaScript. Also binding can be done with JavaScript, but this is a little bit more tricky, since we require our own binding engine.

The last point seems to be in favor of XAML, but remember that (existing) JavaScript binding engines could work out of the box, if we would do everything in JavaScript. This being said: You can have it, but you are also free to develop your own C# to JavaScript binding engine. The last point is really appealing in my opinion, because it allows everyone to write a binding engine that just fits and simplifies the debugging process by controlling the complete data flow. The engine will be 4-layered:

1. One layer is of course the UI to value binding.
2. Another layer is the data to value binding (code-behind).
3. A layer is required for receiving (and sending) requests from the UI to the model - this one sits in the "wrapper-assembly".
4. Finally the last layer has to be implemented in the C# side. Here we have two options: If our models are in fact already ViewModels, then we can skip this step. Layer 3 has then just to be modified in such a way to read and write to all the available VMs and do the JavaScript wrapping. Otherwise we are implementing something different here. If we do want to keep the library free of the binding or VM stuff, then we could also implement this layer in the wrapping-assembly or consider having another library between the wrapping assembly and the model assembly.

The last layer gave us several options, but in my opinion having the ViewModels in the same library makes sense. One of the reasons for this is that unit tests should be performed on this as well.

TL;DR

So what are the conclusions? Microsoft did a quite good job on Windows 8, but Metro (again, I prefer that name) is only a half-baked solution. Picking the right language is quite hard in my opinion and is not as obvious as one could naively think. There are several reasons for JavaScript with HTML and CSS. Most importantly for me, the whole user interface is portable (you can easily use it in any HTML capable browser, in a real application or in combination with a certain framework), Expression Blend has a nice "data preview" mode and some of the essential UI controls which are missing in XAML are present. On the other side we will most probably need to do some wrapping, since C# should stay our language of choice.