BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Selection Criteria for Javascript Frameworks

Selection Criteria for Javascript Frameworks

This item in japanese

Bookmarks
With the continuous growth of AJAX technologies adoption, many developers and architects are still trying and sometimes struggling to determine what are the best ways to evaluate Java Script frameworks/libraries. Brian Raindel offered some advice on the various aspects one should consider during the selection process, summarized here:
  • 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.”
  • Extensibility of the framework. “Plugin support is definitely a plus for any JavaScript framework, but developers usually just want to know — how difficult will it be to troubleshoot the core library?”
  • API Style. “This is an important, but complicated question that is answered for most developers only after using several JavaScript frameworks on numerous projects. Terseness, as well as chainability, are two very important features that should not be overlooked.”
Some of the comments following up in the post could also make the list of selection criterion to be considered for JavaScript library choices:
  • Is there an extensive set of tests, both functional and unit? - submitted by Kanjax
  • Is there any commercial support available?
A number of commenters spoke positively about JQuery, although Ian cautioned against JQuery and prototype in high performance scenarios:
Beware of these frameworks if your app requires high performance. Prototype, jQuery fall over terribly when using large tables and grids.

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.
Another commenter pointed out that Mootools has a page benchmarking Protoype, JQuery & Mootools.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Great Stuff

    by Beren Erchamion,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    This is great stuff - but why only Javascript. This would seem to apply to all things...especially open-source.

    beren

  • No mention of unobtrusive vs obtrusive?!?

    by gcom nz,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    It's an interesting list, but it seems to leave out one of the single most important evaluation criteria: whether the framework leans toward unobtrusive or obtrusive JavaScript.

    For instance, ExtJS tends to be highly obtrusive, but suitable for some people who don't mind coding lots of their interface in JavaScript rather than HTML.

    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...

    by Thom Nichols,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    ?? He gives a bunch of generic criteria, most of which _do_ apply when selecting any type of framework. The he doesn't really give any answers, other than "Prototype and JQuery can be slow." So I guess that means Dojo, YUI, ExtJS and MooTools are faster?? We don't know because the whole thing was kind of lacked detail. Other than where he wrote that they re-wrote the framework with just the parts they needed. That doesn't really seem like framework selection to me. That sounds more like "roll your own JS framework."

  • jQuery Ajax function

    by yuanfeng xia,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    We can use the part of the jQuery function.

  • What framework to use for Ajax heavy applications?

    by Hussein Baghdadi,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    If Prototype & jQuery aren't suited for Ajax heavy applications, then what should we use?

  • Re: What framework to use for Ajax heavy applications?

    by Jep Castelein,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    @ Hussein: you could take a look at Dojo, Tibco and Backbase. Those are some of the more comprehensive Ajax frameworks.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT