Matt RaibleMatt Raible is a Web Developer and Java Champion. Connect with him on LinkedIn.

The Angular Mini-Book The Angular Mini-Book is a guide to getting started with Angular. You'll learn how to develop a bare-bones application, test it, and deploy it. Then you'll move on to adding Bootstrap, Angular Material, continuous integration, and authentication.

Spring Boot is a popular framework for building REST APIs. You'll learn how to integrate Angular with Spring Boot and use security best practices like HTTPS and a content security policy.

For book updates, follow @angular_book on Twitter.

The JHipster Mini-Book The JHipster Mini-Book is a guide to getting started with hip technologies today: Angular, Bootstrap, and Spring Boot. All of these frameworks are wrapped up in an easy-to-use project called JHipster.

This book shows you how to build an app with JHipster, and guides you through the plethora of tools, techniques and options you can use. Furthermore, it explains the UI and API building blocks so you understand the underpinnings of your great application.

For book updates, follow @jhipster-book on Twitter.


Over 10 years ago, I wrote my first blog post. Since then, I've authored books, had kids, traveled the world, found Trish and blogged about it all.

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.

  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 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:


Ajax Framework Candidates
(intro and explanation)

  Project Information
  (license / cost)
  (number of committers)
  (support options)
  (mailing list traffic (nov/dec 2008))

Matrix and Notes


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.

Posted in Java at Jan 08 2009, 09:36:22 PM MST 39 Comments

I, actually, feel that jQuery is really good in UI widgets with it's

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 09, 2009 at 04:42 AM 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 09, 2009 at 04:54 AM 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 08:03 AM MST #

no Smartclient/SmartGWT ?

Posted by Claudio on January 09, 2009 at 08: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 09: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 09: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 01:07 PM MST #

@Claudio - Yes, as part of GWT, we are looking at SmartGWT and Ext GWT.

Posted by Matt Raible on January 09, 2009 at 02:12 PM 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 ( 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 02:34 PM MST #

Hi Matt. Wondering if you've considered ZK. If I were to build an app with heavy JS front end as a requirement It would be on my list. To me its like GWT, only better because it supports templating via xul like xml. Has 100's of ajax widgets, but can code in pure java. --James

Posted by James Law on January 09, 2009 at 04:14 PM 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?



vs YUI:

YAHOO.util.Dom.getElementsByClassName('test', 'div'); 

Posted by Ikai Lan on January 09, 2009 at 07:00 PM MST #

As another poster said, consider SmartClient / SmartGWT.


- 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


- Ugly look and feel (they are working in a new one: 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 07:45 PM MST #

Ikai, you can use the YUI Selector utility and an alias to achieve jQuery-like nirvana in YUI:
var $ = YAHOO.util.Selector.query;
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 09:46 PM MST #

I think one of the best AJAX Frameworks I have seen:

Posted by Mahesh Chalil on January 10, 2009 at 08:07 AM MST #

Other important AJAX frameworks are TIBCO General Interface and OpenLaszlo.

Posted by Jim White on January 10, 2009 at 09: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 10:29 AM MST #

I think one criteria for an evaluation should be "javascript only yes/no". YUI is one of the few frameworks out there which allows you to "decorate" existing html using javascript and css to become widgets. In cases where search engine optimizations is crucial, a.k.a. a public website, this can be crucial. E.g. ext js if I recall correctly is completely javascript driven. So, a spider will never be able to negotiate the menu structure and get stuck on page 1, unless you implement all sorts of hoopla to work around this.

Posted by Marc on January 11, 2009 at 11:22 AM MST #

why are you limiting yourself to using just one frameworks , size considerations ? we just jquery for its consiseness , plugin architecture and plain ease of use and YUI for widgets . why not take the best of each library ?

Posted by surya on January 12, 2009 at 04:07 AM 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 06:54 AM MST #

@ ex-ExtJs guys: check http:/

Posted by Claudio on January 12, 2009 at 08:25 AM MST #

@surya - you bring up an excellent point. We're certainly considering jQuery for ease of use + a widget framework.

Posted by Matt Raible on January 12, 2009 at 10: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 11:36 AM MST #

Ah - sorry for that! I obviously had to read a bit more about SOFEA. Now things make much more sense to me (see my comment above). I also think Struts2 is a pretty safe choice in the MVC area.

Posted by Fabricio on January 13, 2009 at 11:52 AM MST #


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 06: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 14, 2009 at 03:26 AM MST #

Another vote for jQuery (for your own coding) + other widget libraries (for widgets). The jQuery programming style makes Javascript a pleasure to develop in, and the library itself is slim, fast, and non-polluting.

Posted by Ray Davis on January 14, 2009 at 08:22 PM MST #

btw i also see Sofea architecture as the real way to do things now. It is ria without the selling, clver lightweight components. I will write something about it but in french(sorry)

Posted by gabriel K. on January 15, 2009 at 06: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.



PD: sorry my poor english

Posted by migue on January 15, 2009 at 10: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 01:02 PM MST #

In this post and comments all the talk is about the javascript. How about backend frameworks for ajax? I'm in a project that has a full fledged ejb3 backend with an old webwork 1.x frontend that needs to be brushed up (scrapped). How do you guys make your backend available for ajax calls that return json or xml?

Posted by Trond G. Ziarkowski on January 20, 2009 at 11:44 AM MST #


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 12:31 PM 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 12:35 PM MST #

For the sake of completeness: Wave Maker is an easy-to-use visual builder that enables the drag & drop assembly of scalable, web-applications using Ajax widgets, web services and databases. WaveMaker Studio will look and feel especially familiar to client/server developers who are used to working with visual tools. Very similar to Tibco GI.

Posted by Bruno on January 23, 2009 at 02:14 PM 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:

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 10:45 PM MST #

Posted by DZone on January 27, 2009 at 09: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:

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 10:14 PM MDT #

Any opinion on DHTMLX ... seems to have a lot of features and easy on developers.

Posted by Venu on May 10, 2009 at 03:24 AM 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 02, 2009 at 12:33 AM MST #

Post a Comment:
  • HTML Syntax: Allowed