HTML5 heralds some nifty new features and the potential for sparking a web programming paradigm shift, and as everyone who has read the tech press knows, there is nothing like HTML5 for fixing the Internet. Sprinkle some HTML5 into your code, and your websites will be faster and fancier -- it'll make your teeth white, too.
But the reality of what HTML5 can do for those seeking native-app performance on the web falls short of the hype.
After several years of enjoying HTML5's sophisticated new tags and APIs, the time is ripe to admit that there are serious limitations with the model. Not only are there reasons to grouse about HTML5 failing to fulfill our web nirvana dreams, there are even reasons to steer away from HTML5 in some cases.
The truth is, despite its powerful capabilities, HTML5 isn't the solution for every problem. Its additional features are compelling and will help make web apps formidable competitors for native apps, but security issues, limitations of local data storage, synchonisation challenges and politics should have us all scaling back our expectations for the spec. After all, every technology has its limitations.
What follows is a list of 11 hard truths web developers must accept in making the most of HTML5.
Security is a nightmare
The fundamental problem with client-side computing is that the user ultimately has control over the code running on the machine. In the case of web apps, when your browser comes with a great debugging tool, this control is easier than ever to abuse.
Suppose there's a variable that holds a value you'd like to change. Well, Firebug or any of the other browser debuggers is happy to help you tweak the data to be anything you desire. Do you want to trick your friends into thinking you're in another geographic location? It's easy to edit the variables that hold latitude and longitude to place your browser anywhere in the world. All the neat features of your web app can be modified, and the browser environment makes it easier than it would be normally with native code.
The danger depends, of course, on the nature of the application. It's one thing when someone edits their latitude and longitude to play tricks on their friends by checking into a website while pretending to be halfway around the world. The trouble begins when someone qualifies for all of the rights, privileges and free beers accorded by being crowned the mayor of some location.
When money gets involved, the games can only get worse. All of this means that client-based HTML5 apps can't be trusted with serious data collection, and it's better for everyone to be aware of their capabilities.
Local data storage is limited
The local databases buried in your browser are one of the neater features that make it simpler for web apps to cache data on your computer. But for anyone hoping to offer desktoplike data functionality in the browser, these databases can save bandwidth and improve performance. However, they won't give users the same power over their data that they're used to enjoying with desktop apps.
HTML5 data storage capabilities are certainly an important addition, but you still can't move stored data to another machine, make copies, back it up or open it with a different app. It's all buried deep where the browser hides it.
In a sense, these databases are the worst of both worlds. You get all of the responsibility for hosting the database, but none of the control.
Some of the latest browsers allow you to see which databases have been created on your machine, but this information is limited. Safari even lets you delete the database. But you can't browse the information or move it to another machine. The files aren't designed to move easily, although you can do it if you know where to look.
Nor can you dig into the files to see what is stored there. Sure, a programmer can take them apart, but only after studying the format and doing some hacking. They're not like spreadsheets or text documents that are easy to open with any editor, making the data less resourceful than it might otherwise be in a desktop app.
Local data can be manipulated
The user may not have control over the data, but the central website is also hampered when dealing with client data. Did the user switch browsers? Did the user switch machines? Many web developers just toss up their hands and use the local data storage for caching short term content. They can't let the user create much because of the problems of synchronisation.
Offline apps are a nightmare to sync
HTML5 local data storage is vastly improving the ability to use web apps offline. The only trouble is data synchronisation.
If a web app is connected to the Internet, it can continually save data to the cloud. When it's offline, changes aren't always stored in the cloud. When someone switches browsers or uses a different machine, copies begin to proliferate and the difficulties of synchronization rear their head. To make matters worse, clocks themselves may be unsynchronized, making them unreliable for finding the latest saved data.
Of course, this has always been a problem with native apps, but the difference is that the native model makes it obvious who is responsible for synchronisation: humans, who manage synchronisation troubles by looking at file names and change dates. But because HTML5 doesn't give users control over the databases stored deep inside their browsers, developers must provide the user interface and piping to handle synchronisation. The specification doesn't offer any help.
This isn't a completely intractable mess. Programmers manage these headaches by using version control systems, which have become increasingly sophisticated to handle such problems. Yet just having the technology doesn't mean it's an easy solution for programmers to use. Merging the various GIT repositories can take time. HTML5 developers will need to master these issues if they're going to manage the synchronisation of HTML5 web apps.