- Project requirements. “Is this a Web site or application that requires AJAX, robust support for handling events, or how about a library of effects?” The amount of functionality provided out of the box and of experience needed to support the framework should be considered as well.
- Browser Support. Although most frameworks support most browsers, “…there are often some exceptions in the fine print — typically with Safari on the Mac”.
- Strength of development team supporting the framework. The best frameworks are maintained by a core team of developers. This will result in faster response time to bug reports and questions as well as in more rigor in testing and adherence to guidelines.
- Maturity of the framework. “More than anything, the maturity of a framework demonstrates a commitment to longevity, as well as a solid foundation. A mature framework will no longer be in beta…” A thriving community and support for a Subversion and CVS version repository are other signs of maturity.
- Frequency of public updates and releases. “Long delays and bloated releases are also a sure sign that you will not enjoy supporting the framework on future projects. Alternatively, too many public releases could indicate instability, or a lack of focus.”
- Documentation quality. Documentation is an important differentiator; strong documentation includes the API, books, tutorials and blogs while “the worst documentation is the sort that is only focused on syntax”. Examples with each method and property are also very helpful.
- Existence of an active community. “Are experienced users willing and able to lend a helping hand, or will they send you elsewhere for assistance? Are developers creating extensions, or contributing to the core framework?” The community character can also be a predictor of future reliability on community help.
- Benchmark tests. Benchmark tests can help to get a glimpse into the framework performance aspects. Their existence also proves a certain commitment towards adopting some quality assurance best practices. Also, ”…even a modest gain in speed, or a decrease in download size during a release cycle can be seen as a positive improvement.”
- Is there an extensive set of tests, both functional and unit? - submitted by Kanjax
- Is there any commercial support available?
Beware of these frameworks if your app requires high performance. Prototype, jQuery fall over terribly when using large tables and grids.Another commenter pointed out that Mootools has a page benchmarking Protoype, JQuery & Mootools.
I’ve done extensive benchmarking for my current project at work which is very AJAX heavy and will use at it’s core large tables.
I’ve experimented with both jQuery and Prototype and the performance was always lacking. The problem? document.getElementById(). DOM lookup is VERY expensive. In fact, our tests seem to suggest that DOM lookup is not done via hashing.
A lot of these frameworks add extensions that many times you will not need, slowing performance down. Our solution has been to study what is beind done and write our own code, minus all the extensions and any extraneous framework support it is doing.
But for small webpages without large tables, Prototype or jQuery work very well and are nice to work with.
No mention of unobtrusive vs obtrusive?!?
On the other hand, jQuery and Prototype, and their UI plugins, tend toward unobtrusiveness. Or at least you have more of an option on how obtrusive you'd like to be.
This is not to point out those frameworks, but rather the glaring omission from the article above.
So the answer is...
What framework to use for Ajax heavy applications?
Craig Motlin Sep 01, 2014