Stuart inspired me to do an objective evaluation of all the toolkits out there and then make a choice. So, here it is, my personal evaluation and reasons for choosing what I chose!
|Google Web toolkit||Custom||Java – Integrated AJAX Library||Great widget set, easily extensible, it’s from Google!||Java based, no pretty visual effects, Bad license|
|Echo2||Mozilla/LGPL||Java – Effects and UI library||Fantastic widget set and eye-candy, Smooth rendering||Java based, No control on JS|
Okay, so that’s the brief summary. I haven’t included prototype in the list because its too fundamental and a lot of the toolkits are actually based on it. I also have probably missed many more toolkits, but these were the ones that caught my eye.
The main factors that we kept in mind while making the choice were:
License. It is important for the toolkit to have an open license that falls within the limits of the Gentoo Social Contract.
Infrastructure. The toolkits’ deployment requirements must be something that the Gentoo-Infra team can provide.
Documentation. It shouldn’t take a long time to learn the toolkit itself. One of the important requirements of the project is rapid prototyping since the UI forms a core component of the editor.
Stability & Support. The chosen toolkit should obviously not be one that is dead. It is important for the toolkit to be stable, and under active development; since the application may be used by hundreds of people.
Features. Of course, the stuff that the toolkit offers should match with what we require. Ideally, it shouldn’t offer anything more nor less.
Based on the above, all Java based tollkits are out. The GWT has a particularly restrictive license. I wasn’t too comfortable YUI because it wouldn’t validate. I ruled out Dojo because it wouldn’t work in Opera. I am not too particular about the application working on IE, but I would expect it to work smoothly in Firefox and Opera at the very least. I started out with OpenRICO but then realised that I’m spending too much time finding out what functions it offers.
MochiKit offers most of the effects that script.aculo.us has, besides being one of the most awesome toolkits out there. One look at its documentation, and I knew this was it. It’s very programmer friendly, and work exactly like how you expect it too. MochiKit forms a very nice abstraction layer over JS to hide all the gory browser quirks. Its visual library however, is a bit broken, basic functions such as Move’ or Scale’ are broken, although they’re working on it for 1.4.
I couldn’t not use MochiKit just because of its Visual Effect backdraw, the other stuff that it offers are just too amazing too miss. So here’s where the X library comes in. I believe MochiKit and the X Library to perfectly complement each other; use MochiKit for the Model and Event Handling, while leaving X to do all the jazzy stuff. It’s working out quite well uptil now, although ideally I would prefer to use MochiKit alone (If only the Move’ function would work!). But then, X is quite amazing too, and its fun to use both the toolkits.
So that’s that, I’m going to go ahead with MochiKit and the X Library. More on how the UI is going to turn out later.