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.
[ Find out which 10 apps are pushing HTML5 to the limit. | Also on InfoWorld: "HTML5 in the browser: Canvas, video, audio, and graphics" | "HTML5 in the browser: Local data storage | "HTML5 in the browser: HTML5 data communications" | "HTML5 in the browser: HTML5 forms" | "HTML in the browser: Geolocation, JavaScript, and HTML5 extras" ]
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, synchonization 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.
HTML5 hard truth No. 1: 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.
With a JavaScript debugger like Firebug, anyone who is curious about what Facebook, Google, or any other website is doing can just start inserting breakpoints and watch the code. This is great for debugging and learning how websites operate, but it's a nightmare for security.
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.
There are limits to the security problems that can be incurred. Some JavaScript tools such as Google Web Toolkit are nearly as complicated as standard compilers. Their output can be fairly inscrutible. Luckily tools like the JavaScript Deminifier can help.
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.
HTML5 hard truth No. 2: 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.
HTML5 hard truth No. 3: 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 synchronization.
Web developers also need to worry about the security of the local database. While there are no tools that make it easy for a user to edit the local data and upgrade their privileges, there's no way for the central server to prevent it. All of the security holes introduced by letting the user tweak the JavaScript code affect the databases, too. They're wide open and waiting for someone to write a Greasemonkey script or some native code to change the data.
HTML5 hard truth No. 4: 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 synchronization.
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 synchronization: humans, who manage synchronization 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 synchronization. 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 more 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 synchronization of HTML5 Web apps.
HTML5 hard truth No. 5: 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, which leverages the cloud 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 plug-in for uploading photos. With a wave of the caliph's hand, the plug-in 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.
HTML5 hard truth No. 6: 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.
HTML5 hard truth No. 7: Web Workers offer no prioritization
Web Workers are among the more intriguing additions to HTML5. Rather than depend on copious JavaScript wait, delay, and pause commands, Web developers can now split apart their code and segregate the CPU hogs into Web Workers. In other words, HTML5 Web Workers make the browser operate more like an OS.
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.
HTML5 hard truth No. 8: 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.
HTML5 hard truth No. 9: 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 geolocation 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.
HTML5 hard truth No. 10: 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 Web developers to come to terms with.
HTML5 hard truth No. 11: 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.
Many JavaScript developers have left the issue of compatibility to those who create the libraries, such as jQuery. These layers insulate us from the cross-browser differences. Will they be strong enough in the future to smooth over the differences? Only time will tell.
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."