The State of HTML5 Apps

We’re at the brink of shifts in the way we do things. The monks who have been toiling away on these new pieces of machinery are coming out of the monolith and starting to spread the word to the people. You might have seen my tutorial on creating an HTML5 iPhone app, highlighting the possibilities of open standards, client-side applications that leverage technologies we’ve traditionally used for websites and web apps.

Recently, Apple announced its HTML5 expose (however failed). Respected web design consultant and author, Eric Meyer, has started talking about the concept of Web Stacks — and we’re in a situation not unlike the beginnings of Ajax: A few people are already doing it, but we haven’t fully put it out in the open yet, and we certainly don’t know what to call what we’re doing. My own HTML5 projects have been presenting their own questions, and I felt like I needed to take a step back and set a stage so that I could make sure that I understand where all these disparate pieces fit.

Let’s Talk Terminology

We need to address terminology. We could even be in for a good, old glossary at this point, but for now let’s just define the essentials. These aren’t set in stone either, by the way.

I think there is going to be some jockeying for position here among buzzwords.

HTML5

What is HTML5? HTML5 is pretty well summed up by Mark Pilgrim.

“HTML5 is the next generation of HTML, superseding HTML 4.01, XHTML 1.0, and XHTML 1.1.” – Dive Into HTML5 – Introduction

An interesting side note here is that we might see an “HTML6,” but it sounds like they just want to drop the number idea, and instead, evolve the specs slowly over time. This will take a large reeducation, but makes sense. One more from Pilgrim:

“The next version of HTML doesn’t have a name yet.

In fact, it may never have a name because the working group is switching to an unversioned development model. Various parts of the specification will be at varying degrees of stability, as noted in each section. But if all goes according to plan, there will never be One Big Cutoff that is frozen in time and dubbed “HTML6.” HTML is an unbroken line stretching back almost two decades, and version numbers are a vestige of an older development model for standards that never really matched reality very well anyway.

HTML5 is so last week. Let’s talk about what’s next.” – The WHATWG Blog

Applications

While there are plenty of good definitions — and you probably know what an application is — I think it’s worth rehashing here.

“Application software is computer software designed to help the user perform a particular task.

Such programs are also called software applications” – Wikipedia

HTML5 Applications (HTML5 App)

What is an HTML5 App? They are applications that fit the definition above (from a user’s perspective). They may not be in parity with other applications right now, but they are close enough that users won’t care.

Sooner rather than later, we will be looking at capability parity as well. From a developer’s perspective, they are applications written using HTML, JS, and CSS. They are applications leveraging open technologies and the evolving specifications of HTML and CSS that allow us to create software that can be used offline; things that used to need (at the very least) platforms like Silverlight or Flash.

Really, an HTML5 App is just web standards stuff. I guess you could throw in images there too, but really, the same things you have been using to build web pages for years are now being used to build applications that are more similar to a desktop or smart phone app than a website.

Open Source Paradigm Shift

Tim O’Reilly, O’Reilly Media founder and open source proponent, was onto something:

“IBM’s commoditization of the basic design of the personal computer led to opportunities for attractive profits “up the stack” in software, new fortunes are being made up the stack from the commodity open source software that underlies the Internet.” – Open Source Paradigm Shift

Value moves up the stack, commoditization moves down the stack.

I see HTML5 as a new, new layer. The browser — even at this point — has become a commodity. As long as it adheres to a standard, I think it will do okay.

People are going to be more worried about what HTML5 Apps they can run on their browser than what browser they are using. People saw this early on too, and they thought, “Oh, so we can just put our OS into a browser!” Well, no. If we have learned anything, it’s that you can’t copy-paste from old mediums into new ones.

Think about going from radio to TV. You can’t just point a camera at a man reading the news into a microphone. While there was an initial wow factor, I don’t think the full OS on the web thing will ever fully translate as much as HTML5 apps will translate into offline device use.

The Importance of Distribution Channels

No distribution channels like the Apple App Store and Android app store dominate. Then there are novel uses like Valve, the video game development and digital distribution company, is doing with game distribution, as well as Netflix with movies. These distribution channels seem to be how users will organize themselves.

Just like the OS was the binding piece of software for the desktop era, distribution channels will be the binding software for the “cloud” era.

How Did We Get Here?

There were — and still are — two big choke points.

Thank You, Web Standards

As much as we complain about fragmentation in the browser market, it’s not that bad.

It can be better, but it’s not the end of the world. They all run HTML, JS, and CSS. Though each browser has its own things going on, by-and-large, we are doing okay.

For example, you can always put some content on a webpage and have it delivered to the user and know that — in some fashion — the user will be able to see it. Can you imagine if a company starts to think they are going to redefine the web from the bottom up and have complete control of the standards? “We’re not going to use HTTP, were not going to use HTML.” It would be crazy!

This fact gave standards bodies like W3C immense power to get browsers to stay on the same path.

There Aren’t a Lot of Layout Engines

The second part is that browsers are hard to make. Billions of web pages — lots with really bad markup.

