d’bug » Blog Archive » How to choose a JavaScript framework

How to choose a JavaScript framework

Posted by Brian
Posted on October 30th, 2007
View Comments

Efficiencies. Projects live or die by them. A JavaScript framework may not make you a better programmer, but it will make you more efficient. That alone should be reason enough to choose a JavaScript framework, or library if you prefer. Unless you decide to build your own, there are plenty of options available to developers. However, choosing the right framework can be tricky, and weeding through a mess of opinionated fanboys (myself included) is intimidating.

The best advice I can offer is to be flexible in your approach, and to ask the right questions. This list should help you get started.

What are your project requirements?

The first and most important question you need to ask yourself is what are your project requirements? Is this a Web site or application that requires AJAX, robust support for handling events, or how about a library of effects? How much functionality do you need out-of-the-box, and what level of experience will be required by other programmers and designers to support this framework? If you have few requirements, you could find success with an extremely lightweight, modular library.

Does the framework support A-Grade browsers?

Once you know your audience, and your project requirements, you need to consider whether or not your JavaScript framework should support A-Grade browsers. Most frameworks do, but there are often some exceptions in the fine print — typically with Safari on the Mac. If you are building an internal Web application for an Intranet, you might only be required to support a limited set of browsers. Regardless, making the grade is an important consideration.

Is there a core team of developers?

Several JavaScript frameworks are built by a single developer, but the best are maintained by a core team of developers. This helps to ensure regular updates, prompt response to bug reports, and open access to get questions answered in a timely fashion. With a core team of developers, it is likely that the code is more rigorously tested, and adheres to specific style guidelines. A single set of eyes can more easily overlook the obvious.

How mature is 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, and will have been through a full release cycle. There should be a growing, if not thriving community, and depending on the open-source license, a mature framework might also support a Subversion or CVS version repository. Any bug fixes can be rolled into a build without a public release, which is a huge plus.

How often are updates publicly released?

Even though there is no hard and fast rule, you still need to ask this question. If you find that the community questions or complains about the release cycle, then that could be a warning sign. 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.

How friendly is the documentation?

A major differentiator between JavaScript frameworks today is documentation. This not only includes official documentation for the API, but also includes books, tutorials, and blogs. The worst documentation is the sort that is only focused on syntax. Look for a framework that includes examples with each method and property, and that is updated to meet the needs of the community. Documentation is simple to research, and it can be a lifesaver when dealing with tight deadlines.

Is there an active community?

An active community does not guarantee a quality framework, but it does help a framework evolve. The character of the community is also an excellent gage of the type of help you might receive in the future when caught in a bind. Are there forums, or a Google Group? 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? All of these are important questions.

Are benchmark tests performed regularly?

I have yet to discover a JavaScript framework that brags about bloat and memory leaks. Yet, without benchmarks, how could you possibly know either way? Benchmark tests are often questionable when determining the quality of workmanship put into a framework, but they do demonstrate a developer’s willingness to adopt some quality assurance best practices. Even a modest gain in speed, or a decrease in download size during a release cycle can be seen as a positive improvement.

How extensible is the framework?

Extensibility is typically a requirement of experienced programmers, and is rarely a request of designers. 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? Layers of functionality provided by an active community do give a framework uniqueness, but this is a beneficial byproduct, and not often a necessity.

Do you like the API style?

This is an important, but complicated question that is answered for most developers only after using several JavaScript frameworks on numerous projects. Complaints about frameworks like Yahoo! UI are generally in regards to the style with which the API has been designed. Terseness, as well as chainability, are two very important features that should not be overlooked. Remember, you can grow irritated quickly because of cumbersome implementation details.

Tags: framework, JavaScript, tips, tricks

A day late and a dollar short... comments are closed.

01 | October 31st, 2007 at 1:03 am

Hi,

The Mootools guys released: Slickspeed a benchmarking framework for any / all frameworks.

You can also download the code and test any other frameworks / versions

Comment by:

Ross

02 | October 31st, 2007 at 2:57 am

Hi Ross,

Thanks for sending that along!

It makes for a very interesting comparison.

Comment by:

Brian

03 | October 31st, 2007 at 11:41 am

11) Is there an extensive set of tests, both functional and unit?

(I’m surprised this extremely important aspect didn’t make its way into your list)

Other than that, good overview

Cheers,
kangax

Comment by:

kangax

04 | October 31st, 2007 at 12:07 pm

Hi kangax,

Thanks for the feedback. What would be the best way to observe some functional and unit tests in action for a user who has not chosen a framework yet?

