Recently 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 is 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 many small websites, my friend's had grown organically, beginning as simple "brochureware" and gaining new features over time: a contact form, photo galleries, a blog. 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. Each new feature was bolted onto the last.
 |
For starters, there is really no such thing as a web app built only with HTML. Choose any random site and it is likely to mix HTML with CSS, JavaScript, SQL, JSON, XML, and a server-side scripting language such as PHP. 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. Web developers must constantly balance between supporting the largest possible audience and delivering the user experience the client wants. The problem with frameworks should be familiar to any developer by now. 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 is 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-organised code, better attention to browser compatibility, and with a mind to flexibility and scalability. That is not to say I advocate rip-and-replace as good development practice. 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 is easy to dismiss tools like Flash, 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.