An excellent response to an obviously flawed article…
I recently read a disturbingly misinformed article on .net Magazine by one Mr. David Akka. Akka argues three points against the use of HTML5:
- That it is insecure.
- That HTML5 applications lack synchronicity.
- That it is not a completed standard.
And so, that is the order that I shall refute these claims.
No system is inherently secure
Security is something that must be developed. Akka argues that phishing, malware and DDOS still apply as threats from HTML. Let’s start with DDOS (Dedicated Denial of Service) attacks. This is something that affects servers at the the network level—not the client level. You can write a DDOS application in Flash or any other software capable of making an HTTP connection. As for phishing and malware? These have such incredibly broad reach in terms of application that any attempt to use them as nails on the cross for HTML5 is a laughable one.
In addition, he cites an article in which security firm Sophos warns of HTML5 being used to trick users based on its “sophisticated presentation layers”. Having worked extensively with both HTML and Flash, I can tell you that the latter gives much more in terms of presentation capabilities. As a bonus, you only have to develop it against a single viewing platform.
There is a fundamental danger that HTML5 will offer an open gateway to the corporate network, and, with the proliferation of mobile devices accessing networks, this is too much of a risk to take.
Then don’t do that. I mean…really? Arguing against hypothetical situations aside, if your corporation is allowing incoming connections to secure content by default, then you need a new IT department. Don’t kill the messenger.
Synchronicity can be developed
HTML5 is a living standard
If you really can’t afford to use HTML5 because the W3C hasn’t placed a banana sticker on it yet, then don’t use it! You’ll notice I used the phrasing “a choice” and not “the only choice” for the title of this article. But consider this: HTML5 will become a standard based on the feedback it gets from those who use it. If you don’t bother to kick the tires a bit, the possibility exists that it may never suit your needs.
The argument comes up that your developers will have to keep updating and changing code. Yes, that is a possibility, but perhaps you should talk to your iOS and Android developers about ever-evolving codebases and APIs before you start shaking a finger at HTML5.
If you have an in-house development team though, don’t let them stagnate with a technology! This can lead to two situations: they get bored because they aren’t being challenged and leave, or they get lazy and roadblock new technologies that you will want to use in the future. This is precisely why COBOL and Pascal developers still exist to this day.