In order to introduce Mochikit, I feel I need to give some context about myself and Javascript. I’m a designer. I’m a designer who has learned a particular amount of programming only to do what I needed to do. I ‘know’ javascript, but not at all like these guys do. So my look at Mochikit is from a ‘know enough to be dangerous’ perspective, but hopefully a few of you might find my translation of the power of Mochikit valuable.
What Is It?
Mochikit is essentially a Javascript programming library much like a few others that have popped up. It’s claim is to “Make Javascript Suck Less” which anyone who’s developed much in Javascript can certainly understand. It also has one very important aspect to it, Mochikit is 100% documented and is well tested. This means that the lead developer, Bob Ippolito, ensures everything contributed to Mochikit has documentation. This is a big score over the other libraries out there who have little or no documentation what-so-ever.
Mochkit Highlights
While what I know about Mochikit is but a fraction of what it can do, (and I understand even less) I found a few features to be essentials. The first and foremost is the Mochikit.DOM namespace and it’s DOM Coercion methods. A quick sample:
var newRow = TR( { 'class' : 'alternate' }, TD(null, "my cell data"));
swapDOM{'oldrow', newRow);
This sample is all the coding it takes to create a new table row, and swap it with the old one. Mochikit.DOM contains a number of methods that make creating new DOM elements a breeze. Then to take it further, it has a number of shortcut properties for all your basic HTML nodes (such as TR and TD used above). These shortcut methods take two arguments, an array of attributes, and any child nodes you would like to place inside. This is the easiest and shortest code I’ve ever found to create DOM elements in any library. Take that and couple it with a number of helpful functions like swapDOM to get your elements into the document, and you’ve got an effective one-two punch. These are especially useful when using AJAX to update a screen. (Mochikit has a great AJAX implementation as well)
It’s this type of intelligent programming that you will find all throughout Mochikit. features such as Mochikits’ Mochikit.Iter namespace includes some robust iteration tools that can make looping through a group of objects much more useful than a complex for loop. There’s also handy functions like map, which uses Mochikits own iterable tools to take each element in a collection and apply it to a function.
Debugging, which is always a pain in Javascript, is aided by an extensive logging system which let’s you keep alert and document.write out of the picture for seeing what’s going on in your code. Bob even created a handy bookmarklet that will pop-up the logs of any Mochikit page to the screen. Don’t need to see anything? No problem. Need a quick peek at what’s going on? Hit the bookmarklet and see your trace statements live.
Most of the features in Mochikit I don’t fully understand yet. This is primarily because I don’t program heavily in Javascript. If you do any hardcore Javascript programming you’ll probably see the power of Mochikit right away. However, what I did use, I found so immensely useful that it was enough to sell me on Mochikit.
What you should know about the other libraries
One of the more talked about a popular libraries out right now is prototype. Prototype has also spawned a few libraries based off of it such as Rico, Behavior, and the well known script.aculo.us.
The reason it’s important to know about Prototype and the libraries based off of it, is it has a serious flaw. Essentially it works by extending Javascripts base class Object. The problem is everything in Javascript is an object, and by extending Object you will inadvertently get properties you didn’t intend.
var mydata = {somevar : 'value1', anothervar : 'value2', thatvar : 'value3'};
for(prop in mydata) {
alert(prop);
}
The above code will contain some unwanted hitchhikers, namely you will get an alert for a mystery property called ‘extend’. Considering that passing data and variables around this way is very common, especially into a function, this would mean quite a bit of hackery to avoid those extra properties.
What Mochikit does instead
Mochikit shuns this type of class based inheritance for more functional style programming. This means rather than extending any base classes, Mochikit contains a series of functions within a namespace. While being an X-.NET guy and completely sold on Object-Oriented programming, I found this a little difficult…at first.
This is where the documentation comes in. Since remembering a name such as doThisToThatPlease() is a chore, the documentation makes picking up Mochikit your first few times a snap. Once you learn the common functions you use often then there isn’t much difference. If your a Python guy, then you probably already know what a lot of Mochikit does as it was modeled very heavily from Python and Python libraries.
Don’t worry about missing out on those cool effects from script.aculo.us either. For starters Bob Ippolito made sure Mochikit is still compatible with the popular Prototype based libraries (Meaning it used the hackery to route around the Prototype flaw if it’s present). Second, is there’s already talk of porting similar functionality over to the Mochikit.Visual namespace in the Google Group. Since Mochikit is as open source as you can get, anyone can extend Mochikit with these effects.
Wrap Up
If your into heavy Javascript programming, the AJAX model of updating a screen, a Python developer, or know what XHTML is, then you should take a peek at Mochikit. The guys behind it are very passionate about what they do, and very knowledgable developers well beyond just Javascript. It’s this experience that I think makes Mochikit what it is, a smart library intended to help Javascript become useful as a development platform. This is the key to Web 2.0, that the browser is now a platform rather than just a document reader. In order to get there, you need serious engineers working with a robust language. With Mochikit making “Javascript Suck Less”, we just might get there.
Published on August 20, 2005
Resides in CSS/XHTML, Web Technologies
No comments yet.