Matt Raible has been building web applications for most of his adult life. He started tinkering with the web before Netscape 1.0 was even released. For the last 16 years, Matt has helped companies adopt open source technologies (Spring, Hibernate, Apache, Struts, Tapestry, Grails) and use them effectively. Matt has been a speaker at many conferences worldwide, including Devoxx, Jfokus, ÜberConf, No Fluff Just Stuff, and a host of others. Matt is a DZone MVB and is not an employee of DZone and has posted 148 posts at DZone. You can read more from them at their website. View Full User Profile

Choosing An Ajax Framework

01.09.2009
| 10859 views |
  • submit to reddit

This past week, my colleagues and I have been researching Ajax Frameworks. We're working on a project that's following SOFEA-style architecture principles and we want the best framework for our needs. I'm writing this post to see 1) if you, the community, agree with our selection process and 2) to learn about your experiences with the frameworks we're evaluating. Below is the process we're following to make our choice.

  1. Choose a short list of frameworks to prototype with.
  2. Create an application prototype with each framework.
  3. Document findings and create a matrix with important criteria.
  4. Create presentation to summarize document.
  5. Deliver document, presentation (with demos) and recommendation.

For #1, we chose Ext JSDojoYUI and GWT because we feel these Ajax libraries offer the most UI widgets. We also considered Prototype/Scriptaculous, jQuery and MooTools, but decided against them because of their lack of UI widgets.

For #2, we time-boxed ourselves to 3 days of development. In addition to basic functionality, we added several features (i.e. edit in place, drag and drop, calendar widgets, transitions, charts, grid) that might be used in the production application. We all were able to complete most of the functionality of the application. Of course, there's still some code cleanup as well as styling to make each app look good for the demo. The nice thing about doing this is we're able to look at each others code and see how the same thing is done in each framework. None of us are experts in any of the frameworks, so it's possible we could do things better. However, I think it's good we all started somewhat green because it shows what's possible for someone relatively new to the frameworks.

For #3, we're creating a document with the following outline:

Introduction
Ajax Framework Candidates
(intro and explanation)
Project Information
(history)
(license / cost)
(number of committers)
(support options)
(mailing list traffic (nov/dec 2008))
Matrix and Notes
Conclusion  

For the Matrix referenced in the outline above, we're using a table with weights and ranks:

WeightCriteriaDojoYUIGWTExt JSNotes
#Important Criteria for Customer0..10..10..10..1Notes about rankings

Our strategy for filling in this matrix:

  • Customer adjusts the weight for each criteria (removing/adding as needed) so all weights add up to 1.
  • We rank each framework with 0, .5 or 1 where 0 = doesn't satisfy criteria, .5 = partially satisfies, 1 = satisfies.

The list of criteria provided to us by our client is as follows (in no particular order).

  • Quality of Documentation/Tutorials/Self Help
  • Browser support (most important browsers/versions based on web stats)
  • Testability (esp. Selenium compatibility)
  • Licensing
  • Project health/adoption
  • Performance
  • Scalability
  • Flexibility/extensibility
  • Productivity (app dev, web dev)
  • Richness of widget/component library
  • Charting capability
  • Ability to create new widgets
  • Match to existing Java team skill-set
  • Ease of deployment (on Ops, QA, Users)
  • Degree of risk generally
  • Ability to integrate with existing site (which includes Prototype)
  • Easy to style with CSS
  • Validation (esp. marking form elements invalid)
  • Component Theme-ing/Decoration
  • CDN Availability (i.e. Google's Ajax Libraries API or Ext CDN)

What do you think? How could this process be improved? Of course, if you have framework answers (0, .5 or 1) for our matrix, we'd love to hear your opinions.

References
Published at DZone with permission of Matt Raible, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Frank Mena replied on Fri, 2009/01/09 - 8:25pm

You really should add SmartGWT.  It has a rich widget library built on top of GWT and does not have the offensive license of Ext JS.

 

Otengi Miloskov replied on Fri, 2009/01/09 - 11:59pm

My vote goes to GWT for Java and Dojo for Javascript.

Also a good Ajax framework for Java but is serverside is ZK or OpenLazslo is great because support Ajax or Flash rendering.

JQuery is the best if you just need to intagrate some effects to your MVC web app.

Marcus Bosten replied on Sat, 2009/01/10 - 4:56am

... Apache Wicket is missing on the llist.

It runs on the server - and it has already a lot of (AJAX)components - but more important you simply can create your own (AJAX)components.

You have Wicket Quickstart  wich will setup your project in minutes  and/or tools like wicket RAD where you can generate by using a descriptive approach and/or  others that e.g. generate a runable Eclipse project (based on your hibernate configuration an annotated POJOs ) .

You can use different types of model depeding your needs (eg. use pure inMemory models if you have only a few users OR LoadalbeDetachableModels to work with very less memory usage to serve a lot of users).

You have support for Google Guice and with some smaller adaptions you can use it restfull.

Documentation is mostly up to date ad sufficient. 

 Last but not least -Development with Wicket is fun :-)- no doubt.

 

 

