If you are a programmer you might have found the whole fuss about HTML5 that hit the "media" puzzling. Didn't you want to say - "It's just a markup language". Now the hype is all but gone. What remains?

The computer industry is driven by hype, fashion and marketing. Even programming, the discipline, and I use the term lightly, that makes it all work, is subject to its fair share of hype. You may think that Java took off because it was a language that we needed. There is a case for saying that it took off because the name hit a soft spot in the zeitgeist. You need to remember that LiveScript was renamed JavaScript to cash in on the Java buzz.

Yes, programming has its fashions and its fads and these can be ruled by non-logical considerations.

So what about HTML5?

The first mystery is why it ever got hyped in the first place. There was little marketing advantage to anyone to suddenly notice HTML5 and use it to promote their own particular products. At best you can imagine that browser makers might latch onto HTML5 as a way of showing their browser off but

"my browser is more standard than yours"

is a strange sort of marketing line. It's like proclaiming that "my browser will do everything yours does, no more and no less". Given that the browsers are all free, it makes even less sense as they can't compete on price in the absence of features. About the only thing left to market a standards-based browser is performance and perhaps the UI.

But this is to miss the fact that HTML5 was hyped as the solution to all our programming ills, not as a way of making a better browser.

At first sight it is even difficult to see what HTML5 has to do with programming. Ideally HTML5 is used as a semantic markup language conveying no style or behavioral information. The style is the job of CSS and the behavior is the job of JavaScript.

OK, you can argue that HTML5 was simply the catchall for HTML5 plus CSS plus JavaScript, but even if you make this assumption it still doesn't add up. JavaScript hasn't changed much since the introduction of HTML5 and the changes to CSS have mostly been incremental - welcome, but nothing groundbreakingly new.

Most of what could be done with HTML5 could be done with the existing DHTML's DOM plus JavaScript and some CSS.

Putting it simply, HTML5, in its broadest possible interpretation, promised very little we didn't already have.

If you take a look at the demos that were being used to demonstrate what a wonderful world HTML5 was bringing to our browsers, then with a few notable exceptions they could all have been done using the existing technologies.

So what are these "notable exceptions"?

Over time, and as the HTML5 hype started to die down, the key idea became the idea of the web app. So much so that today you will hear more about web app versus native app than HTML5 versus anything at all. The idea is that the browser should be an environment where you can create programs that are the equal of what you can create using the native hardware.

To this end, JavaScript has improved its performance by an amazing degree. This makes a difference - but has little to do with HTML5. We have also acquired a lot of new APIs for the JavaScript to work with but no matter how much you try to pretend that these are part of the HTML5 package they vary in how "core" they are regarded.

And this is where it all starts to go wrong.

The APIs that are so necessary to building web apps the equal of native apps are seriously hampered by the needs of security and the in-fighting of the browser makers.

The security is something of a joke.

One minute we invent an API do do something, then cripple it by the need to stop cross-site attacks and then some clever programmer finds a way around the restrictions and opens up the security risk all over again.

There are lots of examples, but perhaps the best known is the same origin restriction on getting data from another server. Just as you are getting used to this restriction in comes JSON/P as a way of getting data and more from any server anywhere. Why bother with the original restriction if it only makes life complicated? This is not to say we don't need security - but we don't need multiple layers of ad-hoc security that simply stop you from doing reasonable things.

There isn't even any consensus as to what should be allowed and what should be prohibited on the grounds of security. For example, Firefox lets you hide the button that the user has to click to take a picture, but Chrome doesn't in case you find a way to take photos without the user knowing.

The needs of security are also used to limit support for APIs that are claimed to be insecure. For example, Microsoft refuses to support the WebGL API because use of the GPU is not secure. Yet when it suits Microsoft to use the GPU as part of its own API efforts it does so even though it might not be secure.

The needs of security are currently crippling efforts to create web apps that are as good as native apps.

Next we have to move on to the way browser makers are behaving. For a very short time at the start of the hype the browser makers all wanted to be seen to be working together to conform to standards. It wasn't quite a Woodstock moment, but love and peace did seem to be in the air. For one thing all of the important browsers implemented the canvas element and Microsoft even managed to catch up and implement SVG.

The love in didn't last long.

The cracks started to show almost at once. First Google added WebGL for 3D graphics and Microsoft refused.

This is still the biggest failure of the standard but there are lots of others. Slowly but surely, each of the three big browser makers realized that their interests were better served by inventing "standards" as fast as possible and hoping that everyone else would have to accept them as de facto standards - some chance.

At the moment we have a patchwork quilt of what is necessary to implement a modern web app. Even where they do agree on how to do something the minor differences are so great that it makes a big joke of the idea that a web app works everywhere.

What browsers implement and don't implement is once again a battlefield where the developer is simply API fodder.

Then there is the matter of the use of prefixes - CSS in particular - what bright spark thought this idea up.

On the desktop we have DLL hell, but on the browser we have prefix purgatory.

The idea is clearly nonsense. If you want to implement a new feature but aren't 100% sure you will do it properly, then put a prefix on the front of the names used. Anyone notice the problem? Now any programmer wanting to support the feature has to write one version for each browser, using the appropriate prefixes. And one day the browsers will remove the prefixes? If they do then they simply crash a lot of code that only uses the prefix. 

The current status of the HTML5 revolution is typified by the way each of the browser makers currently shows off its creation by implementing experiments and demos designed to impress. Yes, they impress but they also reinforce the division. Standards-based browsers should not be showing off what they and only they can do. Chrome experiments simply bring back the old slogan of "Web page best viewed with X".

The strangest thing of all is that, as the HTML5 hype dies down, things are looking better. Browsers are slowly acquiring the APIs needed to really write a good web app. They certainly aren't there yet, but they are getting there. Due to the lack of standards these things are browser specific, but at least there are only a small number of browsers we need to tackle. HTML5 hasn't delivered on the promise to standardize things but at least we only need to target three variations of the basic platform - and for this we should be pleased.

It is the world beyond HTML5 and its hype that will deliver the goods.

We are not there yet.