An individual developer isn’t going to stand a chance. Even past just parsing HTML: HTML moves fast — not fast for the majority of us — but fast for an individual developer. Also, we choose to use HTML in new ways (like microformats) so even conventions can change midstream on browsers.

Then add on top of all that, the diverse ecosystem of computers and operating systems that a browser vendor has to keep up with, and it’s a recipe for a small club. A small club is exactly what we have today. There are only four major layout engines that are the core of the market: Trident (IE), Gecko (Mozilla, Firefox), WebKit (Chrome, Safari), and Presto (Opera).

Tons of browsers are built on top of those engines. With such a small club, it’s easier to keep things inline and to keep track of what the other guy is doing. As much as people complain about IE, as far as I can tell, everyone talks to one another nowadays and IE9 looks like it’s going to be an upstanding member of this small club.

So here we are: Standards and browser vendors have created a choke point where pretty much anything you want to do one the web has to flow through them. But, this also means that if you have a browser on a device, you have an HTML5 App environment. There is always going to be fragmentation, but that is just the way it’s going to be, and we can live with that for now.

Where Are We in Standardization?

There is an infamous estimate from Ian Hixie, the HTML5 editor:

“It is estimated, again by the editor, that HTML5 will reach a W3C recommendation in the year 2022 or later.” – whatwg.org wiki

This freaks a lot of people out, but what I think it means is that finalizing the standards take a really long time.

Browser vendors are free to start implementing this stuff now — and they have been (most everyone except Internet Explorer).

Feature Detection versus Browser Sniffing

This is where the feature detection (detecting what the user’s browser can do) versus browser sniffing (what browser the user is using) debate is coming from. If you are an application developer, you are free to target “advanced functionality,” but you should be doing feature detection and progressive enhancement.

This seems like a completely reasonable way to develop. It allows for the standards process to make sure it does the right thing while not holding up developers from fulfilling their users’ needs. At any given time, there is going to be a hugely varied crop of browsers out there.

(Using sites like caniuse and QuirksMode will help.) Along with that, there are great feature detection libraries like Modernizer. Then there is this Mark Pilgrim list as well: The All-In-One Almost-Alphabetical No-Bullshit Guide to Detecting Everything.

Offline APIs

These, I really think, were the first step in the HTML5 App movement, and they’re more then just storing data offline.

What’s lost on many developers is that it’s great that we have localStorage, but how do we allow apps to do a fully offline boot? The Application Cache, of course. Without the ability to store the source files and data offline, we wouldn’t have offline HTML5 Apps.

Like I said, we have a couple of offline storage mechanisms: a simple key/value storage system called localStorage and a SQL storage engine, which a few browsers support (but the SQL idea seems to be falling out of vogue). The new hotness is Indexed Database — it has support from all major browser vendors. Storing the app and the data offline are the baseline needs for any HTML5 App environment.

Thankfully, we have support for these standards in WebKit browsers, Firefox, and it should be coming in IE9. Even though IE support may not be all the way there, think about offline use: Where do we most need offline capabilities? When we’re on our mobile phone or netbook. Smart phones are leaning towards WebKit and many of the smart phones sold these days run WebKit.

So, the places where we need offline experiences the most does support offline experiences — and it doesn’t matter as much that IE doesn’t currently support offline storage.

W3C WebApps Working Group: The Next Step in HTML5 Apps

The W3C WebApps standards is another major area of work. Lots of APIs and other specifications around client-side HTML5 Apps are being developed.

Deployment and Packaging for Distribution

“For local/offline HTML5 Apps, W3C Widget packaging and configuration is the deployment mechanism of choice. It will become the standard because it’s already there, it makes sense, and it’s close to becoming a formal specification. Besides, many vendors are already hard at work implementing it.

W3C Widgets work on Vodafone S60 and Samsung phones, Opera desktop and mobile on any platform, the Bolt browser (a thin-client solution like Opera Mini), and Windows Mobile 6.5. While BlackBerry also supports them, right now they need a special Java wrapper as an interface to the BlackBerry OS. There’s no reason to assume that the W3C Widget march will stop here.” – HTML5 apps – QuirksBlog

These are standards, just like any other.

Essentially, if you have an HTML5 App, it’s going to contain some HTML, CSS, and JS (and maybe images and other media). The standard is just a way to help developers package their apps in such a way that they can be distributed in one whole package consistently and interoperably. If you’re familiar with PEAR, it’s a very similar concept (but for HTML5 offline apps instead of PHP classes).

You will probably need to fill out some extra metadata to explain how your app is put together. Then — in a platform that supports the standard — you can be sure that a user will be able to install your app. This starts to get interesting when start talking about “app stores,” – we’ll get to that topic in a bit.

And the Rest of It

HTML5 has a bouquet of other cool APIs that HTML5 Apps can take advantage of. These APIs are going to give the app access to things like files, webcams, two-way communication with the server, and hardware-accelerated animations. These APIs are going to get better, but they are just the icing on the cake when talking about HTML5 Apps.

And HTML5 Apps Can Be Used Where?

