Ajax Framework Analysis Results
Way back in January, I wrote about how my colleagues and I were evaluating Ajax frameworks to build a SOFEA-style architecture. To make our choice, we used the following process:
- 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 and recommendation.
When I wrote that entry, we had just finished step 2 and were starting step 3. I first wrote this blog post a week later, when we delivered step 5. Here is the comparison and conclusion sections of the analysis document we composed.
In order to evaluate the different frameworks against important criteria, we created a matrix with weights and ranks for each framework. This matrix shows how our weighting and rankings lead us to the winner for our project. You can view this matrix online or see below for a summary.
Note: Criteria whose values were identical across all candidates were weighted at zero. Charting capability was weighted at zero b/c we decided to use Flash for this.
This matrix indicates that GWT is the best candidate for our team to develop SOFEA-style applications with. In addition to the matrix, below are graphs that illustrate interesting (and possibly meaningless) statistics about each project.
After working with the various frameworks, we believe that all the frameworks were very good and could be used to write applications with. If all weights are equal, these frameworks were almost even when compared against our evaluation criteria. The graph below illustrates this.
Even after applying the weighted criteria, the evenness doesn't change a whole lot.
Based on this evaluation, we believe that GWT is the best framework for our team to develop SOFEA-style applications with.
Flash Forward to Today...
The core GWT library from Google doesn't have a whole lot of widgets, nor do they look good out-of-the-box. So early on, we experimented with two alternative implementations that continue to leverage GWT concepts and tools:
Because of these findings, we are proceeding with the core GWT library from Google and adding in new components as needed. It is cool to know you can make a UI "pop" with GWT, as long as you stick to the core - close-to-the-metal - components. For those applications that can afford an initial "loading..." state, I'd definitely recommend looking at GXT and SmartGWT.
* To make refactoring easier, I copied GXT MVC into our source tree and modified all imports.
Posted by Martin Wildam on April 24, 2009 at 01:33 AM MDT #
Posted by Keith Donald on April 24, 2009 at 06:53 AM MDT #
Posted by Tiho Lupak on April 24, 2009 at 08:09 AM MDT #
@Tiho - the first commenter on my original post asked about jQuery. Here's what I wrote then:
That being said, I believe that GWT was a better fit for our project because it allowed us to do a lot of refactoring, modularizing and optimizing.
In the end, it turns out widgets weren't as important as we originally thought. Now we're more concerned with speed and a library with more widgets tends to be fatter and therefore slower to initially "pop".
Posted by Matt Raible on April 24, 2009 at 08:47 AM MDT #
I haven't used the others but GWT is a hit in my book. I have refactored a lot but just paying attention to statics and writing solid Java code is cake. I think that there is a lot to learn as the application grows. I told a friend yesterday that in Oklahoma I worked with 9 others on a 4.7 million dollar JSF application and my GWT app will surpass it's codebase in size before the project is complete. And, I'm rolling on the code all by myself. It's no-nonsense AJAX creation. I fully agree with your findings.
Posted by David Whitehurst on April 24, 2009 at 09:20 AM MDT #
Posted by Tom on April 24, 2009 at 09:51 AM MDT #
Posted by Tom on April 24, 2009 at 09:57 AM MDT #
Posted by Les Stroud on April 24, 2009 at 01:20 PM MDT #
Posted by Matt Raible on April 24, 2009 at 01:35 PM MDT #
I think it is a fair comparison, though highly weighted towards your specific application at a moment in time. I am not sure it would change anything, but when you measure "productivity" you are measuring from when you completed the prototype.. but are you as proficient as you could be? When you weight 'change for the Java team' that is fine if you are a real crunch time cycle, but is that the best long term answer? I have teams who are choosing Struts 1.3 because that is the quickest starting point... does that sound like the best idea?
I am totally not busting on the effort, I think these are critical and useful to share and need to be put with a big asterisk, as you have stated many times in your presentations on Java frameworks... 8)
Thanks for the post though.
Posted by Tony Lowe on April 24, 2009 at 02:04 PM MDT #
I'm a Java programmer and that's why I love GWT. It's very object oriented and you do have to think about things some, but it's also very much like other UI libraries so it's comfortable and not daunting.
I haven't had a lot of downtime debugging either. Things have been pretty smooth.
Posted by David Whitehurst on April 24, 2009 at 02:16 PM MDT #
Posted by David Whitehurst on April 24, 2009 at 02:23 PM MDT #
Posted by Les Stroud on April 24, 2009 at 02:32 PM MDT #
I searched for GUI design support for GWT under NetBeans but it seems, there is nothing around so far, isn't it?
This is bad, because I know from my about 26 years of experience in software development, that without a WYSIWYG GUI designer about 80 % of the work flows into GUI development. This might not be true if I would be more familiar with the one or other type of layout in Java, but I simply don't want to bother with that.
I was happy seeing visual GUI design support when doing JSF, is there any helpful thing when using GWT? And I also wonder, if JSF could be combined with GWT for just the RESTFUL background loads of data - but not sure.
Posted by Martin Wildam on April 24, 2009 at 03:20 PM MDT #
As you have noted, GWT is great in protecting you from the complexities of the actual client-server app you are generating. Also, you've noted that whenever you venture outside the provided box you are not only exposed to the client-server complexity but also to the complexity of the system that tries to hide the former complexity.
All because you don't want to code true clients. In my experience, if you take the first complexity up front and learn it (using Ext or Dojo (which as you would know from trying them out extensively, differ from jQuery and others in having a good MVC model)), you will separate client and server nicely and know what you are doing and not pay any taxes when introducing new functionality (that's not in the shipped package).
What you're saying is that you don't have any skilled front-end developers in your team. Take someone who is a really good coder and make that person responsible for doing *all* of the UI and use only REST to communicate with the (now less UI encumbered server-side guys)
No, you won't get 100% browser penetration. Maybe someone will turn off CSS :) But hey, maybe your app gets a 30% share of the Internet's total customers. That's something, isn't it?
And you might actually implement more features before burning all of the capital.
Posted by Peter Svensson on April 24, 2009 at 03:46 PM MDT #
Posted by Cagatay Civici on April 24, 2009 at 05:25 PM MDT #
Matt, how many developers participated in this analysis?
Posted by Yuval Goldstein on April 27, 2009 at 04:26 AM MDT #
Posted by Matt Raible on April 27, 2009 at 09:36 AM MDT #
Posted by pascal on April 28, 2009 at 07:11 AM MDT #
Fascinating write up!
One note regarding GWT + Dojo is that there's an integration project called Tatami which might re-weight some of that outcome if you're into GWT. Also, a minor quibble w/ the charts: they should all start at 0. Particularly the last two, else they're no good for understanding the actual relative weights of the values.
Posted by Alex Russell on April 28, 2009 at 03:34 PM MDT #
Posted by tieTYT on April 28, 2009 at 05:58 PM MDT #
Good analysis, but it's a pity you didn't include server-side ajax solutions, ex. ZK, Echo2, IceFaces, RichFaces. They are popular java ajax frameworks.
Posted by rcheng on April 28, 2009 at 06:58 PM MDT #
@Alex: I agree with you that charts could be better. Anyone know how to show the full range with Google Spreadsheets? If not, I can redo them with some other software.
@rcheng: We weren't interested in server-side frameworks for this project. In general, a SOFEA architecture only uses a server-side framework for serving up XML or JSON. We're using Grails on the server-side.
The nice thing about this architecture is we're not tied to our UI framework. We could easily change to Flex (or another UI framework that does REST) and not have to change our backend.
Posted by Matt Raible on April 28, 2009 at 07:11 PM MDT #
its a nice comparison, thanks for the post matt.
i understand that this is done for your team but is looked at the stats without this line:
"Match to existing Java team skill-set and preferences 0 0.5 1 0"
because this is team dependand. if you (the reader) has a different team which has dojo knowledge these will be 1, 0.5, 0 and 0.
because the outcome is almost a tie i conclude the teams skill-set and preferences are the tie braker.
unweighted without team skill-set and preferences: 17, 15.5, 16, 17
weighted without team skill-set and preferences: 70, 65, 65, 72.5
Posted by tibi on April 29, 2009 at 01:50 AM MDT #
Posted by Larry Maccherone on April 29, 2009 at 05:58 AM MDT #
+1 for Peter Svensson.
You're going for a SOFEA architecture but then avoiding coding in the client? Code static html/JS clients (with mvc in the browser) and make separate soap data calls and you get true separation of client & server. Having coded this way for a long time (doing both the client and server) I worked on one project with gwt-ext and my productivity bottomed out. All the server round tripping to just tweak a UI layout and prototype my UI just drove me nuts.
Posted by Simon Gilligan on April 29, 2009 at 06:49 AM MDT #
1. Take someone who is a really good coder and make that person responsible for doing *all* of the UI and use only REST to communicate with the (now less UI encumbered server-side guys)
2. You're going for a SOFEA architecture but then avoiding coding in the client?
I believe we've done #1 by only using REST and having a couple guys that are really strong coders (both from a Java and JS perspective). Personally, I've found that GWT doesn't eliminate the need to know JS. However, it seems I'm strong enough in both to help other team members.
For #2, I don't see how we've avoided coding in the client by using GWT. Originally, I was an advocate for both Ext JS and jQuery, but I don't think the whole team would've been as productive with these and I'm happy I'm not the guy who had to write everything. ;-)
Posted by Matt Raible on April 29, 2009 at 08:06 AM MDT #
+2 for Peter Svensson.
I would just add that in one hand you talk about execution speed and on the other hand you don't want to know anything about the code running in the client?
I don't catch the trick here. I guess that the only way to optimize what you are doing in your browser is to get your hands dirty by putting them in the engine :).
Moreover I think the in-browser optimization aspect is very important when you consider that a web browser is a very closed and limited environment to run an application.
For my own opinion, provided you stick with a rather simple application it is not a concern, but when you reach a fairly honest point of complexity you have no choice.
Posted by lou_tribal on April 29, 2009 at 02:30 PM MDT #
Not interested in serverside, but you include gwt in your list and grails which are at least as complex as a serverside framework like icefaces.
My experience with gwt is its nice for small apps but as you scale up you lose performance. I was one of our possibilities more than a year ago when we decided on icefaces.
We are happy with our decision, besides a nice set of components icefaces also has a very complete api for building your own components.
On the link to this page, someone commented they using any of these sets you menitioned is better than rolling a page grid (whatever that is) by hand.
With icefaces I could easily do that in half a day. On my spare time, god I have no life, we have an ipen source project were we've done a lot of integration with icefaces.
Posted by michelle on April 29, 2009 at 03:31 PM MDT #
Posted by Patrick Keenan on April 29, 2009 at 03:48 PM MDT #
The Beta release of Ext JS address some of the areas of poor or no rating. Items such as extensibility is poorly rated when Ext is one of the most extensible frameworks I have seen. They also will have charting in the next version, currently in beta.
Since it is a beta, I won't scoff too much. :P
Also, since Ext is flexible enough to run on top of other frameworks (jQuery, YUI, etc), it garners bonus points from me as it opens up a whole secondary set of widgets if the need arises.
Posted by Casey Neehouse on April 29, 2009 at 04:25 PM MDT #
Posted by Lance Chen on April 29, 2009 at 07:22 PM MDT #
Your joking right...
Posted by michelle on April 29, 2009 at 09:45 PM MDT #
Posted by Simon Gilligan on April 29, 2009 at 09:57 PM MDT #
but therein lies your problem ..
Posted by michelle on April 30, 2009 at 05:18 AM MDT #
Posted by Simon Gilligan on April 30, 2009 at 07:49 AM MDT #
Posted by ???? on May 01, 2009 at 08:36 AM MDT #
Posted by Nandatte!? on May 02, 2009 at 06:59 PM MDT #
Hey Matt. Why did you just give 0.5 to Dojo for it's widgets? In my opinion Dojo has the most Widgets and they are mostly marued of al of the JS Frameworks, if you also take a look at Dijit and DojoX.
thx for that nice comparison
Posted by Andre Bock on May 03, 2009 at 03:23 AM MDT #
Thanks Matt, very useful.
I was wondering to what extent your prototype application had to manipulate user-generated data structures on the client?
Some time ago (>3 years) I was looking for an ajax framework that would allow users to manipulate complex user generated structures (eg directory trees) whilst automatically imposing permissions and type checking (and sharing all of these control aspects transparently with the server). Since I couldn't find one I wrote my own (lmframework).
Do you know if any of the frameworks you tested have made any progress in this direction?
Posted by David on May 03, 2009 at 04:13 PM MDT #
Posted by Yuval Goldstein on May 17, 2009 at 07:46 AM MDT #
However, GWT is much better. It gives you enough AJAX to make a real interactive application. With RichFaces and IceFaces you always plunge into full page refreshes from time to time. However, with GWT your app. is truly rich.
With GWT your app. is really light on the server. All the action is within the browser. So your serverside is not holding the tree of components as in JSF. The server side is super scalable. You can go from several hundreds to million hits and just have to scale up your DB and business tier ( which is just some simple Apache AJP config.)
No JSF life cycle bulshit. No JS debugging. No browser quirks (99% of the time). Thank GOD.
The classic UI design patterns (Component/Container) + all the OOP + design patterns + strict typing and code manageability are a reality.
Bindings with Maps, Video, AJAX Search and endless amount of open source controls give you the strength to build fantastic applications. Google Wave is the proof. So are several other high profile apps like http://www.contactoffice.com
Blend it with hibernate4gwt and GWT Server Library (GWT-SL) and I wonder if any other framework can beat it in terms of clean design and less amount of compact code.
Posted by Vinay Soni on May 31, 2009 at 09:10 PM MDT #
Posted by michelle on June 01, 2009 at 05:22 AM MDT #
With RichFaces and IceFaces you always plunge into full page refreshes from time to time. However, with GWT your app. is truly rich. I don't seem to have issues with partial page refreshes when using icefaces, I haven't used gwt since its first release, but I don't think it has the comet-d support icefaces does. I'm particularly interested in technologies that integrate weill with the Iphone and icefaces fits that bill very nicely. The server Push lets me use a servlet as a data pump, pushing data which forces updates to the user page. I don't think I could do that with gwt. At least I have never seen an object-c / gwt integration.
Posted by afolayan on June 10, 2009 at 06:06 AM MDT #
Posted by michelle on June 10, 2009 at 07:02 AM MDT #
Posted by afolayan on June 10, 2009 at 07:46 AM MDT #
Posted by michelle on June 10, 2009 at 07:56 AM MDT #
Posted by Vinay Soni on June 10, 2009 at 07:29 PM MDT #
Posted by michelle on June 11, 2009 at 04:48 AM MDT #
As Vinay soni said you can have all the goodies of OO (OOP, Design Patterns etc...)
This implies in one aspect that was not accounted by Matt. Unit test.
In developing using GWT you can use the patterns to improve the testability. For example, MVP (model view presenter). The view resumes to a minimal collection of widgets and you can create unit tests to the presenter class.
And even in cases when you have to use the real view to do the test (for example, if there is no problem in loading the view), there is the GWTTestCase. The problem in using GWTTestCase and use the real view is that the tests become too slow. So it is not a true unit test.
As I am a big fan of TDD, testability (and refactoring(and maintainability)) is much important to me and my experience with GWT was very good.
Sorry any mistake in my English
Posted by Josue on August 10, 2009 at 08:41 AM MDT #
Posted by 220.127.116.11 on August 30, 2009 at 03:52 AM MDT #
Posted by laker2000 on October 13, 2009 at 08:07 PM MDT #
Posted by Ray K on September 20, 2011 at 04:17 PM MDT #