A first look at JavaScript Frameworks 6

In our discussion today about Javascript frameworks we finally came to a conclusion, of sort, regarding when to use frameworks.

In back office applications we can use whatever framework we want. It is used by a small number of people and we have total control over possible dependencies and namespace collisions, so we do not have to worry about breaking other people’s stuff.

When we create code that is going to be included on another web page it is a completely different story. In those cases our goal will be to create code that does not require a framework, so we avoid polluting the requiring site with our dependencies. It might not always be possible to achieve this, but it is a noble goal at least.

We have been using Prototype for most of our work so far. On smaller projects we have started to dabble a bit in JQuery and YUI. The next time we do any major JavaScript development we will explore the options they give us.

The major reasons for moving away from Prototype is the huge size of the library, and numerous changes it makes to basic JavaScript objects. A lot of the changes are good and make for easier code development, but they don’t really feel like proper JavaScript. Instead they rely too much on magical functions and the forced object oriented coding style that Prototype enforces.

We also find that Prototype (and Scriptaculous) are lacking in regards to their option for “plugins”, like calendar- or graph-plugins. Either Scriptaculous have a solution built in, or there are very few good alternatives. Both JQuery and YUI seem to have better communities surrounding them that develop better, and more, plugins that might suit our needs.

The little experience we have with JQuery so far indicates that it is very DOM-centred. This is both a boon and a bane; we loose some of the power we might have gotten used to in Prototype, but it might help us creating purer JavaScript for code in the areas that do not touch on the DOM. This is a goal we have since we want to make all of our JavaScript code testable, and it is much easier to test code that only manipulate data and do not touch the DOM.

Another option in regards to plugins that we are going to look into is ExtJS. The GUI elements that they offer seem to be very powerful, and using pre-built items would save us a lot of time. The pitfall that we saw was that overuse of the items they supply might make the application look too much like a desktop application. Since we are developing for the web we should be careful to not draw too much inspiration from the desktop, they are different media and require different solutions.

6 thoughts on “A first look at JavaScript Frameworks

  1. Pingback: Enterprise JavaScript Coding » select *

  2. Reply Audun Ytterdal Mar 2,2010 6:40 pm

    espenh at gomobile will be angry for weeks if you don't include mootools in your comparison :-)

    • Reply Michael Mar 5,2010 8:54 am

      None of us have any experience in Mootools, and since our time is limited we felt it better to spend it getting to know jQuery and YUI too see what they have to offer.

      If we find them lacking Mootools is definitely on the list.

  3. Reply Soeren Apr 22,2010 9:21 pm

    I would probably stay away from ext.js. They have apparently lost their lead developer (the genius Jack Slocum) and people are starting to complain about numerous bugs.

    More interesting discussion here:

    http://ajaxian.com/archives/ext-js-3-2-beta-stores-components-transitions-and-themes#comments

  4. Reply Hope Dec 25,2013 11:45 am

    It’s remarkable to visit this web page and reading the views of all friends about this piece of
    writing, while I am also zealous of getting experience.

Leave a Reply