Wednesday, August 22, 2012

Contrasting Windows 8 Development in HTML5/JavaScript with Web Development

One of the nice features of Windows 8 development is that WinRT, the Windows Runtime, permits apps to be developed in HTML5/CSS/JavaScript (the other two choices are .NET/XAML and C++/XAML). If you're involved in modern web development, the HTML5 approach may be attractive to you. There are however some differences between HTML5 web development and Windows 8 development you should be aware of.

1. No Need for Cross-Browser Support or Feature Availability Checking

In a standard modern web app, you've got to deal with the reality that users will use different browsers (and different versions of those browsers). This is usually handled with shims and polyfills (especially Modernizr) and specific checking for browser features with fallback behaviors.

In Windows 8 development, there's only one target browser: IE10. There are no other browsers to be concerned about. You can also freely take advantage of IE10-specific features, such as CSS Grid, that you might have been hesitant to use in the past because they weren't supported broadly enough.

2. External References are Disallowed

It's common in web apps to reference external stylesheets or scripts, especially to access open source JavaScript libraries via CDNs. In Windows 8 external references are disallowed as a security risk. This means your stylesheets and scripts must be local to the application.

3. Some DOM Operations are Disallowed

It's rather normal for modern web applications to manipulate the DOM, for example to set the innerHTML property of elements. But WinRT is picky about allowing this, and you just might get an error like this:

HTML1701: Unable to add dynamic content ' a' A script attempted to inject dynamic content, or elements previously modified dynamically, that might be unsafe. For example, using the innerHTML property to add script or malformed HTML will generate this exception. Use the toStaticHTML method to filter dynamic content, or explicitly create elements and attributes with a method such as createElement. For more information, see

Don't fret, you can modify the DOM as long as you following Windows 8's rules, which are described here. This can in fact stop popular JavaScript libraries from working. To make jQuery work, you need this work-around.

4. There's no server - and no 'home domain'

In a standard web site, you have a server and your Ajax calls are pretty much restricted to that domain for security reasons. In Windows 8, there's no implicit server and therefore no implicit domain. You can freely perform Internet access using the WinJS.xhr method.

This doesn't mean you can't have a back-end, you certainly can (and Windows Azure is a particularly good choice for your back-end services).

5. A Windows 8 App is Not a Web Site

Although you can transplant a web site into a Windows 8 app without too much trouble, you need to be conscious of the differences between a Windows 8 app and a web site. A Windows 8 app has certain standards for styling, user interface, behaviors, security, etc. that must be conformed with in order to be accepted into the Windows Store. Windows 8 apps have special artifacts such as the App Bar and Live Tiles which you'll need to add.

Having said that, there is plenty from the web world you can apply to an HTML5 Windows 8 app. You can use many of your favorite libraries and frameworks, including Twitter Bootstrap for responsive web design that adapts layout to various form factors and orientations.

6. Windows 8 Apps Have a Specific Lifecycle

A Windows 8 app that holds state needs to be able to quickly save that state when being deactivated by the operating system, and likewise restore it when revived. You'll need to include JavaScript code in events such as onactivated to handle this.

7. Windows 8 Apps are Sandboxed and Require Use of the WinJS API

Windows 8 apps are sandboxed, meaning they can't do much on their own except when you go through the WinJS API. The WinJS API provides many methods which you'll have to use in order to perform communication, get user information, share with other applications, and access resources managed by the operating system such as file storage or contacts. Some things which you might be used to handling in other ways must use the WinJS API in Windows 8, period.

8. Touch Needs to be a First-Class Consideration

If your past web development hasn't focused on touch support, it will need to in Windows 8. This is more than a finger touch equaling a click event: Windows 8 users expect to be able to use swiping and other gestures. Not everything you do in HTML5 will automatically work with touch; for example, HTML5 Drag and Drop works with a mouse in Windows 8 but does not respond to touch. You'll want to ensure touch is well supported by your app and of course you don't want to forsake mouse and keyboard users either. Take advantage of the Windows 8 Simulator in Visual Studio 2012, which can simulate touch if you aren't developing on a touch-capable machine.

So what' s the bottom line on Windows 8 development in HTML5/JavaScript? It's certainly viable, and can allow you to transplant existing markup, CSS, and code--and use many of  your favorite frameworks and libraries--but the aforementioned considerations will need to be dealt with. Ultimately, leveraging your web skills in Windows 8 development is useful but a Windows 8 app is not a web site and it's a mistake to forget that. A satisfying Windows 8 app--regardless of which language path you use to develop it--must conform to the conventions and spirit of the platform.

No comments: