Here’s a good tip I just found. Note that this may not be for all cases. In fact, I may have stumbled on a freak coincidence. Here’s the story:

I hate java. I hate having java on a server, but hate it even more if it’s only for running one small script. Forever, beeets.com has used the YUI compressor to shrink its javascript before deployment. Well, YUI won’t run without java, so for the longest time, jre has been installed collecting dust, only to be brushed off and used once in a while during a deployment. This seems like a huge waste of space and resources.

Well, first I tried gcj. Compiling gcj was fairly straightforward, thankfully. After installing, I realized I needed to know a lot more about java in order to compile the YUI compressor with it. I needed knowledge I did not have the long-term need for, nor the will to learn in the first place. I, although revering myself as extremely tenacious, gave up.

I decided to try JSMin. This nifty program is simple, elegant, and it works well. It also has a much worse compression ratio then YUI. However, I trust any site that hosts C code and has no real layout whatsoever. Knowing the compression wasn’t as good, I still wanted to see what kind of difference gzipping the files would have.

I recorded the size of the GZipped JS files that used YUI. I then reconfigured the deployment script to use JSMin instead of YUI. I looked at the JS files with JSMin compression:

YUI:
mootools.js     88.7K (29.6K gz)
beeets.js       61.5K (20.5K gz)

JSMin:
mootools.js    106.1K (29.5K gz)
beeets.js       71.0K (17.7K gz)

Huh? GZip is actually more effective on the JS files using JSMin vs YUI! The end result is LESS download time for users.

I don’t know if this is a special case, but I was able to derive a somewhat complex formula:

YUI > JSMin
YUI + GZip < JSMin + GZip

Who would have thought. See you in hell, java.

I just stumbled onto this tonight: The Mootools plugin forge. Pretty sweet. Tons of fan-based plugins for Mootools in one spot. Check it out!

So after reading a very good comparison between the two frameworks, I have to say I feel good about my decision to use Mootools in pretty much all of the sites I build. This isn’t because of some nebulous reasoning about Mootools being better than jQuery, but the facts are

• They both do different things, and do them very well
• They intersect in some places (mainly DOM parsing)
• They both have their uses, pros, and cons

I was considering looking into switching beeets.com to use jQuery, but wanted to do some research beforehand. I’m glad I did.

It seems that jQuery is popular because it removes the hassle of doing everyday Javascript chores. Quite frankly, I’ve known Javascript for quite some time, and don’t mind getting my hands dirty in it. So using a framework that abstracts that out and creates what seems like (from reading the syntax) a whole new language makes me groan.

Mootools seems to better extend Javascript itself, and provides the tools to extend it even more. So if you already know JS fairly well, you can look at Mootools code and still tell what’s going on even if you only have an extremely limited knowledge of Mootools. It also implements some great features that allow you to reuse code extremely intelligently. So intelligently, in fact, that in much of the code on beeets.com (JS heavy), we’re actually not tapping into the full power of Mootools. Whoops.

That is another point I wanted to bring up, though. When Mootools 1.11 and earlier was around, things were great. The framework was good, the docs were good, the examples were good. Come 1.2, they changed their site (much uglier), castrated the examples, and the documentation is, in my opinion, pretty jenky. There are no good tutorials on their site, and it seems like there are many features I’ve never tapped into because, well, I just never knew about them.

This is half my fault, half Mootools’. I should be doing my research, but educating those using your framework is a must as well. Let’s hope they work on it, and in the meantime I’ve got some reading to do. It doesn’t help that the update from 1.11 to 1.2 changed an assload of conventions, classes, and method names.

All in all, it seems like Mootools is the way to go if you are already great at Javascript…and I am. That being said, it may be worth me learning jQuery to do simpler DOM parsing and AJAX. For larger projects that actually need to reuse big pieces of code and do more than parse the DOM, I’ll gladly stick to Mootools.

Let the flames begin…

Is it just me or does programming with the new mootools (1.2) suck balls? They changed (and broke) a lot of unnecessary things. Tool tip titles are broken, form.send() no longer works, $E and $ES are “deprecated”…more like too easy.

Come on, MT guys, what the fuck are you thinking? This post is a little late, but I just finished converting beeets (JS heavy) to use MT1.2 and it was a big fat pain in the ass.

Plus, the documentation is lacking, the demos are castrated and only about half of them are there, and the new site just sucks in general. Bring back the old website, plz!!

Ok, everything sucky about it aside (everything), it does work marginally better. Some things that were buggy (IE of course) in the old mootools 1.11 are now working smoothly. Was it worth it? If one person has a better experience on the site because of it, yes. If not, then fuck…waste of my time.

But gee willickers, I can’t wait for version 1.3!!

“We released Mootools 1.3! BTW it’s not compatible at all with 1.2!! AND WE CHAINJED OWR WEBSIGHT AGAYN!! LOL BAI!”