A question I often get asked is whether Byng uses the jQuery JavaScript library and another popular follow up question is why not. Source of much self reflection and questioning I often found myself wondering why I don't feel at home with jQuery as much as Mootools. That is until I read an excellent blog post on Clientcide explaining some of the theory behind Mootools.

Without summarising the article (which makes some generic points applicable to many JS frameworks) several key points really stuck out and apply aptly to Byng's company philosophy on software development.

Programming to the Pattern

...calling "Programming to the Pattern." It goes something like this: when I write my code, I can choose to be an architect, or a construction worker. I can design, or I can implement. In reality, I must do both, but I can choose which one I want to do more and, in many ways, it's possible for me to do almost entirely one or the other - though not 100%.

This couldn't be truer for a technology company choosing a JavaScript framework and I feel, like the author of the post I reference, that Mootools "makes it hard to avoid writing your own code this way". Mootools provides a rigid framework capable of serving multiple levels of abstraction paving the way to more reusable code with a lower cost of maintenance and extensible classes.

Extensibility

Although jQuery has a defined coding pattern (excellently summarised in a blog post about plugin development patterns) in my view it simply does not provide enough guidance for abstraction and separation of concerns (although the jQuery plugin authoring page does provide a neat way to create "closure" around JavaScript functions). This is expressed somewhat by the fact that the jQuery head honcho, Bill Scott, is purported to have suggested that jQuery needs augmentation of some kind to implement a useful "class" structure.

Although jQuery has implementations of objects factories and templating, for example Classy jQuery, I am yet to find a hardy and well thought out solution. One could reasonably be expected to use JavaScript's own native prototype inheritance but, for me at least, it simply feels like going backwards against using the Prototype JS object oriented approach.

Moobyng...

So for our core framework and software products Mootools simply enables clearer, maintainable and more reusable JavaScript code. As a core philosophy extensibility is high up on our priorities and for that reason Mootools is surely the framework of choice for our application development.

However, if the decision was that simple, why the hesitancy to embrace Mootools? My singular concern with Mootools is the limits of extending the native JavaScript objects and the associated memory leaks or limitation of runtime speed in Internet Explorer. For this reason jQuery may still be my framework of choice for enterprise applications deployed in environments where the still ubiquitous Internet Explorer is abundant. Fortunately our portfolio of clients are "cool" enough to use Firefox, Safari and Chrome in their offices where our business applications roam the world. So until the time we will be sticking with Mootools but keeping a beady eye on jQuery!