So I posted yesterday in my flurry of catch-up posts about the mad4milk.net guys new framework: MooTools. I’ve had a little time to dig into it and I must say that I’m blown away. In many ways, this is the framework that I’d say CNET should write for itself if it were to take on such a task.
…

The Yahoo UI is really powerful and easy to implement. It’s extendable and well documented. Yahoo hired a staff (Bill Scott from the Rico project and others) to come and do precisely that: write a toolset so all their developers could easily drop code into their layouts and make cool looking stuff. By authoring their own UI library they solidified their environment around a specific framework and created stability for the developers.

With our (well, mine and Andy’s) focus on Prototype, which is more lower-level than the Y!UI library, we’ve been dealing with the shifting sands that come with open source frameworks. Because Javascript doesn’t rely on a compiler (unless you want to use the Google API or something), these shifting sands create maintenance issues for us when those things are updated and improved. If we stick with one library/framework (like Prototype) we’re probably ok, as these groups try and keep their code backwards compatible.

But Prototype isn’t like the Y!UI library in that it doesn’t give you a lot out of the box. You have to put something on top of it - your own code or Scriptaculous or moo.fx or whatever - to be able to actually do something, where as the Y!UI library is designed to give you specific functionality: drag and drop, fading, resizing, etc.

Which brings me back to MooTools. MooTools is still pretty low level stuff. Their class creation/inheritance model is really slick and their chainable functions (similar to jQuery’s model - Element.addClass(’x').removeClass(’y').resizeTo([100,200]) etc.) are really powerful and tidy.

But right out of the box you get some really nice functionality that you can implement really quickly. You get popup tooltip stuff, you get accordians, draggables, sorting tables, JSON support, cookie handling, event handling, and Ajax (and more).

When you look at Prototype (and Scriptaculous), these frameworks are exceptionally powerful. They offer you the kind of functionality that you’d need if you were writing a web based application. If you wanted to build a Goolge Maps or a Page Flakes or the like, you’re going to want what Prototype and Scriptaculous have to offer, and you’re not going to care about the 100K-200K price tag that comes with them.

But we’re not building that kind of application. We’re enhancing what is still fundamentally an html layout, and we do care about page weight. Looking at what MooTools has to offer, and how extendable it is, I’m hard pressed to say that there’s anything else out there that’s more appropriate for work here.

Now, I’m not saying that Prototype doesn’t have a place for our work here. But I am saying that we can meet most of our needs with MooTools for less page weight. After chatting about this with Andy this morning, I’m going to spend some time creating a prototype.lite.lite file - one that removes any redundancy that might exist with MooTools - and put together a library that combines the basics of Prototype with the MooTools library. This may sounds like a bad idea to some of you, but give me a few days and I’ll post the results with more detail and you’ll see where I’m headed.

BTW, in case I hadn’t mentioned it, MooTools and Prototype won’t conflict with each other (though they will duplicate some of each other’s functionality), so it seams that you can include both in the same page and not worry about conflicts.

If you have the interest and the time, I highly recommend checking out this library.