Disclaimer : As a reminder, this post represents only my own personal opinion and is not presented as an endorsed or official position by anyone but myself.

Few evolutions of developer technology have resulted in as much discussion and speculation as “HTML5”.

In this post I’m going to write about building APPLICATIONS with HTML5, not sites or pages.

Two weeks ago I was in London at the Apps World Conference where I witnessed an interesting dichotomy.  The few HTML5 sessions were PACKED. There wasn’t even standing room left. But, almost every other session included commentary to the effect that HTML5 is “nor ready for prime time, though it is going to be really important in two or three years.

If you’re a cross platform tools vender, out-source developer, or consulting shop working in the mobile application space, then that’s probably what you want to believe. (Or at least what you want the industry to believe.) If you’re a  “native” developer you’re probably in the same boat.

I’ve talked to many “Native” / desktop application developers over the years who just don’t like the “Web Stack”.  They tend to discount HTML5 out of hand.

You hear one liners like :

HTML5 Apps can’t get good performance.
JavaScript sucks !
You can’t access the necessary hardware in HTML5.
You can’t optimize battery life in HTML5.

There is no question that there are some kinds of applications that you would not try to write using Web development technologies. You wouldn’t write Adobe Photoshop, Apple Final Cut Pro, or Audacity in JavaScript for example.

But I believe there are LOTS of applications that can be written in HTML5 / Web technologies and that there are significant advantages to doing so when your application scenario makes a Web stack appropriate.

Lets first fix what I think is a problem with the vocabulary.

“HTML5” is not really HTML 5.0. “HTML5” is a wave of technologies of which version 5 of the hypertext Markup language is only one part.

You can read the W3C HTML5 Draft Specification here : http://dev.w3.org/html5/spec/

While the HTML5 specification enhancements are important we, should be equally interested in the work being done by the What Working Group – http://www.whatwg.org/

But to get the whole picture we need to consider other evolutions in web technology as well.

There is the CSS3 specification – http://www.w3.org/Style/CSS/specs which is part of the wave.

I also think that jQuery is in important part of the piece, especially now that browser venders are leveraging the performance experience of other scripting language makers and building significant optimizations into their respective “Web Stacks”.

So, in this post I will refer all of the technologies that we would use to build a Web Standards Based Application collectively as “The Web Runtime”.

Before I start to talk about what we can to with The Web Runtime, let me suggest that none of the corporate entities will want you to believe that you can build great  applications that will thrill customers by using only standards based technologies.

Why ? Because web technology runs on every platform that matters, is not controlled by any single entity and can be delivered by a wide variety of mechanisms.

Apple wouldn’t be thrilled by the success of The Web Run Time. Apple changed both the phone and the information industry with iOS, but their sustained success is, at least partially, predicated on the head start they achieved by being first to the market space.

While (in my opinion) iOS, as a device operating system, is still slightly better than Android at this stage of Android’s evolution, it is only marginally so and Android is evolving rapidly. What’s more, the iPhone is no longer the number one phone from a hardware perspective.There are many Android phones that are more advanced. (Like the Galaxy S2 Skyrocket). Apple can’t innovate on the hardware as quickly as the entire phone and tablet manufacturing industry and folks have angst over whether or not Apple can keep up with the pace. Expected announcement of the iPhone 5 this fall never materialized.

Still, the iPhone is staying strong in the market because the “Apps” are there. iOS is a proprietary platform. Apps that run on iOS do not run anywhere else. For most consumers, the only way to get Apps on your iPhone or iPad is through the Apple store where Apple gets a good percentage of the purchase price, subscription fee or in application purchases. (Yes, we geeks can jailbreak or iPhones, but that does cause other concerns.)

If Web Runtime Apps started to enjoy adoption Apple would loose it’s head start as well as it’s monopoly on the sales and distribution process. Developers could build an application once and consumers could run that app on whatever great bit of hardware they wanted. Moving from one platform to another would be FAR less painful.

It’s been suggested to me that the performance of HTML/JavaScript in Safari on iOS has intentionally been made slower than it needs to be in order to help maintain the disparity between “Web Apps” and native iOS apps.

Microsoft probably wants “Web Runtime” applications to succeed even less.

Though Microsoft has more than one profitable product, Windows is still the mainstay of Microsoft’s revenue stream and the combination of Windows and Office (which has almost no success outside of Windows) probably still represent more than half of Microsoft annual revenue (thought that is a guess on my part).

Operating systems have nearly no direct value to the average consumer of computing devices (Servers, Laptops, Tables, Phones, TVs, etc) An operating system is only as interesting as the applications that are available to run on it.

In the early days of Microsoft Bill Gates and company had a brilliant long term success strategy of embracing developers and the development process to get them to target Windows for all kinds of applications.

That strategy has worked well. We had and CP/M and Apple computers well before the first PCs hit the street and the IBM PC with MS-DOS surpassed them all. We later got IBM’s OS2 and NextSTEP, which were technically better than the versions of Microsoft Windows that were available in their day, but did neither succeeded against Windows.

Even today, Apple’s OSX is a more consumer friendly Operating System than Windows,  and Linux is far more performant and stable than Windows, but yet Windows is far more popular than both OSX and Linux combined on the consumer’s desktop – why?

There are three reasons.

