Web & communication software

11 Hard Truths About HTML5

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.

Next Page: Incomplatibilites, browsers, and hardware quirks...

Subscribe to the Daily Downloads Newsletter