The cloud owes you nothing
It's not really fair to blame HTML5 for all of the structural problems with storing your data in the cloud, but the cloud is an essential part of the vision, leveraged to fix all of the headaches for installing software and backing up data.
Given the limitations of HTML5 local data storage, the bulk of web app data storage will remain in the hands of servers, and there are moments when this approach can be devastating. Just recently Facebook decided it didn't like one Linux-based plugin for uploading photos. With a wave of the caliph's hand, the plugin was gone, along with all of the photos that were uploaded using it.
These stories aren't common, but they're appearing more and more often for many reasons. Are you sure that the cute web startup promising free everything with their HTML5 app is going to be there in a few years or even a few months? You'd better be.
It gets worse. As the terms of service for many web apps make clear, it's not your data, and in most cases you have no legal recourse to recover the data. Some of the more outrageous service agreements insist that the data can even be deleted for "no reason at all."
Not only does HTML5 avoid fixing this issue in any way, its structure practically ensures that any of the local data cached on your browser will be stored in the cloud, out of your reach and control. The HTML5 hype says this is a feature, but it could easily turn against the model.
Forced upgrades aren't for everyone
One story, perhaps apocryphal, tells of a person who used a Gmail account for casual hookups with people in bars. When Google+ came along, all of the memories came flooding back, because Google+ linked those old addresses into the discussion forums. Every day, the old names and old faces are there asking to be put into discussion circles.
When the web app companies need to upgrade, they must upgrade everyone at the same time. While this is said to relieve users of having to manage the software installation, it can be a nightmare for anyone who doesn't want the new features. This isn't just a problem for people's privacy, as in the case above. New software can often crash other packages that relied on the old features being where they were supposed to be.
Web Workers offer no prioritisation
Alas, they do not duplicate all of the features of the OS. While they do provide a way to fork the workload and separate it, there is no way to manage the workload effectively or set priorities. The API just allows messages to be passed into and out of Worker objects. That's all; the browser handles the rest.
Will CPU-rich applications like code crackers sneak their way into the background running on popular websites? Will people begin luring users to cycle-stealing websites?
Malware already piggybacks with useful software, so it's likely just a matter of time before this functionality is exploited. There is little users can do about it because they have no way to watch for the creation of Worker objects or track what they do. Their computer will just get slower after navigating to the targeted web page.
Format incompatibilities abound
HTML5 heralds the introduction of audio and video tags, which at first blush look as easy to use as image tags. Just plop in a URL and the browser streams the data. Yet if it's so easy, why have I wasted two weeks trying to get basic audio files to play in all of the major browsers?
It's not really the HTML5 committee's fault that individual browser builders decided to implement some but not all of the various audio and video formats out there. People are human, and humans fight for dominance. But the developers have to deal with the fallout when a file that works perfectly well on one browser fails to do anything on another.
How does one test for this? API developers were smart enough to include the function canPlayType, but even that function is not supported by all browsers.
Implementations are browser-dependent
The idyllic vision of HTML5 is one thing, the grungy reality of its implementations is another. True, programmers are trying their hardest to build the architects' dreams, but some of the tags and objects don't work correctly.
For instance, there are many things to like about HTML5's geo-location API. It offers some protection for privacy and a bit of control over its precision. If only it worked consistently. One browser always times out, even though it should be smart enough to know that the desktop doesn't have a GPS chip.
Ultimately, this is more of a complaint about how browsers fail to implement the feature consistently, as opposed to being one aimed at the structure of the API itself. This hard truth highlights the browser-dependent challenges that web developers face in making the HTML5-based web app Nirvana a reality.
Hardware idiosyncracies bring new challenges
It also seems unfair to complain about how some browser builders are going above and beyond the call of duty to provide much better performance, but no good deed goes unpunished. As the new Ferrari owner finds out after wrapping their car around a light pole, sometimes extra power isn't always a blessing.
Microsoft has done a great job of increasing the Canvas object performance of its IE browser by integrating it with low level hardware drivers. The company has even commissioned neat games like pirateslovedaisies.com to show off the power.
But now programmers must pay attention to whether these additional features are available, and it's not clear how to find out how fast your code is running.
The game designers at pirateslovedaisies.com, for instance, included a switch to turn on and off the features that IE enables. Is there an API that makes it possible to guess about these features? Not really.
The simplest thing is to test for the browser name and try to estimate the frame rate. Yes, I know that native game developers have been dealing with the wide range of available hardware for years and the only real solution is to ban innovation, but this is yet another wrinkle for developers to come to terms with.
Politics as usual
Some folks call Ian Hickson, the main drafter of the HTML5 standards, the Supreme Dictator for Life.
They're joking, I guess, but the title doesn't match. The standard writer is just making suggestions, and the coding geniuses at the browser companies are the ones who make the real decisions. They may or may not choose to implement a feature, then the web developers get to decide whether the results are stable. After a few years, the standards are often changed to match the implementation.
This issue highlights the fundamental problem for the field. We want the freedom, creativity and cornucopia of features that come from pitting many browser companies against each other in a tough competition. The pace of innovation is great, but it creates even more differences, as the browser developers rush to add new features to gain an edge.
But we also want the stability that comes from putting one central dictator in control of the platform. Alas, the world has never found an ideal solution for the battle between authoritarianism and democracy.
Instead of grousing too much about the headaches that come from the differences, we might want to adopt the attitude of Winston Churchill, who told the House of Commons, "Indeed, it has been said that democracy is the worst form of government except all those other forms that have been tried from time to time."