Microsoft is attempting to change more than itself. With Metro, it hopes to shift the rules of the programming across device platforms altogether. Yesterday I outlined how different Metro and Windows 8 are from the previous Microsoft programming approach. It is a radical departure and does give Microsoft the opportunity to stake out different territory than that occupied by Apple and Google. Today, I want to go into more detail and show you just how developer friendly the new framework could be.
I also want to introduce the idea that Microsoft is taking aim at the desktop to bring along the tablet and smartphone. For developers, Metro means write once and automatically scale across all three devices. This efficiency in tying the desktop/laptop to mobile devices may be just the hook Microsoft needs to generate broad developer community interest.
For the non-technical, you can skip over the code sample below. The implications of these examples are described in the text. However, for the more technical, it is included to emphasize the main point about simplicity saddled with proprietary. For everyone, there is also an assessment at the end of the impact Metro and Windows 8 may have on the enterprise. Let’s get started.
First class support for HTML and JavaScript
From a developer’s perspective, this is the most significant development. One can now build native Windows applications using HTML and Javascript, in concert with Microsoft’s extensive WinJS libraries.
Here’s a snippet of HTML markup in Metro (taken from this MSDN post):
Looks great, right? The binding will be familiar to anyone who has used Windows Presentation Framework (WPF) – it takes a bit of getting used to, but is an excellent, terse way of tying declarative markup to backend gluecode.
Back to the Walled Garden Approach?
However, what we do not get is pure JavaScript and HTML – the bindings along with the extensive references to 
Microsoft’s proprietary JS libraries brings me to this conclusion:
I love the focus on HTML + JS, but like most Microsoft development tools, it is Windows only. One can write elegant applications quickly across all MS-enabled devices, leveraging the broad knowledge-base and talent pool available for these well-understood web technologies. But that is where it ends. You cannot take a Metro app and deploy it to the cloud, to be run in any standard browser. You cannot run it with PhoneGap on iOS or Android natively.
Microsoft has once again chosen to embrace and extend a standard, creating one-way compatibilities. This wall around MS developers may help keep them and their applications in, but it also represents a missed opportunity by potentially leaving even more out.
Single API across all devices, that’s a unified approach
As much as this could be a barrier to adoption, this may also be the most compelling reason to get on-board with Metro for developers (and perhaps users as well). Metro apps are meant to scale up and down in terms of screen real estate and processing power. This means Desktop apps have considerations introduced such as apps being “backgrounded” that they previously did not, and UI idioms such as swiping and extensive gesture support that were once the sole province of mobile hardware. This convergence of tablet, phone and desktop does not seem nearly as much of a fait accompli to me as Microsoft (or Apple) would like it to be. It is impossible to imagine doing many jobs without a keyboard and trackpad.
However, for developers, it makes a stunning amount of sense; write once, and run anywhere Microsoft does. Microsoft Phone and Tablet products hold an insignificant amount of market share at this point, but certainly they are laying out some attractive bait:
Write a Windows Metro desktop app because most of your users are on PCs, and get a tablet/mobile app for free.
This bait becomes much more alluring if Microsoft’s tablet and smartphone market share rises. It’s a much more coherent strategy than Google has with Android where Android is smartphone/tablet only, and the Chromebook is their own internally-made, less well-loved competitor to the desktop. It is also a more attractive (and unified) development platform than OSX/iOS and Objective-C. Microsoft’s logic has the potential to be very appealing to IT departments.
Enterprises will like Unified Metro Approach
Microsoft has planted a bright, bold stake in the ground with Windows 8 and Metro. It is making the case to work on every type of device, with a single API, even down to the lowest end of the market with their newly added support for ARM. At same time, the team from Redmond has done it in fairly typical fashion as their first-class HTML/JavaScript support also involves a great deal of propriety interfaces.
I believe Microsoft has made a very good case for enterprise support. Organizations are going to be writing or at least using Windows Desktop apps anyway, so why not bless Windows 8 Phone and Tablet devices as well. The desktop apps will run on them for free. When you look at how the new Microsoft Surface blurs the lines between laptop and tablet and resembles a business more than consumer-oriented device, the strategy seems coherent.
I do not see this as much of a threat to Apple in terms of marketshare and developer engagement. The iPad and iPhone are just too dominant today. However, the Metro / Windows 8 approach does look like a good way for MS to shore up control of the desktop as well as erode Google’s enterprise and consumer positions. This all is being done in classic Microsoft form: appealing to developers with excellent, highly productive tools focused on delivering customer value. Only this time, with a bit of panache.
What do you think? Will the unified Metro approach be a winner? Comment below.
Related Reading
