Microsoft unveiled Windows 8 at the //build/ conference in September. Since then I've spent time seeing how to put together Windows 8 metro applications with HTML and JavaScript.
The following is all you need for a native Windows 8 Metro application.
<!DOCTYPE html> <html> <head> <meta charset="utf-8" /> <title>Hello App</title> </head> <body> <h1>Hello!</h1> </body> </html>
There are some other small administrative details, like a manifest file. And, the above application is plain looking without styles or colors, but it is a real, native Metro application. To the user, the product is indistinguishable from a Windows 8 application written in C++ or C#. In Windows 8, HTML (and its friends JavaScript and CSS) are first class citizens.
Contrast this model against other platforms whose creators tout the benefits of HTML 5, but provide second-rate support. Their users still demand native applications on those platforms because they can feel the difference between an application written in Objective-C or Java, and an application written in HTML, just like they can taste the difference between grandma's peach pie and a vacuum packed peach pie they bought from the bottom of a freezer bin in a convenience store.
The support for HTML 5 in Windows 8 is an impressive, bold move for Microsoft and also validates the capabilities of the new web specifications. When you build an HTML application in Windows 8 you can feel an amazing potential. Consider what web development would be like if we had flexible-box layout, grid layout, rounded borders, and box shadows 5 years ago. The gross domestic product of the planet would be measurably higher as developers and designers spent less time creating useless images, less time cursing three column layouts, and less time searching and hacking to vertically center text in a div.
CSS has a history of making easy things difficult (and that's without the troubles of IE6, 7, and 8), but all of the above scenarios are trivial with the new standards.
CSS animations and transitions are another pleasure to work with. Consider what's inside the following style rule:
.class { transition: all 1s ease-in-out; }
That's pretty much all the code you need to add subtle, realistic animations to an otherwise herky-jerky effect. Contrast this against the mind numbering amount of namespace infested XML required by XAML for simple animations.
It's not all about CSS, though. There is scriptable video, bitmapped graphics, and vector graphics. There's WebWokers, WebStorage, and a NOSQL database built in. Everything you need, including all the APIs of the Windows Runtime - the same API available to C# and C++ applications - is available to JavaScript, and that's where this post reaches a turning point.
Programming Windows 8 with HTML and CSS is a joy. Programming Windows 8 with JavaScript is . . . different. It's not that you can't use utility belt libraries like jQuery and Underscore – you can. You can even use a library like jQuery UI (but keep it mind that jQuery UI doesn't process touch events or produce touch-sized widgets, so it's not a good idea).
There was some other feeling that kept growing on me as I wrote code and browsed the samples. Code like the following (but don't read the code, just look at the shape):
The code is verbose. I don't mind verbosity, but noisy code is a pet peeve. The SDK samples for Windows 8 are noisy and often have consecutive lines of code stretching over 120+ columns. It looks like a wall of text.
Nobody wants to read a wall of text, much less comprehend it, debug it, and maintain it.
This is a difficult problem, because the Windows Runtime API is expansive and will grow. Namespaces are required, but there is no automatic and simple "imports" or "using" in JavaScript. What we'll need is an automated refactoring operation. "I see you are using the Windows.ApplicationModel.DataTransfer.SendTarget namespace, would you like me to alias that to a module-scoped variable named wads?" Yes!
I also don't feel comfortable with the built-in declarative data binding.
<span data-win-bind="innerHTML: productName"></span>
This approach easily avoids all 'flash of unbound content' problems, but it feels significantly different from every other JavaScript templating technology. Navigation is also cumbersome and complex. I was expecting some template loading and a pushState API based on the new history specifications, like every other one page HTML application, but there appears to be an entire API designed around the concepts of fragments, navigation, and state, and I find it difficult to wrap my head around the magic.
There are some good points in the JavaScript code. Modern practices are in play with the module pattern appearing in the default project template. There is a nod to ECMAScript 5 with "use strict" in the module scope. And, with the Windows Runtime offering only non-blocking asynchronous APIs, it's good to see the Windows JavaScript libraries implement the CommonJS specification for a Promise. Promises remove noise by getting rid of the "continuation tail of curly braces". I'll save details of that topic for a future post.
I'm impressed by Microsoft's implementation of the Windows Runtime, the bindings from the runtime to JavaScript, and the implementation of HTML, CSS, and JavaScript standards. Ironically, it makes me think more about the day when we are using all these new features to implement web applications (and finally retire support for obstinate, outdated browsers), and less about desktop development for Windows 8. Because …
I'm not 100% sold on Metro.
There are a couple challenges I see.
First, even though you are writing an application with HTML 5, CSS, and JavaScript, as soon as you take a dependency on Windows.Runtime you have at least some of your code tied to Windows. It's not a script you can send to anything but a Metro app on Windows 8. This in itself isn't a problem, because we can expect millions of machines to run Windows 8 in the future. But, right now the Metro sweet spot is tablets. All of the oversized, touch-optimized controls feel ridiculous when running on a desktop machine – it's a like drawing on high quality graph paper with crayons. Unless we get a way to put a Metro app in a Window, I think the success of Metro will depend entirely on Microsoft's success in the ultra-competitive tablet market. That's a wait and see game, and a game where many will hedge their bets.
Secondly, with regards to Metro and native HTML applications, I just don't see JavaScript programmers getting excited about the platform. I have flashbacks to the ASP.NET Control Toolkit when writing Metro code. It's heavy. It's noisy. It's a lot of ceremony surrounding little nuggets of essence. It's going to require some work to properly architect and design an application to hide the infrastructure details and promote maintainability.
Finally, on a personal note, the way the whole thing went down leaves me with a bit of a bad taste and a slight bias. For the last few years many people have been working hard at turning Microsoft into a "kindler, gentler" entity that listens to a wider community and addresses issues forthright. Then earlier this year came the "Silverlight is dead" whispers, followed an enforced silence, followed by more talk of dead platforms, followed by panicked customers followed by total silence. No, I haven't talked to anyone with a blue badge about this scenario, but I did have a mental imagine of Mafioso heavies roaming the halls of Redmond wielding clubs emblazoned with a Windows 8 team logo and holding people up against walls to demonstrate what might happen if they don't stay ... "on message".
And for what?
It's not that Metro is revolutionary. Metro primarily represents a shift in focus from the enterprise to the consumer. The languages, the development environment, the technologies – they've been with us for some time. You'll see many familiar controls and paradigms in Metro applications as it builds upon things we've been using for years (except in the case of the JavaScript libraries, where everything is written from scratch, and going through the Metro SDK samples you'd think the earth was devoid of any other JavaScript libraries that might possibly help build stuff for a web browser). It's the old Microsoft – the corporate giant that does everything right and doesn't need your help or feedback.
Hopefully that behavior was not a harbinger of things to come.
OdeToCode by K. Scott Allen
Subscribe
Twitter
Search
About
Learn C#