We have HTML5 Apps, they can live offline, they can deliver unique experiences, but where can they live? Well, in the browser, duh. HTML5 Apps can live in many places, but the first question is, “Does the device have a browser or a layout engine of some kind?” If it does, and the engine is modern, you can probably run an HTML5 App on it.

But, essentially, I think this breaks out into three major areas of operation: desktop, mobile/small screen, and fuzzy.

Desktops

If you have a modern browser, you are good to go. If you’re using IE, you’ll need to pick up a modern browser like Google Chrome or Mozilla Firefox, or at least, chrome frame.

Also, desktops are still really important. If you really want to piss some people off, start talking about how HTML5 Apps can target the desktop just like any other stack (e.g. Flash, Flex, and Objective-C) — HTML5 Apps are right there with you, with a little help.

Site-Specific Browsers

Site-Specific Browsers (SSB) take one site or app (like Gmail) and just turn it into an app. There’s no URL bar or other  distractions. Some SSBs allow you to build a self-contained installable bundle and distribute it.

This opens up the desktop app field immensely. Some things to check out: Prism, Fluid/Fluidium and NativeHost.

Mobile

Yes, this is the hotspot for HTML5 Apps.

The iPhone has very sweet integration and your app can live on the home screen among all the other apps (see my tutorial on how to do this). The Android has support for the HTML5 APIs required, but not as nice of an integration. Over the next few years, the number of devices that are running HTML5-capable browsers is going to skyrocket.

Besides just the amount of devices, the different types of phones and phone OSs you might have to develop for, will also increase. It is going to make a lot of sense for a portion of app developers to target HTML5 because it will be able to run on all of these devices, and you won’t need to worry about all the underlying disparate technologies.

Fuzzy Space

We already have two companies that will launch TV platforms: Google TV and (possibly) Apple TV.

Google, during the Google TV keynote, said they would be support HTML5. We don’t know what Apple TV will support, but based on the recent HTML5 buzz it has been putting out, it’s likely they’ll also support it. Even if they don’t support HTML5 Apps, other TV box people (like Boxee) already do. While roundabout, you can leverage HTML5 to make a Boxee app instead of needing to develop something specifically for Boxee.

Fuzzy spaces are the most open field right now and they offer a lot of playroom. TVs connected to computers are increasing in numbers, and there are full screen browsers for watching YouTube on your TV. The popular video gaming console, Wii, has a version of Opera on it.

The sky is the limit here. What matters is that “playing” in these spaces doesn’t require anything more than HTML, CSS, and JS.

HTML5 App Stores

Eric Meyer wrote about how we have the ability to make HTML5 Apps; he calls them Web Stack Apps (and we have for a while now) but the Apple App Store darling gets all the attention.

One thought is that for HTML5 Apps to get more press, their needs to be a HTML5 App store. I think this idea has some merit, and I think someone is on the way with at least one. Chrome is planning one and Palm has one.

Any day now, we are going to see a fully independent app store spring up for HTML5 Apps. (Maybe I should save that idea for myself.) Stores are great: Developers can get paid in ways other than displaying ads. This has always been hard on the web.

Second, users now have a place where they can go and find apps regardless of what device they own. It’s a distribution channel, which leads me to my wrap up.

Where to Put Your Money

If I were a business analyst, this is where I would put my buy/sell recommendations.

HTML5 is rapidly advancing. It will continue to evolve. It’s something everyone needs to keep a close eye on.

Companies are going to start moving into this space in a big way this year and in the coming years. We are going to see some big numbers from the Chrome App Store. I also hope that we will see an app store on the Google TV, and Apple TV.

I started out thinking that HTML5 was the grand unifying theory, a culmination of my professional work that will take over everything, but what I have realized is that HTML5 is a player in the same ecosystem as traditional development stacks for applications like Flash, Flex, Silverlight, and Objective-C. Not only is it a player, but it’s going to be competitive. Flash, Flex, Silverlight and Objective-C can’t say they’re everywhere.

Flash, for example, has just been unsupported on a very popular device, the iPhone. On the other hand, HTML5 seems to be working its way into everything. This means that if I were a company looking at the long-term, I would be investing in HTML5. Even if I couldn’t create as intense and as immersive experiences in HTML5 as in other platforms right now — Flash has been used on TV and in 3D animation before — I would still buy stock in it. The sheer number of audiences I would have access to with the least amount of development would make it easy on any company’s balance sheet. We are always going to hear people say, “Well yeah, you can do that, but it won’t be an amazing experience on [device X],” and they are right, but that isn’t the goal for everyone, and I am not sure if that’s a bad thing.

For the young developers coming up right now: HTML5 is an A-level skill that needs to be developed into your skill set. It’s going to be marketable and it’s going to be in demand; it can be everywhere you want to go, and so companies will need to have some HTML5 App ninjas in their pockets. I am recommending buying into HTML5 Apps.

Buy big. Buy now.

Related Content

• How to Make an HTML5 iPhone App
• Eric Meyer on CSS3
• The Anatomy of a Website