tcaudilllg Dragonmaster
Joined: 20 Jun 2002 Posts: 1731 Location: Cedar Bluff, VA
|
Posted: Sat Aug 18, 2012 2:43 am Post subject: HTML 5: A Critique |
[quote] |
|
HTML 5 has been out for a while now. While it seemed to have promise in the beginning, it seems that Google's presence has ultimately marred it in a fashion similar to what MS managed years before.
The result is waste and complexity, much of it quite needless.
CANVAS is the most obvious example. Not for what it does, of course -- CANVAS itself is great -- but for what it prevented. Decisions have been made primarily with security in mind; indeed, the security question has haunted the internet for quite a few years now, so much that it's becoming a major complication and burden.
What was really needed was integration of DHTML inside the CANVAS framework. Instead, CANVAS is in large part a hack job meant to benefit existing interests. It behaves pretty much like a VGA card running in Mode 13: you even have to create your own double buffer. Its handling of animated GIFs and PNGs is particularly poor: you have to use requestAnimationFrame to redraw the GIF as it iterates; however the redraw is more CPU intensive than the actual running of the GIFs outside the canvas. The redraw code must be poor for it to consume so much CPU at 60 FPS. What's even better about the GIF animations though, is that they cannot simply be reset by changing the SRC attribute, so they are actually LESS reliable for use in sprites than under DHTML.
DHTML was pretty good without CANVAS. It had the VSYNC issue and it lacked primitives, and that's pretty much it. Of course, DHTML can be used in conjunction with CANVAS, but the focus on CANVAS has left DHTML impoverished by comparison. DHTML is still burdened with rerendering issues which slow it down unnecessarily.
Workers are a whole other story. A good idea that got conflated with security issues. Have you seen the spec? It's monstrous. It's like the W3 hired a lawyer to write the spec instead of a scientist. If you though XML was bad, this is much much worse. For example, the whole purpose of synchronous file ops, as opposed to async ops, is to avoid callbacks which mangle code. But, because of "security concerns", synchronous file ops can only take place in workers, which require (wait for it) callbacks. You're literally forced to wrestle as much with the language as with the algorithm.
In short, HTML 5 was made of Google, by Google, and for Google, and all the "HTML 5 Rocks" propaganda aside, it's a loss for everyone but Google. And maybe MS and Java, because I think a lot of people are gonna conclude that HTML 5 just ain't worth the effort to produce cross-platform apps for (and as far as that goes, Google has done more than enough to make cross-browser compatibility just as hard, if not harder, than in the MS days).
|
|