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…

A while ago, I wrote a snippet about MySQL replication. Well, I finally started playing with it not long ago, and was very successful. Apparently it works well, even for someone who hasn’t set it up before. Nice. I haven’t actually set this up on beeets because we don’t need it yet, and also I haven’t played with it enough to feel confident using it on a production basis.

That said, our Lyon Bros aframe framework now supports replication. It sends selects to the slave, writes to master, last_id to master, transactions to master, etc. Basically the only thing that slaves get are dumb selects (which are most of the queries anyway). I had the opportunity to test this out with the play MySQL replcation setup, and it works perfectly. It was nice to see something that complicated actually working.

Right now, it only supports connecting to two servers: master and slave (it holds off on connecting to those servers until one of them actually gets a request to save time on request startup). Basically, aframe doesn’t support load balancing. This means that if you have more than one master or slave, to use replication effectively, you’ll have to use a MySQL replication load balancer (either software or hardware). This will give you a single IP address to send requests to, but distribute the requests automatically to improve load times.

Hopefully we’ll need to set this up soon, but for now, just the one MySQL server will do =). Sometime within the next few months, we plan on releasing aframe as open source. It’s licensed and ready to go, but we have no documentation…and just saying “check out CakePHP and hope it works the same” won’t fly…especially since aframe is 23,148,855,308,184,500x better than Cake.

One thing I’d like to check out on round two of replication tinkering is Maatkit. From what I hear, it automates a lot of stuff I would be writing scripts for and checking every day. I looked at it a while ago and it seemed overly complicated, but that was even before I tried to get a server replicated. Maybe nowadays it would be easier.