It’s happened several times this week.

I heard someone say “There no difference between an HTML5 App and a Web Page / Web Site”.

While a web page could be an App, I think it’s a gross over simplification to say that they are the same thing.

Fundamentally, an HTML5 App should be more that simply a saved web page.

Yes, the HTML5 Off-Line API lets you create an application manifest to specify assets to be downloaded so that you can access those assets when the host device is not connected to the internet.

I clever application will understand when no network connection is available (See navigator.OnLine) and will tailor it’s behavior based on the network state.

Supporting “sometimes connected” experiences will likely require slightly more complex architectural design too. For example, web “sites” that work with data simply don’t work if the browser connection to the internet goes away. A line of business App that supports both connected and disconnected scenarios could determine the network state and, if not connected, store application / transactional data locally and then sync when a network connection becomes available.

Though that work flow and the eventing mechanism to support it is non-trivial, it can be abstracted into a common data I/O layer.

As you think about Apps supporting different network states you will think of any number of scenarios where you would implement custom logic  for on-line and off-line conditions.

Consumer research constantly tells us that consumers have very distinct, and different, perceptions of what an “Application” is and what a Web Site / Web Page is.  Apps should have a host integrated presence. For example, on most hosts I should be able to launch the application from a shortcut or icon. A process manager (like on Windows of Linux) should know the App identity.

Another big part of the intended App experience is the idea that we can write an application one time and run it on any device that we choose. As an industry, we have been trying to accomplish this forever.

Using “Web Standards Technology” we will define our user interface structure with HTML and write our imperative client logic in JavaScript.

We can write different CSS styles to custom tailor the aesthetics to whatever devices we want without touching the logic.

The “App” can be served up from a server and run ion a browser or run on the desktop using a Web Run Time.

Applications that have a server interactions will speak HTTP and JSON or XML so you can implement that data access (and any additional server side logic) in pretty much whatever language on whatever platform you like. This model solves another problem that we are always trying to solve and that is turning the World Wide Web back into a real Client / Server Network by federating real logic to the clients computing device thereby taking as much load as possible off of our servers.

The cross platform nature of HTML5 / Standards Based Technology has become important in a way that it has never been in previous generations of computing.

A decade ago cross platform meant writing your application once and being able to run it on Windows and Unix. The “platform” we were talking about was really the Operating System. Sure the hardware was different, but to the application developer the underlying hardware didn’t matter. This is no longer true and the difference between hardware hosts is greater than ever before.

Good applications will sometimes need to offer different functionality on different devices and will sometimes need to implement some features in a device specific manner in order to offer the same experience no matter what device the application is running on. Since it is commonplace for users to own and use multiple different devices to access the World Wide Web it will be important for developers to make their applications experience as similar as possible across devices.

Take, for example, an application that helps the user find something close to them. If the App is running on a phone or other 3G/4G enabled device that device will have a GPS built in to the hardware. If the App is running on you Mac Book Pro (or other laptop) it’s not likely  that a GPS will be present so the developer will have to provide an alternate mechanism for any geolocation functionality.

To do this I could use the GPS is there is one available on the host device but us an IP based Web Service if the device has no GPS but is connected to the internet.

If you are wondering how you would get access to that GPS, or,  for that matter camera, mic, or any other device specific hardware, well I’m glad you asked.

THAT is what the Web Run Time (or WebRT) will do.

Today’s modern browsers create a “sandbox” to limit what code delivered from the Web is allowed to do on the host machine. This concept of restricting the functionality of “untrusted” application code is not unique to browsers. Adobe AIR & Flash, Sun /Oracle Java, Microsoft .NET and many other technologies do this sort of thing.

The “Web Run Time” will (eventually) have a collection of standard APIs that expose all of the common hardware types that applications developers will need access to in order to build rich applications using Standards Based (HTML5/CSS3/JavaScript) Technology.

And the Web Run Time will free the developer from the browser “chrome” so an App will look like (and be) it’s own thing – and not just something the user can use inside Firefox or Chrome or IE.

So, maybe it’s just me, but I believe that thinking about HTML5 based “Apps” as simple HTML pages (that may get cached off line) is a pretty narrow view of what the next generation of Web powered applications could look like.