Hey Mr. wide-range questions :-),
There are number of toolkits to implement AJAX on an application.
How should a developer make a choice among these? How is prototype and script.aculo.us different from others? How are the objectives of Protoype and Script.aculo.us different from the rest of the kits? For What kinds of applications should a developer make a choice to and not to Prototype?
Hmm, okay. Let's tackle this.
1. How to choose a JS framework There's no "best framework" out there. As always, there is just "the best framework for your current project," and even at such a narrow scope you may well find several frameworks are equivalent, so it will boil down to which "coding style" suits your liking best.
Each framework comes with its scope, its philosoph and core design decisions, a resulting syntax style and coding idioms, some documentation, and possibly a community.
You should consider the following points when choosing one (in no specific order):
� What do I need a JS framework for? Which frameworks fit the bill, feature-wise?
� Can I assume this framework will rule the whole page, or am I developing in a context where it may collide with other JS libs on the page? In the latter case, which frameworks "play nice" with other libs in the same scope space?
� What does idiomatic JS code look like when using such or such framework? Do I find the resulting code to be readable and elegant, or does it confuse/irritate me?
� How good is the online documentation? Are there many books on it, and what is their quality? Is this mostly reference material or are there good tutorials too?
� Is there a vibrant, active community around the framework? Is it easy to find help? How well are n00bs treated on the forums?
� How actively is the framework maintained? Can I trust bug fixes and patches to be implemented swiftly?
� What is the framework's code quality? Is it robust? Is it fast? Does it come with massive
unit testing?
2. How do Prototype and script.aculo.us differ from the others? Let's take the list you mentioned:
� Prototype is a
middleground framework: it's not just "smoothing out browser incompatibilities" (like Dean Edward's Base2 focuses on), it's also providing a core set of features that we feel every webapp needs: stupid-easy Ajax, powerful DOM manipulation and CSS-based extraction, form observation, and enhanced JavaScript types. Prototype goes the pragmatic route by extending the native types directly to shorten the syntax and make it unobtrusive. However, the price to pay for this is that we don't coexist very well with other libraries in the same page space: as soon as they use a for/in loop on native-type objects, for instance, they'll see our extensions (and the fact that they
shouldn't use for/in in most cases doesn't alleviate the problem).
� script.aculo.us is a
widget/effects framework that focuses on core widgets and visual effects not specific to desktop-like UI: fades, movements and morphs, auto-completion, drag and drop, in-place edition and sliders. They can fit in any page style (and I sure use them in many pages that don't look alike at all�). It's entirely dependent on Prototype, it's Proto's sister library, if you will.
� jQuery is the featherweight of JS libs (only Dean's Base2 is lighter, I believe). It exists in the same goal/feature-space as Prototype/Scripty, but (a) chose to be entirely encapsulated in its own namespace, so it plays well with other libs in the page and (b) has a very different-looking code. In my personal opinion, I find jQuery to be quicker to get started with and tinker with, but harder to "discover." Prototype's API is very consistent and convention-based, and therefore easily "discoverable." I find jQuery to be more of a toin-coss when you try out stuff: just because code looked that way in one instance, or situation A featured extension B on object O, doesn't mean that the same applies in a similar-yet-slightly-different situation.
� Dōjō is a full-fledged SDK, so to speak. It's the JsDK, if you will, it's a full-fledged app development framework, complete with numerous processing algorithms, collection types, and desktop-app-like UI widgets. It's massive, although it went through some significant diet with its 0.9 rewrite and is now a bit more modular (core, digit, dojox). It is mostly designed to be the one framework in the page, and targets webapps that should feel like desktop apps with a very rich set of widgets (trees, tables, check lists and the lot).
� Yahoo! UI has the same scope as Dōjō, but obviously its backing by Yahoo!, even these days, carries major weight. The fact that Yahoo! uses this lib for all its recent needs, on many properties, and provides a CDN for it is certainly a major point. The code quality is generally excellent, and the docs are very good. On the other hand, it's not open-source (in the sense that only Yahoo! develops it with no particular care for external input).
� Mootools: let's just say I'd rather not talk about them, that despite excellent skills within their team they don't add much to the mix, and they tend to make any other framework team want to blow off some steam now and then.
� Ext: they're mostly an "overkit" that you can plug around your favorite framework as a core (an impressive design feat!). They're nice and have cool docs, but I can't really go into details about the lib, I don't know it well enough.
Most of these libraries have pretty good online docs, although jQuery, Prototype and script.aculo.us lead the race offline (books-wise). With Dōjō, they also feature a vibrant community with plenty of help channels and quite a few quasi-official websites in addition of the official ones. They also all offer varying levels of "plugins" or third-party extensions (jQuery has a formal plugin support, Prototype has the Scripteka repository and will soon introduce its own formal extension system, etc.).
3. Differences of objectives / apps for which to (not) use them? I can't quite vouch for the other ones (I'm sure Bear will be glad to chip in about jQuery, for instance), but for Prototype and script.aculo.us, here are a few things to know.
� We're first and foremost trying to provide a nice, simple, consistent API that lets people script web pages easily and elegantly.
� We're all Ruby lovers, so our language extensions are partly guided by how we're trying to emulate some of Ruby in JS (the libs will work fine with any server-side tech though, not just Rails, for instance).
� We are VERY big on automated testing. Prototype features an enormous amount of unit tests, for instance, and we don't apply any patch that does not come with the proper tests, unless what we're patching is not at all testable in an automated way. So the codebase is very robust.
� We eat our own dog food, obviously: the codebase uses itself all the time.
� We're NOT trying to be a full-fledged SDK or to cater to desktop-like UIs. We believe a web page should look like a webapp, not a desktop app. You'll find plenty of desktop-UI stacks that are based on Prototype, though.
� We're actual open-source, with a MIT-style licence, we welcome (tested) patches through our Trac, RFEs on the Prototype-Core list (Google Groups), and provide nice, noob-friendly help on the RubyOnRails-Spinoofs list (ibid.).
Well, I'd better get back to work. 'hope this helps,
.
