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.
Framework Comparison
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.
Conclusion
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.
Without considering the even or weighted criteria, we believe the decision all comes down to what the developers on the project feel they will be most comfortable with. If you're developing with Dojo or YUI, chances are you're dressing up existing HTML and possibly using progressive enhancement to add more rich functionality. On the other hand, Ext JS and GWT are similar to Swing programming where you build the UI with code (JavaScript for Ext JS, Java for GWT).
The tools available for JavaScript development have gotten increasingly better in recent years. IntelliJ IDEA has a JavaScript Editor that provides many of the same features as its Java editor. Aptana Studio also has excellent support for authoring and debugging JavaScript. However, we believe the Java debugging and authoring support in IDEs is much better. Furthermore, we are more familiar with organizing code in Java projects and feel more comfortable in this development environment.
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:
Unfortunately, over the past few months, we've found that both of these implementations are too heavy for our requirements, mostly because of the file size of the generated JavaScript code. For example, a feature I wrote generated a 275K *.cache.html file using GXT. After determining that was too slow to give users the initial "pop", I re-wrote it without GXT. After a day, we had an application with *.cache.html files of 133K. Yes, that's over a 50% reduction in size!*
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:
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.
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 #
Matt:
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.
David
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)
I am interested to see where we go in the next few years, since I have been working recently on 100% Ajax solutions with no Java MVC (unless you count DWR) and loving it. I just have a hard time with GWT, as it seems like I am coding at a distance from things, why not just jump into the JavaScript and start drowning?
Thanks for the post though.
Posted by Tony Lowe on April 24, 2009 at 02:04 PM MDT #
Tony:
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.
If you were to ask me if I care about all the callbacks, etc. in Javascript and how it all really works, my answer would be that I don't care really as long as it works. I do think that one needs to remember that after compilation it's not bytecode running in a JVM. That's probably the most important thing. Classes aren't being instanced in real-time and as you're writing this code, just remember that it's producing javascript that I really don't care about as long as it works. The early binding methods that pop-up in an IDE are very easily understood if you've written code for other UI projects and API's.
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.
Cheers,
PS
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?
Thanks.
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.
Regards
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 #
Matt,
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.
http://www.mooncatventures.com/blogs
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 #
Writing native javascript is best. Hire a Javascript expert won't cost you too much. Since complex front-end is an important part of your application, why not hire an front-end technology expert.
I see no reason to use GWT. Good javascript based framework like Ext, dojo or jQuery are good for making new widget. Any java programmer can get familiar with javascript in couple days. After understanding the javascript, you will love the flexibility and power of javascript.
Posted by Lance Chen on April 29, 2009 at 07:22 PM MDT #
Your joking right...
Javascript presents all kind of code maintenance issues, true libraries such as prototype provide some kind of organization, but debugging javascript can be a pain. I spent a whole weekend tracing a bug in a java framework that was in one of the javascript components. normal debugging methods don't work very well with javascript.
Also javascript can be very unsecure. I've been a java programmer for a long time , I've done it both ways javascript with the aid of dwr and component frameworks, eg. icefaces. And I firmly believe the the serverside frameworks are the better solutions. The exception being if your not using java but a scripting language such as php than you're forced to use javascript.
We've done stuff with icefaces and other component libraries in a few hours that would of taken us weeks coding it in javascript.
www.mooncatventures.com/blogs
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 ..
I don't see the problem, I've been a developer for some time. And In my experience the more javascript you need to maintain the more nightmeres you have.
Its a lot easier for code reviews to review java code than javascript, and a lot easier to write internal standards. When we had a lot of javascript before moving to frameworks, we had a tough time coming up with standards for new developers.
Last night I completed another component, it wasn't a big effort , just a wrapper around the yui image carousel. But using the component library gave me instant access to all the ajax capabilities of the format. So I only needed to code a minimal amount of javascript and all the data source stuff is managed again via the component suite. Yet every option for the carousel, there are a lot are available via simple binding from the java backing bean , javascript or the jsf page.
I just don't see this kind of flexibility with javascript.
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?
Thanks
David
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.
Then you should checkout GWTEventService framework for GWT . I used it( GWT+GWTEventService+Struts 2+JPA+Spring) and when my friends saw what've done with these guys, they dropped their jaws, went back and deleted the working chat application they had written in javascript! (started from scratch with GWT and making me their reference guide all the time!). Aside having ajax at my beck and call, i am confident of maintenance (very crucial in even the smallest application-"Hello World!!")
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 218.186.12.237 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 #