Geertjan Wielenga replied on Sat, 2009/01/10 - 5:55am

Yes, I was also surprised to see Wicket missing from your list.

peter svensson replied on Sat, 2009/01/10 - 6:16am

@192707, @Geertjan: The reason Wicket is not on the list is that the selection process is constrained to pure front-end (i.e. JavaScript) frameworks. Wicket (even though it's a very good one) is a server-side web framework which hides the client-server relationship between browser and service. The basic ideas behind SOFEA is to make this relationship explicit and to put all state of the application on the client/browser (security remaining on the server, nautrally :)

I think the list of criterias is very good, but I would recommend you to have a baseline for terms such as richness, flexibility, risk, et.c.  Perhaps taking an existing mature server-side web framework as an example, to iron out what the points mean in more detail, since most of the team will know it inside out already.

Another tack is to be explicit about that the level of productivity in a certain framework is only relative to the other ones in the list. 

Also, you could set up specific scenarios that is near some of your actual targets, and measure each framework on how they worked in that specific scenario. This will also lead to a reworking of the reading of the criterias, I think. Depending on how I read your article this might very well already be what you are doing, so apologies in that case.

 

Cheers,

PS

Marcus Bosten replied on Sat, 2009/01/10 - 10:28am in response to: peter svensson

@Peter: I read your comment for multiple times  - but even with support I was not able understand what you want to tell us (sorry -no native Speaker available at present).

Can you please say it in a easier manner  for the Part from

" Perhaps taking an existing..."

        up to

"...reading of the criterias, I think.".

Thank you.

By the way: I think the list of criteria is ok.

 

peter svensson replied on Sat, 2009/01/10 - 10:42am

@192709: Sorry, I was too fluffy with my wording :)

 What I meant was that Matt's team could apply the above criterias to another thing that everybody knows well and work with daily. For example the Java Spring  framework, or something else. Then everyone will have decided how fexlibly and how well documented, et.c. that framework is, so that they will have a 'golden standard' when they start compare they front-end frameworks later. Possible they have alrady done this, but I'm not sure.

What I also think will happen then, when applying these criterias 'for real' against Spring (for example) isthat they might feel that they need to change the wording of certain critierias which might be considered too vauge, or too generic.

That way, everyone will know what they are looking for and what they mean when they say that some front-end framework or other is less documented, because they have something to compare to.

 

Cheers,

PS

Stephen Musoke replied on Sat, 2009/01/10 - 11:04am

How about JQuery, its in the same league as Motools, etc. There are numerous plugins not only for AJAX but for simplifying the Javacript functionality, form validation etc

Marcus Bosten replied on Sat, 2009/01/10 - 4:53pm

If for any reason a server side framework is not acceptable (think twice), you might also think about qooxdoo.

@Peter: Thank you for explaining what you mean.

In general a reference that is known by everyone might help - but it is not a siver bullet . 

peter svensson replied on Sat, 2009/01/10 - 5:26pm

@192709: Believe me: I have thought way more than twice about this :)

http://www.youtube.com/watch?v=XMkIZZ7dBng

http://codebits.sapo.pt/intra/s/speaker/10  (Talk is at the bottom of the page)

No, of course, I just tried to give my input on how to optimize the selection process. Please chip in.

 

Cheers,

PS

 

Schalk Neethling replied on Sat, 2009/01/10 - 5:41pm

If you are looking for a front end solution, no need to look any further the jQuery. jQuery will make you so much easier and if you need UI components, look no further then jQuery UI (http://ui.jquery.com/)

peter svensson replied on Sat, 2009/01/10 - 6:09pm

Since one of the questions was also what experiences one has with a given framework, I'll just say that I'm very biased towards Dojo, having used it for years and also being a small-time contributor.

I actually got a variant of this question today on a LinkedIn forum, which I turned into a quick blog post, where I try to outline briefly where Dojo (and to some extent ExtJS) differ from the rest of the crop.

http://unclescript.blogspot.com/2009/01/what-makes-dojo-diferent.html

Cheers,
PS

 

peter svensson replied on Sat, 2009/01/10 - 7:20pm

<removing extranous comment due to dzone borkfest>

Maurizio Turatti replied on Sun, 2009/01/11 - 7:58am

Anyone had alook at JMaki? I have no direct experiences with it yet, but it seems one of the most comprehensive:

https://ajax.dev.java.net/whyusejmaki.html

Jose Maria Arranz replied on Sun, 2009/01/11 - 5:19pm

 I can understand the SOFEA approach if you want to free the server of saving visual state, but some times the main reason is to use the amazing look and feel and "all in the same page behavior" of some client centric frameworks.

 The first reason is fine... if you can deal with tons of JavaScript code and security concerns :)

 The second reason is no longer true because look and feel is basically CSS and HTML and "all in the same page behavior" can be replicated using AJAX with a server-centric solution.

 What if you can easily "steal" your preferred look and feel and DHTML of your client framework with a server-centric one?

 For instance, this is a server centric application based on ItsNat using CSS and generated layout of Ext-JS but no Ext-JS JavaScript code is used:

