Choosing an Ajax Framework
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.
- Choose a short list of frameworks to prototype with.
- Create an application prototype with each framework.
- Document findings and create a matrix with important criteria.
- Create presentation to summarize document.
- Deliver document, presentation (with demos) and recommendation.
For #1, we chose Ext JS, Dojo, YUI 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:
| Weight | Criteria | Dojo | YUI | GWT | Ext JS | Notes |
|---|---|---|---|---|---|---|
| # | Important Criteria for Customer | 0..1 | 0..1 | 0..1 | 0..1 | Notes 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.
I, actually, feel that jQuery is really good in UI widgets with it's http://ui.jquery.com/
We chose jQuery instead of Prototype.
Also, we've been playing around SproutCore, which may not be an option for you, but still is a very interesting thing.
Posted by Olexiy Prokhorenko on January 08, 2009 at 10:42 PM MST #
@Olexiy - jQuery was #5 on our list. I definitely think it's one of the best (if not the best) Ajax framework for simplifying JavaScript. However, I don't think their widget library is quite as good as the 4 we chose. That could change though as the project seems to be very active.
Of course, if you've recently switched from one of our 4 to jQuery and jQuery UI, I'd like to hear your story.
Posted by Matt Raible on January 08, 2009 at 10:54 PM MST #
Just a quick note that I'm very interested to see the outcome of this study, as I have been grappling with the exact same question myself for some time now. I would shortlsit those same 4 candidates (although I tend to rule out ExtJS because of the licensing fiasco, despite it's obvious promise) but don't really have any way of distinguishing between them (in practice our development teams tend to use Dojo and YUI equally).
A sidenote, one thing I've found moving from prototype to a richer widget library is that I miss the javascript language extensions that dojo/jquery provide, and if anyone reading this has any insight as to how to get a good combination of these going please share :)
Good luck!
Posted by Casey Butterworth on January 09, 2009 at 02:03 AM MST #
Posted by Claudio on January 09, 2009 at 02:34 AM MST #
We using ExtJs 2.2 since 5 months on a web application. We choosed it because it provides exactly the widgets we were looking for.
Here is few criterias / rank (feedback from the project i'm working on), may this can help :
* Quality of Documentation/Tutorials/Self Help
0.5 -> Very good API doc / Too Many Tutorials (Different implementations for the same thing)
* Browser support (most important browsers/versions based on web stats)
1 -> We are using it on IE6 + IE7 + FF3
* Licensing
0.5 -> Commercial Licence is not a problem (guys need to earn money).
Migration from LGPL (v2.0.2) to Commercial + GPL (2.1+) was brutal !
* Project health/adoption
0.5 -> With new licences, I think community no longer trusts ExtJS Company ...
* Flexibility/extensibility
1 - Very flexible, all client requirements has been easily done. Extensions are now in GPL too ...
* Richness of widget/component library
1 - It's why we choosed it.
* Match to existing Java team skill-set
1 - Working on Swing-based app help me a lot (listeners, Editor, Renderer ...)
* Degree of risk generally
0 - Ext v3(Licence ,Fees ?)
* Ability to integrate with existing site (which includes Prototype)
1 - We using prototype too (webapp based on an old AppFuse 1.9.4)
Posted by Benoit Guérout on January 09, 2009 at 03:25 AM MST #
If you have criterias like Performace/Skalability and so on, I think you should have a look about a more "complete" framework like seam.
With seam you have the choice of your "UI widget library" like GWT, JQuery and so.
We have also made some research in our projects (since 2 years) and using now richfaces and spring. But now we are also at the point to have again a look around, with nearly the same questions for the criterias.
It seams that seam/richfaces is the best choice currently because richfaces has very good UI widgets, nice documentation how to create your own widget based on standard JSF component creation. And if you don't like richfaces you have the choice to simple switch to GWT.
As a side point: Richfaces has also good support for JQuery.
Posted by Thomas Wabner on January 09, 2009 at 03:43 AM MST #
Hi Matt,
I had some experience with Dojo and Ext in the past and I found Ext interfaces more responsive, its documentation more complete, and a more integrated "feel". Having said that, the licensing issue may be a big deal for some. OTOH, Dojo has one of the most active communities right now, and was the first one to support comet.
If you plan to test YUI, you may have to save a couple of hours to separately understand the YUI CSS templates and stencils. For example, we do not use the YUI widgets but have adopted YUI reset. You may reach different conclusions.
Good luck!
Posted by Ignacio Coloma on January 09, 2009 at 07:07 AM MST #
Posted by Matt Raible on January 09, 2009 at 08:12 AM MST #
As always it will be interesting to see the results of your comparison.
I wonder whether quick looks at each technology will overweight usability-out-of-the-box vs. long term good solutions. I've had a lot of experience with GWT (http://code.google.com/p/tocollege-net/) but I don't imagine anyone's first 3 days of GWT would compare well to some of the smaller frameworks. GWT took a while to grow on me and it wasn't until I got into the slick ImageBundle and ResourceBundle stuff or looked at their i18n that I finally dugg what was awesome about it.
That said, if you're not looking for a capital s 'Solution' and know that up front I'm not sure I would spend the time and I'd just add jQuery & lowpro and begin your journey on the path to unobtrusive nirvana. Screw widget libraries.
Posted by Jeff Dwyer on January 09, 2009 at 08:34 AM MST #
Posted by James Law on January 09, 2009 at 10:14 AM MST #
Matt, I thought the title of this post was "choosing an AJAX framework" and not "choosing a widget framework"? =P
I'm a huge fan of jQuery, but for widgets I don't think any library is better than YUI in terms of functionality, flexibility. Too bad YUI is so freakin' bloating and makes code ugly. I mean, really?
jQuery: $('div.test') vs YUI: YAHOO.util.Dom.getElementsByClassName('test', 'div');Posted by Ikai Lan on January 09, 2009 at 01:00 PM MST #
Pluses:
- Widget set at the same level as Ext JS
- Fewer lines of code to get something done
- Excellent support from the company (check out the forums, there are almost no questions without reply)
- LGPL license
- *Excellent* library to access data and to manipulate XML or JSON (including built in REST support)
- Less glitches than with Ext JS: most things work as expected (this is a blessing)
- Sanjiv Jivan, GWT magician and impressive hard worker, is now developing (and already delivering) a great GWT wrapper for it. He is also *very* active in the forums. As far as I can see ExtGWT is dead now.
- Nice showcase (250 components) with code examples
- The spotlight of the GWT widget community seems to be switching from ExtGWT to SmartGWT
Minuses:
- Ugly look and feel (they are working in a new one: http://forums.smartclient.com/showthread.php?t=3060&page=4 but somewhat I still think they need to improve it a bit more)
- Fewer users than ExtJS
- The API has gazillion methods in each final class in the hierarchy.
- The SmartGWT Javadoc is not up to the quality of the code. Many times it's mostly a copy and paste of the SmartClient one. Still, it's certainly enough to develop comfortably.
- Visual effects are somewhat slower than in ExtJS
Posted by Juan Medín on January 09, 2009 at 01:45 PM MST #
var $ = YAHOO.util.Selector.query; $('div.test')We have similar aliases for the most common YUI utilities (YDom = YAHOO.util.Dom, etc) to tighten up our code.Posted by Chris S on January 09, 2009 at 03:46 PM MST #
I think one of the best AJAX Frameworks I have seen:
http://www.itmill.com
Posted by Mahesh Chalil on January 10, 2009 at 02:07 AM MST #
Posted by Jim White on January 10, 2009 at 03:52 PM MST #
Hi Matt, long time i did not comment here!
Once again a very interesting benchmark. I would be interesting in seeing the position of each framework regarding accessibility.
IMHO jquery is first hand choice, even if the widget set is pretty slim compared to Dojo or Ext. Simplicity and the decorator pattern of jquery make it invaluable when you have to deal with accessibility.
Posted by Sylvain Gogel on January 11, 2009 at 04:29 AM MST #
Posted by Marc on January 11, 2009 at 05:22 AM MST #
Posted by surya on January 11, 2009 at 10:07 PM MST #
We had to choose a framework this year. The idea was to wrap ajax extensions in a jsp taglib. we picked ExtJS. Unfortunatly the licence affair appeared just at the same moment... Because of the licence thing, I would not pick Extjs again.
But I miss ExtJS in the open source world, now. It was Sofea made easy. What I really don't like with Dojo it that the demos on the website don't work. For me it is a definitive sign of of insanity. Dojo seems to promise a lot but is not "finished".
Some UI-2.0 guys I worked with, explained to me that the best framework was YUI. No compatibility problem (cross-browser)(it is used for real huge sites...), lots of features , very good documentation etc. (I did not choosed it at the time, because one key feature was missing - the ability to execute some js when loading a fragment, you had either to add a plugin, or to add extjs - so we just took extjs)
Posted by Gabriel K on January 12, 2009 at 12:54 AM MST #
Posted by Claudio on January 12, 2009 at 02:25 AM MST #
Posted by Matt Raible on January 12, 2009 at 04:56 PM MST #
@Matt - I am also working on the architecture of a brand new web 2.0 app.
I think it makes a lot of sense to pair up a Js library/framework with an MVC solution like Spring MVC or Struts2. Is that the what you have in mind as well?
BTW - I have been reading quite a bit about Js libraries and my impression is that jQuery currently has the lead.
Posted by Fabricio on January 13, 2009 at 05:36 AM MST #
Posted by Fabricio on January 13, 2009 at 05:52 AM MST #
Matt
Keep jQuery in the mix. The core library is the best, well documented, most stable, well tested and most active.
As an open ecosystem ui.jQuery is the most active and innovative. The innovation poses some possible risk with stability, but I personally have not had any problems. In the end, the testing, documentation and stability approach the jQuery core.
For AJAX and SOFEA I would also consider Aptana's support of jQuery with its Jaxer server, but I have only played around with it.
And of course as you know Appcelerator comes close to providing SOFEA out of the box, but then I personally do not want AJAX in a box.
SOFEA is the best AJAX paradigm. Your blog me in touch with it.
Finally, you tell the best stories.
Posted by Tom Flaherty on January 13, 2009 at 12:13 PM MST #
Hi Matt,
Take a look at Nexus. Nexus is Sonatypes Maven Repository Manager and it is written using extjs communicating to the backend via REST AJAX calls. Its a very well designed, well performing, and good looking app that adheres to most of the principles I consider SOFEA.
Posted by Darryl Stoflet on January 13, 2009 at 09:26 PM MST #
Posted by Ray Davis on January 14, 2009 at 02:22 PM MST #
Posted by gabriel K. on January 15, 2009 at 12:48 AM MST #
What about Echo2 and Echo3 (Beta) ?
They behave as a UI toolkit (like SWT or similar), and you can write a web application entirely written in Java server code (Echo3 allows client-side with javascript)
This library, combined with a DSL based (based in Groovy), allows us fast and easy web applications development.
Regards,
Migue
PD: sorry my poor english
Posted by migue on January 15, 2009 at 04:04 PM MST #
Hi folks!
In the company I've worked, we did a similar evaluation of visual/ajax frameworks. This spreadsheet shows how we evaluated the frameworks: eGen Visual Frameworks evaluation.
We are trying to work with TIBCO GI, 'cause it presents the most of widget, a good documentation, an excellent sponsor and a good architecture.
Any comment of this evaluation will be appreciate!
Posted by Ricardo do A. Nóbrega on January 19, 2009 at 07:02 AM MST #
Posted by Trond G. Ziarkowski on January 20, 2009 at 05:44 AM MST #
Trond
A solution that works really well for me are REST services with POJO classes annotated with JAX-RS (very simple) and JAXB to annotate domain & DTO clases to marshalize them to xml (forward and back).
The feeling you get is that it's simple, clean and with a smooth learning curve. Also REST services are easily implemented and testable. They provide a very clean layer between your backend system and your RIA client.
Many RIA frameworks have support for XML and JSON so if you choose one that does, it'll save you time.
I really love to develop this way.
Posted by Juan Medín Piñeiro on January 20, 2009 at 06:31 AM MST #
Hello Matt, Just want a comment on your choice of only looking at Ajax Frameworks as a presentation tier for a SOFEA-style architecture. I am looking at what tech to use in the presentation layer of a new SOFEA app but am also considering Flex along with Ajax frameworks mentioned above.
Just would like to understand reasoning for only looking at Ajax libs. Flex is interesting to me as it does fit well into the SOFEA pardigm by keeping the MVC 'stuff' at the client and can make 'simple' web services called to a SOA backend.
Am very very interested in your findings.
Posted by Alan O'Leary on January 20, 2009 at 06:35 AM MST #
Posted by Bruno on January 23, 2009 at 08:14 AM MST #
By the way: "The Google AJAX Libraries API is a CDN (content distribution network) and loading architecture for the most popular, open source JavaScript libraries. By using the google.load() method, your application has high speed, globally available access to a growing list of the most popular, open source JavaScript libraries. "
It includes:
jQuery ;
jQuery UI ;
Prototype ;
script_aculo_us ;
MooTools ;
Dojo ;
SWFObject (New!) ;
Yahoo! User Interface Library (YUI) (New!)
Posted by Bruno on January 23, 2009 at 08:28 AM MST #
For my job, I was recently looking for a javascript UI library myself so I could add a dynamic calendar control to our web pages.
JQuery UI used to have a huge example page showing different ways to use a calendar (I couldn't find it just now in a 2 minute search, it was there 3 months ago). It's great that they put up an example page, but mostly it really demonstrated how their calendar control did *not* work with IE6. Most of the calendars would show up with a giant useless text box that went halfway up the screen (in IE6, but not other browsers) and when the control was set to not let you go the next month (like, the user can only select dates in the past, and you're on the current month) it would sloppily display the word "next" and a broken image icon.
This is the most recent page I found, and it appears to have been significantly changed since when I looked at it 3 months ago, though:
http://ui.jquery.com/demos/datepicker
So we went with yahoo yui, who's examples actually worked in ie6.
Well...I couldn't find a better alternative at the time, but it's not a very productive library.
So you'd like to add a calendar control, right? You've got a text field and a button, and you figure you'll just call a javascript function and *bam* the button will be hooked up to the calendar, and everything will be peachy. Well not with yui. With yui, you'll have to copy and paste about 200 lines of code out of the examples. (When you look through the examples, they look impressive, you don't realize all the code you're looking at is "copy and paste" stuff, not "call a function" stuff).
And then, there aren't even any complete examples. If I wanted to embed a calendar right into the page, that's there. But a pop up calendar? Well - we have one example that pops up, but if you click elsewhere on the page the calendar control stays up there. Oh, and it won't display the date you manually entered into the text field - that's in a different example. Oh, and you want that "display manually entered date into text field" to work with a single text field, not 3 seperate ones (month, day, and year)? You're going to have to shoe-horn in code from another example. I finally got something working after many weeks of working on it by combining the code from a completely different "dialog" example with the example for "show manually entered date". Oh, and then the calendar dialog would only display on the *2nd* click of the button, so I had to put in a hack for that. And that's not even counting the various css hacks I had to add to get it to display right on our site. Of course, now that I waded all through it, I finally am able to add a calendar to a button in a couple of lines because I wrote that functions myself.
So if you're using a lot of widgets, I would highly *not* recommend yui if you want to be productive at all.
Posted by Paul Rivers on January 23, 2009 at 04:45 PM MST #
Posted by DZone on January 27, 2009 at 03:47 PM MST #
Hi Matt,
I've just launched a web site that provides an interactive tool for evaluating Ajax Frameworks. It's the Ajax Decision Center. It uses a decision model that contains over 200 criteria. You can prioritize your criteria, add options, and analyse and compare the options.
Also, here is a direct link to the criteria presented as a single page: http://www.athenz.com/app/decision/criteria/ajax
I hope this is of use and would appreciate any feedback if you decide to try it out.
Posted by Jim Briggs on March 11, 2009 at 04:14 PM MDT #
Posted by Venu on May 09, 2009 at 09:24 PM MDT #
As for SmartGWT, my experience says that when you move slightly off the basic functionality (without leaving the grounds of "still reasonable", not speaking of "hacking" anything) you are very likely to face a bug or an unfinished component/feature. Obviously that means wasted time and energy. :( I would strongly recommend to test it in your spare time before you decide to use it for a project with deadline. On my last project I could have saved half of the time had I chosen the (rather weak) widget library that comes with GWT and write the rest by hand.
I'm sure SmartGWT will keep on evolving and maturing, but currently my opinion is that it looks better than it is.
I just hope Google puts some more effort in their widgets.
Posted by Jarda on December 01, 2009 at 06:33 PM MST #