Application Availability. Microsoft has done a better job than Apple, or the Linux community, of exposing a set of developer technologies that make developing Windows Desktop applications easy enough for a broad variety of developers.
Microsoft has grown monopolistic market share and successfully maintained it which makes Windows the largest potential market segment for application developers.
They have leveraged their monopoly market share to manipulate the hardware OEM space to propagate that majority market share.

So, it makes sense that Microsoft would be extremely concerned about anything that helped bring rich, powerful cross platform applications to prominence in the industry. In the years I worked at Microsoft we often implemented a pseudo-embrace competitive strategy. We “embraced” the popularity of Java and then tried to subvert Java on Windows so that it would become a Windows specific technology. Apps written for Microsoft’s version of Java would not run anywhere but Windows.

A similar thing happened when open web development languages surpassed ASP.NET as the premier web development choices.  Microsoft did some work around PHP to make it “almost good enough”, and worked on implementations of Python and Ruby – both of which have been pretty much abandoned.

Microsoft is now doing the same thing with HTML5 and JavaScript. Embracing some of the standards, leveraging the popularity of their great Visual Studio Tool set and extending the standards based technology with “Windows Only” extensions.

Apps that run on anything other than Windows is BAD for Microsoft and choosing this development model includes betting on Windows 8 to be so good on the desktop and on Tablets / Devices that adoption of Windows 8 across all form factors will be nearly ubiquitous (making the market segment of non-Windows devices too small to be of interest to developers.)

Apple & Microsoft combine to represent nearly complete dominance in the desktop operating system space and both see “device based computing” as huge threats to that dominance. (As evidenced by the aggressive legal actions that both have been taking in attempts to thwart the success of Android.)

The more that user’s find utility in internet capable computing devices that are NOT conventional personal computers, the more fragile their respective dominance becomes.

And it’s not just operating system developers that look to leverage the exploding apps space to maintain their historic success. Google, for example, built a pretty good apps platform that only works in their Chrome browser. Why would they care? Because their success is based on search which starts, for the vast majority of users, IN THE BROWSER. So, controlling the majority of the browser market share helps their core mission.

Amazon restricts what yo can install on their brilliant Kindle and Kindle Fire devices because their business is based on the digital acquisition process (Apps, Books, Video, Audio, etc)
All these examples represent the very nature of business.

But in a perfect world, what would be best for the REST of us ?

The retail consumer who purchases applications and the small developer who sells them are the ones who would benefit most from an industry move to standards based applications that could be purchased once and run anywhere the purchaser wanted to run those apps.

It is for these reasons that the OPEN Web Community (including Mozilla) is so interested in “Standards based applications development”.  As a non-profit organization, Mozilla’s mission is to promote openness, innovation and opportunity on the web.

So, what might a “Web Run Time” based application look like?

Well, in many cases it will look like a native application.

It will run while the host device is connected to the internet – and when it’s not.

This is done in part by creating an application manifest that supplies a list of resources to the host (an HTML5 enabled browser or similar runtime) specifying what files need to be saved in the cache for use when off line.

Of course, this means that many web developers will need to change the way they think of web development.

ASP.NET, PHP, Python, Ruby, Perl (did I miss anything important ?) developers are used to writing code the executes on the SERVER with very little code on the client. Usually the JavaScript code in these applications implements some user interface behavior but no real business logic.

In the new “Web Run Time” model we’ll shift our architectural perspective to one who’s logic executes on the CLIENT and gets updates from the server when the server is  available. Those updates can be data, markup, or even code.

Those updates can be determined and delivered by any server side technology that can send data over HTTP, so the old standards like PHP and ASP.NET can be used, or we could choose a newer construct like Node.js.

Application specific data can be written to the cloud, as is becoming more prevalent, and can be written on the client when an internet connection is not present. The “Web Run Time (HTML5) offers several methods for local storage.

Local Storage
Session Storage
The FIleSystem API
IndexedDB (Only implemented in FireFox at the moment)

The application itself can mange storage choices in performant ways, using practices very much like those in multi-threaded designs, by determining the availability of the internet, making I/O decisions and handling persistence execution in “Web Workers”. (Read more here: http://dev.w3.org/html5/workers/ )

What’s more, the combination of Web Workers and Web Sockets can go a long way to finding the performance opportunities that web developers may have struggled with in the past.

In the near future, HTML5 Apps will be able to detect whether they are running in the foreground or the background and select different threads of execution based on this state.

More and more, HTML5 implementations, and the containers in which they run, will expose standard interaction APIs for both hardware (like camera, mic, GPS) and software services (like mail, calendaring, etc).

All these things reduce the scope of applications that would require native access to the operating system API.

If HTML5 provides the user interface structure of our application and JavaScript is what we use to implement it’s imperative logic, then CSS is what we use to define the appearance of our applications.

Clever use of CSS3 will not only let us implement elegant UI behaviors but dynamically applying different CSS style sheets will let us taylor the same markup and code for execution on any specific form factor (Phone, Tablet, PC, big screen television.)

So I’m embarking on a journey n which I’ll explore Application Building in HTML5, sharing with you what I learn and what difficulties I encounter.

What examples of obstructions have you experienced in building real Apps with HTML5?  (Please don’t offer speculations but rather issues discovered in your own hands on development work.)

---