Thursday, November 1st, 2007

Choosing a JavaScript framework

Category: Framework, JavaScript

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.

Brian targets such areas as browser support, project maturity, documentation, & community and how they can have a profound effect on your choice(s). While a lot of the material will be repetitive to many experienced developers, it’s definitely useful to those that are just now looking at leveraging a framework.

Posted by Rey Bango at 7:00 am
16 Comments

+++--
3.7 rating from 49 votes

16 Comments »

Comments feed TrackBack URI

interesting read, but what I’m really curious to see is an actual comparison. Painfully, I missed John Reisig’s tutorial session at TAE which i am told was a wonderfully balanced analysis of the various toolkits (especially considering his position) … I’d like to see a collection of “hello world” like examples written in each of the toolkits showcasing syntax, basic usage, and common functions. I want to see the difference between dojo’s dojo.hitch() and prototype’s .bind(), and even to know what similar scope-locking methods exist in jQuery and Mootools (and all the others someone will inevitably screw “what about” regarding) … lets actually compare the kits (not competitively, analytically) . Each obviously have their strong points, and their weak points, and their own collection of fanboys (throwing the “community polling” results off) … _that_ information would be valuable to someone wanting to adopt a new toolkit, too. more so than whether or not i agree with the API style, for instance. Good article otherwise.

Comment by dante — November 1, 2007

ha. “screw” instead of “scream” … anyone with uber-editor power can go ahead and clean up after my [seemingly] Freudian slip. thanks :)

Comment by dante — November 1, 2007

I know that my primary reason for choosing Prototype was documentation. The API docs on Prototype are simply awesome. Clean, well organized, and lots of example code.

Comment by Jon Hartmann — November 1, 2007

Hey Dante,

When I was writing the post I did a bit of research on benchmarks, in the hope of uncovering a definitive unit or functional test. There is of course, http://mootools.net/slickspeed/, and similar tools that test the speed of basic selectors, but nothing that provides an easy to read output highlighting the like-minded features of each library. In the end, I decided to pinpoint those “exterior” components of a framework that developers tend to talk about the most. For instance, I love the Mootools modularity approach, and I wish jQuery would take a similar approach. I am still very interested though, and hope someone takes the time to do an independent review of the frameworks currently in widespread use.

Comment by Brian Reindel — November 1, 2007

If you want to compare all frameworks then you must find all the common denominators among them. I’m sure all of the frameworks have an Array.each (or $.each, etc.), for example, so someone can definitely do a comparison of that speed, size, and usability. This requires, however, that someone be familiar with *all* of the frameworks and their internals. I am always skeptical when someone tries to do comparison but this article took the right approach and made it objective rather than a subjective comparison.

Comment by Olmo Maldonado — November 1, 2007

@Olmo – i think that’s the reason there is no current comparison. No one knows the other toolkits (other than their own) well enough to make a good comparison. what about a community effort? a set of clear critera to accomplish, and each toolkit-community make a submission? “Hello World”, “send form via AJAX”, “file upload”, common things … and then include a synopsis of what is being done. What about a series of static HTML pages (like csszengarden) where a toolkit is dynamically loaded on pageload (no cheating, something like php) and a script is launched, and the page goes from “plain html” to “ajaxy” within the scope of some kind of “rules” … Common criteria (and something that all toolkits seem to implemenet): XMHR (ajax), Animations, Events, CSS/Style manipulation, DOM Manipulation, etc. Point out the caveats of each toolkit along the way, and decide for yourself. I’d happily provide hosting for such an experiment. By association I suppose I would classify as a dojo-fanboy, but most of “us” are of the opinion that people should use the tools best suited for the job. Each really does has it’s strong and weak points. I guess I’m just tired of hearing people say “but what about …”

Comment by dante — November 1, 2007

This is exactly what I am trying to do at OpenAjax
If anyone want to help, please contact me there

Comment by Ric — November 1, 2007

The major reason I picked my current framework was because I wanted some nice widgets (grid, combo box…) that I could just run with. So you would at least have to have a “I want widgets” and “I don’t want widgets” comparisons.

Comment by Sam — November 1, 2007

Great article. Even more interesting would be rating each one’s importance in making the decision.

In my experience, and applying the points within the article, I believe MooTools should definitely be AT LEAST in the developer’s initial list of frameworks. Compact, extensible, modular, and fast. Plus the forums and documentation are extremely helpful.

In the end, it’s really more about the developer’s skill level and the website’s needs.

Comment by David Walsh — November 1, 2007

I think an actual comparison of frameworks will be a waste of time, frameworks change to often. Besides that fanboys like you and I are not interested in switching framework. We are to lazy to learn another one. Articles like this are nice for those not allready on a framework.

Comment by Trulli — November 1, 2007

@Trulli: True, but it’s more than just switching. If I can use jQuery as an example, they improved their CSS Selectors by 3 orders of magnitude (perhaps more) thanks to SlickSpeed. Again it shouldn’t be particular to any framework. It should be so everyone and the developers of the frameworks can gauge performance.

Comment by Olmo Maldonado — November 1, 2007

If you don’t mind looking at the source code for documentation, Dojo is unbeatable. It has very little documentation, which scares away many developers. Dojo 0.9 supports Stores and Wires, which are just great. The latter can be used to provide AOP-like services — you can wire a method of one object to that of another, thus achieving something that is not possible (or at least not as simpler) traditionally. It has great set of widgets, the concept of modules and a host of other services. I have used Prototype and Scriptaculous, which are both great, but Dojo surprises me everytime I am looking for a particular service — it is either already there or made it easier to develop.

Comment by Rags — November 1, 2007

Why choose JavaScript frameworks when you don’t have to…?
http://ajaxwidgets.com
JavaScript FREE Ajax for those focusing on results in a .Net or Mono environment…

Comment by Thomas Hansen — November 1, 2007

I took the exact same questions about 3 months ago, and the final head was YUI and Mootools, the team were more likely with Mootools’ API, so it ends up with it. Definitely love it.

Comment by Samori Gorse — November 1, 2007

In terms of SlickSpeed, I agree with Olmo in that these tests helped to improve selector engines across the board as it motivated all of the projects to take a hard look at their selector engine performance. The jQuery project was the first to release this type of test suite followed by the substantially improved SlickSpeed test suite which effectively isolated each library to avoid any leakage or conflicts. Kudos to the Valerio and the Moo team for doing that.

I would also ask that anyone running the SlickSpeed test (or any test suite) to please run them in *ALL* browsers, not just FireFox. Each browser handles things differently and the results do vary substantially.

Comment by Rey Bango — November 2, 2007

Hello All! I like jQuery. I think it’s the best framework because it has good documentation and good speed. When i start use jQuery i told myself hey man why did not you use this framework later? Why did you spend so big time for develop simply js application ;-)

Comment by YouNeedJava — December 7, 2007

Leave a comment

You must be logged in to post a comment.