http://www.innowhere.com:8080/inexperiments

Notes:

- Is basically a clone of this Ext-JS application.

- Is not complete (add/remove an item not done yet). Use double click to edit in place.

- Source code is going to be released soon (don't expect something special, Ext-JS specific is in HTML and CSS form in pure HTML templates).

- It may work in your preferred mobile browser.

- Is using an ItsNat v0.6 pre-release (to be released soon).

 

 

Grzegorz Borkowski replied on Sun, 2009/01/11 - 5:29pm

Matt,

I'm exactly at the same level: we are thinking about starting some SOFEA based project, and we have to make decisions regarding technologies to use. At this moment I'm evaluating EXT-JS, based on the opinion of my friend, who worked for the company where they evaluated EXT, GWT, and GWT-EXT. He says "you write the code more or less the same in each of those three, but any customization is much easier in EXT, so I would go for EXT".

I'm very curious about results of your evaluation. Will you publish it?

Client-side framework is only one decision out of several. For server side, I definitely go for Spring-based Java application (as I'm primary Java developer). However communication between those two must be decided too. Contrary to original SOFEA assumptions, after long discussions and reading we decided to use JSON. But what to use for Java-JSON-JavaScript translation? Automation with DWR? Or manual JSON creation with eg. JSON-Lib, or somehing other?  Go for pure RESTful architecture or not? etc. I would be also happy to hear about your decisions on it.

replied on Mon, 2009/01/12 - 1:38am

Like Peter, I'm very biased but to JavaScriptMVC (and also part of the Thin Server Architecture Group).  If you are building something large and complex, 'ground' floor libraries like jQuery and Prototype will not cut it.  If you need a lot of custom components, or modifying them; you'll have trouble using packaged widgets that you find in libraries like YUI.  Of your current choices, I agree with Peter, use Dojo!  It's got everything you need to make almost anything work cross browser.

Currently I'm working with a few Dojo guys building a complex JS application for T-mobile.  We are using jQuery and JavaScriptMVC.  And although Dojo is fantastic library, if your application is big enough and you are working with enough people, Dojo falls short in a few ways.  

First, you need event delegation.  It's hard to articulate how much easier writing JS applications becomes.  You don't have to worry about attaching event handlers every time you change the DOM.  Your app will likely perform much better too!

Second, you need structure.  If you're working with a large team, you want people building their components in the exact same way.  It's very easy for one JavaScriptMVC developer to work on any other person's code.  You have to write your code in the same way.  

Third, you need tools.  You want to be able to easily test, compress, document, etc.  JavaScriptMVC makes these development pain points dead simple.

 

That being said, JavaScriptMVC is very weak in other areas: Widgets, Theming, etc.  However, when used with libraries with widgets, you get the best of both worlds.

 

Mahan Hooshmand Rad replied on Mon, 2009/01/12 - 8:48am

You mentioned all these frameworks but you forgot the most outstanding one:

 The Pure Java ECHO Framework which is on the verge of its third edition.

it's ease of use and the great collection of components (plus echopoint) is undeniable and unique.

I've been experiencing it for a long time.

It's fantastic from many points of views. 

Frank Ezprint replied on Thu, 2009/01/15 - 12:37pm

Whichever one will do the job efficiently is the best one! :) The time set for development was 3 days ,but I'm curious as to how many days you met on the research of Ajax?  I heard a joke about something like that before and it went something like this.  (Developer Team = "We've settled on a solution for the landing page in question, and we believe we can get this idea up and running in an hour since its been decided that a standard HTML form will suffice."  (Boss replies= "...it took you 2 weeks to come up with that?"

 

 

Rajat Taneja replied on Fri, 2009/01/16 - 5:58am

Being one of the co-authors of SOFEA, I had a keen interest in finding the best fit client side framework for SOFEA. I did a similar exercise a while ago and found that a 'scoring' based selection process created somewhat distorted results.

Here were some additional criteria I used:

State management on the Client

MVC framework on the Client

Web Services support for integration with the services layer.

GWT was poor with respect to UI widgets and the MVC framework needed to be built. XML support exists but a Web Services layer still needs to be built (unless you choose to use the GWT RPC support and create an adapter to the web services layer on the server side)

EXT JS was great with UI widgets but the communication with the server was clunky. EXT JS seems to work best with JSON but converting from JSON to Web Services was not seamless.

Ext GWT (http://extjs.com/products/gxt) merges the best of both worlds. Additionally, it ships with a very elegant MVC framework. The biggest downside was the lack of documentation. Therefore it had a somewhat steep learning curve. 

 

 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.