Ajax and Design Patterns
Michael Mahemoff has been collecting a lot of patterns related to Ajax recently, and an interesting collection it is too. Not everything is a ‘design pattern’ in the Alexandrian/Gang Of Four sense, but its good to see this sort of thinking taking place.
If Ajax is going to survive, it needs design patterns and some structured thinking. A lot of ‘toolkits’ are popping up at the moment, some of which are going beyond the 2kbyte wrapper around the XmlHttpRequest object. Hard to say which ones will still be in active development in a year’s time, but I’d put my money on those that have a good structure underlying their code. Qooxdoo looks like a contender, just from a quick examination of their UI ‘Atom’ concept, that reuses some basic layout code across trees, buttons and other widgets to good effect. Borrowing a bit more from KDE than just the icons, evidently ;-) . (I’ll admit to picking names out of a hat here. I’ve played with their demos and peeked at their source code, but that’s about it. Don’t go out and remortgage your grandmother based on my advice.)
So can javascript support design patterns? Most of the literature is focused on strong object-oriented languages like C++, and increasingly Java and .Net, isn’t it? How do we work with these ideas on our Ajax codebase? The simple answer is ‘as well as we can’. Many design patterns are often documented using language features that javascript doesn’t support out of the box, such as interfaces and inheritance (yes, I’ve seen Doug Crockford’s heroic attempts), but the problem that the pattern addresses may still occur, and the pattern itself can usually be applied anyway, in my experience.
There is even an argument for suggesting that javascript needs design patterns more than its more rigidly structured counterparts Java and C#. Let me digress a little, and suggest that computer languages in general fall into one of two camps. (I ought to don my flameproof underwear at this point, although I’m not trying to suggest that one language is better than another.)
One one side we have the ’safe’ languages, epitomized by Java and C#, which are designed to be useable by the average coder of average ability, with a low risk that they will hurt themselves. Interfaces need to be declared explicitly, types are strictly enforced at compile time, and so on. A language of this sort lends itself well to automation, and is likely to have good tool suport in the form of IDE’s, debuggers, code inspectors and the like. There is a limited scope for coders to develop personal idioms and styles - Do you prefer anonymous or named inner classes? Do you declare private members before or after public ones? Is hungarian notation good or evil? - but on the whole, a team of developers with a reasonable turnover of members will find it easy to pass code around between each other without too much discipline. Fitting design patterns to these languages comes easily, and extends the comfort zone a little further.
On the other side, we have the turbo-charged hacker languages, that provide great scope for flexibility and innovation, often allowing the language itself to be extended at runtime. Lisp is the seminal example of this type of ’scary’ language, and Perl is also deeply entrenched in this way of doing things. A skilled practitioner in these languages can knock out functionality in one tenth the time and space of a java or .Net programmer, and extend their code at a similar rate. The downside of this freedom is that the complete flexibility of the language makes teamwork more difficult. By allowing developers to extend the language, radically different idioms may emerge, creating major problems in maintaining someone else’s code. A really good team can enforce the discipline necessary to stick to a common style and feature-set, but the language won’t do the enforcing for you. Design patterns and refactoring can help to maintain the level of discipline required to make these languages work in teams.
Ok, end of pet theory.
Why bring this up now? Sure, Perl used to be a major force in web development seven or eight years ago, but what does this have to do with Ajax? Aren’t these hacker languages fading into obscurity? The terrible truth is that javascript, beneath the java-esque name and syntax, is secretly a turbo-powered hacker language, inspired by none other then Common Lisp! (Appendix B contains more of the gory details.) The danger of creating tangled unfathomable javacript code is relatively high, and as we scale up its use from simple web page tricks to Ajax applications, the reality of this can begin to bite. For this reason, I would advocate the use of design patterns in Ajax more strongly than I would in java or C#.