Why HTML still isn’t the perfect Web language

Last week I applauded the decline of Flash and other proprietary RIA (rich Internet application) platforms, particularly with HTML5 promising improved support for interactivity and multimedia. Not everyone agreed with me. And like so many tech debates, there’s a flip side to the HTML coin, as I was recently reminded when I took on the job of revamping a Website for a friend’s business.

My friend’s original Web developer had gone missing, leaving him in a lurch. With new products due to arrive and no way for my friend to update the site, it fell to me to pick up where the last developer left off. Like so many small Websites, my friend’s bore all the earmarks of having grown organically, beginning as simple “brochureware” and gaining new features over time: a contact form, photo galleries, a blog. Unfortunately, the result was a mess.

Adobe shuts door on Flash for iPhone, blames Apple for decision

What is HTML 5 and why does it matter to you?

Nothing seemed to work as advertised. If I copied the site to a new server, it broke. If I moved it to a different directory, it broke. If I tried to tweak the primary navigation, the page layout blew up. If I disabled a JavaScript function, suddenly all the images stopped loading. Each new feature was bolted onto the last until the whole site was like a kinetic sculpture made of duct tape.

And that’s just the problem. In my experience, for a large segment of the Web, this kind of morass isn’t the exception; it’s the norm. Web standards may offer an open alternative to platforms like Flash, but as a foundation for sane application development, they still leave much to be desired.

Just for starters, there is really no such thing as a Web app built with HTML — that is, not HTML all by itself. Choose any random site and it’s likely to mix HTML with CSS, JavaScript, SQL, JSON, XML, and a server-side scripting language such as PHP, often all at once. That’s a lot of languages for any developer to juggle.

While each of these technologies is defined by standards, actual practice is another matter. HTML tags that behave one way on Firefox may behave differently on Safari, and CSS support varies widely between browsers (particularly where Internet Explorer is concerned . Web developers must constantly balance between supporting the largest possible audience and delivering the user experience the client wants.

One way to restore order to any Web project is to stop reinventing the wheel. Web technologies are a long way from infancy. A wide variety of frameworks and toolkits — many of them open source — are available to help eliminate the drudgery of Web development and ease cross-browser compatibility.

But the problem with frameworks should be familiar to any developer by now, particularly to Java developers. Remember when there were just one or two Java application frameworks on the market? Now there are dozens to choose from — to say nothing of all the tools for other platforms, such as PHP and Rails.

The same is now becoming true for client-side Web technologies. Countless new frameworks and methodologies have sprung up. Should JavaScript developers put their stock in jQuery, Dojo, Prototype, MooTools, or something else ? Each offers its own developer ecosystem and its own idea of what constitutes best practices. And JavaScript libraries aren’t the end of it. These days there are even CSS frameworks, such as Blueprint and the 960 Grid System, designed to speed to process of site layout.

With so many options to choose from it’s easy for developers to go a bit wall-eyed. In the case of my friend’s site, my predecessor had made some good choices. Unfortunately, his execution didn’t match the quality of his tools. He loaded a complex CSS framework but ignored it everywhere it proved too restrictive for the client’s design demands. He was using a JavaScript framework to add client-side effects, but his grasp of good programming practice was limited, leading to a site that performed slowly, had poor cross-browser support, and was riddled with bugs.

In the end, I had to scrap the site. Preserving its visual presentation as closely as possible, I set about recoding the HTML, CSS, and JavaScript portions essentially from scratch. This time I did it in an orderly fashion, with clean, well-organized code, better attention to browser compatibility, and with a mind to flexibility and scalability, so the site wouldn’t need to be torn apart again the next time my friend asked for changes.

That’s not to say I advocate rip-and-replace as good development practice, or even that everything went smoothly with the rewrite. On the Web there’s always too much trial and error. Compared to the rational, sober, verifiable development methods they teach in computer science programs, much of modern Web development amounts to playing darts.

So while it’s easy to dismiss tools like Flash — and I still argue it’s a platform whose time is past — mainstream Web developers have reason to envy those who build applications with proprietary tools. A tightly controlled ecosystem backed by a major vendor makes it easier to define best practices, set development targets, and deliver results with a minimum of chaos.

We need more of that in mainstream Web development. Adobe has introduced some interesting tools for HTML5 support in its Creative Suite 5 product line, and Adobe Dreamweaver was invaluable to me in making sense of the legacy code in my friend’s Web project, but there’s still plenty of room for improvement. The time for Flash and other RIA platforms is over, but the time for HTML5 is just beginning. What Web developers need now are not more alternative tools, but tools that will help us unify the ones we already have.