This story was written by Keith Dawson for UBM DeusM’s community Web site Develop in the Cloud, sponsored by AT&T. It is archived here for informational purposes only because the Develop in the Cloud site is no more. This material is Copyright 2012 by UBM DeusM.

Web and Native

A nuanced look at what native OSs and the Web OS actually offer to developers.

The dichotomy between Web-based and native apps is not absolute, and is getting less so all the time. Many of the apps we write will fluidly use both modalities.

We've seen a lot of ink and electrons devoted to the question of when native app development is most appropriate, and when a Web-based, HTML5 underpinning should prevail. Most recently our own Cameron Laird weighed in on the question. I wrote about the movement toward hybrid solutions last spring for our sister publication Business Agility.

Earlier this month Paul Miller penned a provocative piece in The Verge exploring what he calls Desktop 2.0 -- future desktop operating systems incorporating features that acknowledge that the PC is not the hub of our digital experience, the cloud is. Applications are already clients of the cloud, and Miller envisions the OS and the PC itself -- not the only browser -- evolving into a kind of "thick client" or "cloud captain."

Miller's speculation inspired a more detailed and nuanced technical response from Mike Hanson on his blog. Hanson is currently an entrepreneur-in-residence at Greylock Partners, a VC firm; he previously worked at Mozilla, Cisco, and Apple. In two successive blog posts under the overall title "What's special about the Web," Hanson details, in architectural terms, what distinguishes the Web platform and what are the strengths of native platforms. His analysis goes deeper than the considerations that are usually raised in a Web-vs.-native comparison, for example the greater interactivity and access to special hardware features enjoyed by native code.

Hanson describes the Web as a universal platform whose content can be displayed on any device. It is inherently on-demand and streamed so that applications have an "instant-on" quality. The Web is very strongly sandboxed: Hanson notes that anything violating a "load any page on the Web and it won't hurt you" security model constitutes a critical flaw that will trigger a security response in the "chem spill" range. Finally, between the mechanisms of the URL, the iframe, and Javascript, every application and most application state is both externally referenceable and internally embeddable.

Native applications, in Hanson's view, are enhancers of your device, enabling it to do entirely new things. Such applications, the best ones anyway, use your device to its fullest, maximizing the efficiency of their use of CPU, GPU, memory, network, and numerous other resources. Finally, native apps are discovered and distributed via brand, category, or keyword -- they are not searchable and discoverable by content, the way Web apps may be.

These distinctions lead to a list of considerations for when Web-based or native techniques might be most applicable. And in most cases, thinking from an architectural point of view about Web vs. native leads to the suggestion of blending the two in non-obvious ways: embedding the Web in your app and/or your app in the Web. Such architectural hybrids go well beyond the levels of interoperation enabled by cross-platform development toolkits.

I encourage you to take a close read of Hanson's thinking on the Web / native dichotomy. I guarantee you will end up thinking about these platforms in new ways.