I’ve spent the last few days at the Microsoft //build/ conference where the first preview version of Windows 8 was shown (and everyone got a tablet PC, which I like, and – and this is going to be important for the rest of the post – has built-in 3G network).
I really quite like the new Metro-style UI for touch applications. I’ve liked the Metro UX framework from the start when it first came into view on Windows Phone 7. I’m not sure if it’s a good idea to go to the full-screen home screen for launching apps when in desktop mode, but that’s a different story, and you can still install Launchy anyway.
What I didn’t really understand was why JavaScript and HTML were integrated into the platform in such a deep way. You have three independent language systems for creating applications that use the new Windows Runtime (“WinRT”): native C++ code with XAML as markup, .NET with XAML as markup, and JavaScript with HTML as markup. Each of them is anchored into the system at the same level. Access to the WinRT is provided to each of these systems in a different way using “projections”: translations of type systems and conventions to make working with the WinRT feel like you did not. Repeat; JavaScript has been anchored AT THE SAME LEVEL AS C++ AND .NET.
Phase 1: Writing it off
Seeing actual code written in HTML/JS however was quite a downer. I had hoped for a more semantic way of expressing layout than XAML provides. XAML is basically a 1-to-1 representation of an object graph, while HTML expresses layout more as an intent. I normally find working with XAML a lot less productive than it should be. However, to make use of the controls that the platform provides, you need to drop concrete class names into your markup, making HTML for Metro-style applications more concrete than it should be.
As for JavaScript, there is an extra JavaScript library called the WinJS to provide access to platform specifics. And there are some: since an HTML application is, well, and application instead of a web site, it needs to care about process lifecycle and state management. It’s really hard to put this in words – do you know the feeling when something looks all reasonable, but just does not feel right? That’s it with me and the WinJS.
But my main problem with the whole HTML/JS stack was that I could not understand WHY. Everyone I talked to stated that the HTML path for building Metro-style apps existed so that web developers could bring their existing skill set and write great apps from the get-go. I don”t quite buy this. Because first of all, an existing skill set might not be so important. The enormous success of the iOS platform proves that if something is attractive enough, you even write Objective-C. I think it’s an underestimation of developers who master modern web site development when you assume they could not learn some C# or VB on a level that makes you perfectly productive at the level you need for UI programming.
And secondly, you actually have to extend your skill set anyway: WinRT controls, WinJS, process lifecycle management…
So what I concluded is that the HTML/JS stack was basically an oversized technological approach to solve the business problem that for the platform to succeed, it’ll have to launch with a fully stacked app store.
Phase 2: and then I got it.
I have two days left in California before I head back to Germany. I’m going to take a shower, pack my things, and drive south to the beach once this blog post is finished. Which will cause me my favorite problem: I tend to get lost. And the car does not have GPS.
But what I do have is a tablet PC with GPS and a 3G connection. So when I woke up at 4AM (the jet lag never left), I sat down and wrote myself a Metro app that displays a map full screen, and puts my current position into the center, and puts a pin at it.
And how do you display a Google Map? Yeah. Exactly. All you need is some HTML and JS. (I ended up using Bing Maps because it works better with the pinch-to-zoom gesture).
The thing that sets apart the HTML/JS way of writing Metro-style apps over using XAML markup is not that it’s easier to write, or yields better results. In fact, I believe that for larger apps, the robust type system and patterns like MVVM give .NET a clear edge.
HTML/JS Applications that integrate with web resources intensely have a lot less friction. You don”t need to write an adapting SDK to translate between a service like Maps. HTML and JavsScript are the native language of the web, and when you go there, it’s better to speak that language well.