I’ve viewed benchmark comparisons, but other than seeing the frameworks used in the wild, do you have some URLs for any frameworks that are currently doing unit testing?

Thanks!

Comment by:

Brian

05 | October 31st, 2007 at 3:30 pm

[...] How to choose a JavaScript framework Â» dâ€™bug (tags: javascript evaluation framework library performance choose howto webdev web development) [...]

Comment by:

napyfab:blog» Blog Archive » links for 2007-10-31

06 | November 1st, 2007 at 11:31 am

These are all great and perfect things to consider. Nearly all popular libraries are good for a job, but these things you mentioned need to go into consideration before one is picked. In some cases, it’s not even necessary to have any, or simply just roll out your own.

Comment by:

Dustin Diaz

07 | November 1st, 2007 at 12:36 pm

Hey Dustin,

I think too often I fall into the trap of just loading in jQuery. I have been trying to get away from that habit, especially if all I need is some basic functionality.

I think that’s why more and more I consider Mootools. If I need some selectors, I load that in, or if I need some AJAX functionality I load that in — keeps things small when needed.

Or, I just go to your site and steal a bunch of code ;)

Comment by:

Brian

08 | November 1st, 2007 at 1:12 pm

There are toooooo many js frameworks working around the web atmosphere, any one with your default sintax (or not), and there are we, trying to understand what is the better choice for any kind of project.

Comment by:

Luiz Jr. Fernandes

09 | November 1st, 2007 at 1:16 pm

Great writeup Brian, very helpful. I have to say that I default to jQuery quite often as well — for better or worse :p

The only thing I would add is to ask yourself, “Do I even need a framework?” On smaller projects, writing your own mini-framework can make things easier to use down the road, especially if you don’t need all the extra functionality that x library offers.

Comment by:

Hamish M

10 | November 1st, 2007 at 1:57 pm

[...] With so many good JavaScript frameworks available, it’s getting harder to decide in which direction to head. Brian Reindel offers some good advice to those looking to embrace a framework but aren’t quite sure what to look for. A JavaScript framework may not make you a better programmer, but it will make you more efficient. That alone should be reason enough to choose a JavaScript framework, or library if you prefer. Unless you decide to build your own, there are plenty of options available to developers. However, choosing the right framework can be tricky, and weeding through a mess of opinionated fanboys (myself included) is intimidating. [...]

Comment by:

Javascript News » Blog Archive » Choosing a JavaScript framework

11 | November 1st, 2007 at 2:37 pm

I definately agree that there are quite a few choices, and I think educating developers not only about the differences between frameworks, but the techniques used in them is just as important.

Comment by:

Brian

12 | November 2nd, 2007 at 1:46 am

[...] Anyone who has delved into web development ends up working on a project that will require a lot of JavaScript programming. I have done numerous projects where I started off with making my own library, and everything worked fine. But, occasionally, it’s a good idea to use an existing JavaScript framework (library) to save time on development. I have used JQuery so far with great success, and have begun experimenting with Prototype for an upcoming project. It is just in time that I came across a via Ajaxian entitled “How to choose a JavaScript framework” which discusses the criteria upon which to choose the best JS framework. The author, Brian, covers many different aspects of JS library selection. Here’s a summary of the factors to consider: [...]

Comment by:

Choosing the right JavaScript framework

13 | November 2nd, 2007 at 3:17 am

[...] Und wer sich noch fragt, warum, wieso, weshalb Ã¼berhaupt ein Framework benutzen und nicht alles selbst basteln kann sich vielleicht an diesem Artikel ein paar Antworten holen. [...]

Comment by:

JavaScript Framework : flash und so…

14 | November 3rd, 2007 at 11:59 pm

jQuery has a testing url here

http://jquery.com/test/

Is that an example of what you were looking for?

Comment by:

David

15 | November 4th, 2007 at 10:38 am

Hi David,

Without a good sense of what the numbers mean, it is hard to tell, but this appears to be an in-house benchmarking tool for jQuery?

Brian

Comment by:

Brian

16 | November 4th, 2007 at 2:30 pm

Sorry, you had asked “do you have some URLs for any frameworks that are currently doing unit testing?” and I was answering that question. This is jQuery’s unit testing.

I should have been more specific in my first comment. I have seen it used to test against patches added to the core.

Comment by:

David

17 | November 4th, 2007 at 2:57 pm

Hey David,

No problem — I was just curious what the numbers mean. Do you have a URL that talks some about how it is used? I think it is a great tool that gives credibility to the jQuery team.

