HTML5 is seen as the savior of the internet, and everybody that followed the tech press knows that HTML5 will fix the problems of the internet. With some HTML5 into your code and the websites will be faster and fancier, it will ever make your teeth white. But the reality seems to differ very much.
After some years of HTML5, with all the sophisticated tags and APIs, it’s time to admit there are serious limitations with the model. HTML5 fails to live up to our coding expectations, but there are even reasons to steer away from it in some cases. It time to acknowledge the truth that, despite its powerful capabilities, HTML5 isn’t the solution to most problems. Security issues, limitations of local data storage, synchronization challenges and politics should make us scale back our expectations for the spec. After all, every technology has its limitations, despite all the expectations.
11 hard truths Web developers must accept in making the most of HTML5:
“HTML5 hard truth No. 1: Security is a nightmare
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.
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.
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 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.
HTML5 hard truth No. 6: Forced upgrades aren’t for everyone
HTML5 hard truth No. 7: Web Workers offer no prioritization
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.
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.
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.”
Source : www.itnews.com
Author : Peter Wayner
Hello! bcgbbdd interesting bcgbbdd site! I’m really like it! Very, very bcgbbdd good!
Very nice site!