The Problem with MooTools…

MooTools is without doubt the best JavaScript extension around, providing clean and simple object orientation features such as classes, inheritance, pseudo-events, and more. Yet advertised JS programming roles rarely require this skill, whereas the much more limited, and much less clear, jQuery is almost always required.

jQuery’s primacy is not because it is a ‘better’ system: it doesn’t even have a class model, and class-like features have to be hacked-together in a non-standard manner. jQuery sells because it looks good, and has a huge number of reliable plug-ins.

I recently had call to produce a live data grid, reflecting a database table, and allowing users to make updates to the database table by editing the table on the screen. I found a jQuery plugin within five minutes, and had the code up and running in 15: all credit to jQuery and the plug-in author.

Doing this in MooTools can take all day, though the code produced is easier to maintain and update with new features.

Part of the problem is that MooTools is more compartmentalised. A recent example I came across was trying to produce charts from tabulated data. The wonderful MilkChart library for MooTools,  by Brett Dixon, produces beautiful business-ready charts from HTML tables – but not from MooTool’s Table.Sort or Table.Paginate tables. It only took ten minute this morning to produce a GitHub fork of the project, updated to support these core MooTools features, but it seems curious that such elementary comparability has been over-looked for so long. Perhaps I can gauge the health of MooTools by the state of this fork’s pull request.