Comment by:

Brian

18 | November 4th, 2007 at 8:46 pm

I’m not aware of a url with that explaination. But I think the numbers are just details about the tests themselves. The red is how many failed for that type of test, the green how many passed, and the black is how many total.

Comment by:

David

19 | November 7th, 2007 at 2:05 pm

Wow, the only library you mention by name, YUI, you allude to problems in the coding style. In comp.lang.javascript, YUI is the only library that earns even the slightest respect as to coding style.

So, either $(you don’t know what you’re talking about) about or YAHOO.comp.lang.javascript guys including Crockford, Cornford, etc. don’t know what they’re talking about.

My, my.

Comment by:

beegee

20 | November 7th, 2007 at 4:03 pm

@beegee

That is one of the most ridiculous blanket statements I have heard in quite some time. Before you go making generalizations, please provide me with an affidavit from every developer on that Google Group, stating that they do not respect any JavaScript library other than YUI. I have read a few threads myself that would prove otherwise.

Then, please email Crockford and Cornford and apologize for my daft comment as well as for the personal preferences of thousands of developers. It is obvious that none of us know what we are talking about, and since you know both of these gentlemen personally, it is best that apology comes from you on our behalf.

Comment by:

Brian

21 | November 20th, 2007 at 9:25 pm

Nice write-up. But I would add a caveat to most major JS frameworks.

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 frameowkr support it is doing.

But for small webpages without large tables, Prototype or jQuery work very well and are nice to work with.

Comment by:

Ian

22 | November 21st, 2007 at 12:41 am

What about cost & licensing?

Comment by:

Shimon Amit

23 | November 21st, 2007 at 8:03 am

thanks for the GREAT post! Very useful…

Comment by:

Whatever-ishere

24 | November 25th, 2007 at 2:01 pm

[...] TraduÃ§Ã£o permitida por Brian Reindel [...]

Comment by:

Tyasske » Frameworks Javascript - Usar ou nÃ£o? (parte 2)

25 | December 6th, 2007 at 4:11 pm

Brian,

thanks for your post. It would have been more useful if you had actually provided the data for a number of the frameworks against your evaluation criteria to provide a starting point for user evaluation.

regards

Comment by:

Malcolm

26 | December 6th, 2007 at 7:33 pm

[...] December 7, 2007 in Software I came across this article and it seemed to me that these are great guidelines for selection of open-source (and perhaps commercial) software frameworks and packages. I adapted these a bit to fit more of what I think is important: Project Requirements: should drive the evaluation/selection. The amount of functionality provided out of the box and of experience needed to support the framework/solution should be considered as well. [...]

Comment by:

Rules for Selecting Open-Source « Tarn Aeluin

27 | December 10th, 2007 at 5:39 pm

[...] 456 Berea St expands on Brian Rendel’s original article about how to choose a Javascript framework. [...]

Comment by:

Make It Up As You Go » Blog Archive » How To Choose A Javascript Framework

28 | December 13th, 2007 at 4:01 am

[...] Hangi javascript kÃ¼tÃ¼phanesini kullanmalÄ±yÄ±m? BaÄŸlantÄ± [...]

Comment by:

Fatih HayrioÄŸlu’nun not defteri » 13 AralÄ±k 2007 Web’den SeÃ§me Haberler

29 | December 13th, 2007 at 7:39 pm

[...] How to choose a JavaScript framework Â» dâ€™bug (tags: javascript-library) [...]

Comment by:

30 | December 14th, 2007 at 11:23 pm

[...] Read: How To Choose A JavaScript framework [...]

Comment by:

a bulletproof idea » Blog Archive » Look What My RSS Dragged In #2

31 | January 12th, 2008 at 10:52 am

[...] A primeira informaÃ§Ã£o que consegui foi uma lista de requisitos rica (http://blog.reindel.com/2007/10/30/how-to-choose-a-javascript-framework/) ,Â que com certeza contribuiu para a escolha. [...]

Comment by:

Frameworks Javascript « Vinicius CÃ¢mara

32 | February 27th, 2008 at 10:46 pm

[...] d’bug » How to choose a JavaScript framework [...]

Comment by:

Tagging the Web Daily 02/28/2008 « PAB Skunkworks Weblog

33 | April 27th, 2008 at 2:18 am

[...] How to choose a JavaScript framework [...]

Comment by:

40 Excellent Resources for JavaScript Coders - A Great Place for News, Articles & Free Web Resources

34 | April 28th, 2008 at 6:00 pm

[...] How to choose a JavaScript framework [...]