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.

10+ YEARS


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.

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:

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

Number of Committers

Books on Amazon

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.

Ranking with equal criteria weights

Even after applying the weighted criteria, the evenness doesn't change a whole lot.

Ranking with weighted criteria

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:

  • GXT: a GWT version of Ext JS
  • SmartGWT: a GWT version of SmartClient

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 in Java at Apr 23 2009, 08:34:44 PM MDT 53 Comments
Comments:

Thank you very much for this summary! - As I am overwhelmed by the amount of technologies and frameworks for Web Development, I am really happy for each review comparing them.

Posted by Martin Wildam on April 24, 2009 at 07:33 AM MDT #

Nice summary and comparison Matt!

Posted by Keith Donald on April 24, 2009 at 12:53 PM MDT #

What about jQuery? It looks like it has more plug-ins/components and solutions (for all sort of cases) than all those frameworks tested by you together.

Posted by Tiho Lupak on April 24, 2009 at 02:09 PM 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 02:47 PM 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 03:20 PM MDT #

Not including jQuery in an Ajax comparison is like not including Ubuntu in a desktop Linux comparison.

Posted by Tom on April 24, 2009 at 03:51 PM MDT #

ooops. I didn't see your widget library comment explaining why you didn't include jQuery.

Posted by Tom on April 24, 2009 at 03:57 PM MDT #

Since you evaluated both, did you look at the Ext GWT library?? Personally, I prefer ext straight up. However, if you like the GWT programming model and the ext component library, then it may be a good combination for you.

Posted by Les Stroud on April 24, 2009 at 07:20 PM MDT #

@Les - yep, I just called it GXT. ;-)

Posted by Matt Raible on April 24, 2009 at 07: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 08: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 08:16 PM MDT #

I know, take my pencil from me, but ... GWT is written by Google to keep us out of the Javascript business and ensure that if we do our jobs right as Java developers, their javascript will run on any browser without a hitch.

Posted by David Whitehurst on April 24, 2009 at 08:23 PM MDT #

It would help if I could read. :-) Fortunately my math skills are not as bad or I wouldn't get past the captcha. :)

Posted by Les Stroud on April 24, 2009 at 08: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 09: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 09:46 PM MDT #

Thanks for the great comparison Matt. YUI has always been my favorite, fantastic documentation and user community. I've chosen YUI for PrimeFaces JSF component library as the main client side engine and it suited well to the JSF component model.

Posted by Cagatay Civici on April 24, 2009 at 11:25 PM MDT #

Matt, how many developers participated in this analysis?

Thanks.

Posted by Yuval Goldstein on April 27, 2009 at 10:26 AM MDT #

@Yuval - there were 4 of us, matching the number of candidates we evaluated.

Posted by Matt Raible on April 27, 2009 at 03:36 PM MDT #

What about ZK ?

Posted by pascal on April 28, 2009 at 01:11 PM 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 09:34 PM MDT #

I was hoping that you'd have another testability row for unit testing. That is a very important quality, IMO.

Posted by tieTYT on April 28, 2009 at 11: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 29, 2009 at 12:58 AM 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 29, 2009 at 01:11 AM 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 07:50 AM MDT #

I'm curious why you rated GWT as better than the other three in the "Degree of risk generally" category. If it's because your folks were more familiar with java than js, that's covered in several other categories.

Posted by Larry Maccherone on April 29, 2009 at 11: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 12:49 PM 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 02:06 PM 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 08: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 09:31 PM MDT #

jQuery is the Best!

Posted by Patrick Keenan on April 29, 2009 at 09: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 10: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 30, 2009 at 01:22 AM 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 30, 2009 at 03:45 AM MDT #

but therein lies your problem .. mixing java and javascript. When your UI is managed & created by server side components that create code to execute in another environement (aka a browser) .. the server/client boundaries become so blurred you end up with a half breed mongrel dog. Using a client side widget framework (eg Ext.JS) vs a server side widget framework (eg icefaces) keeps those boundaries clean. Your entire widget stack can be nicely debugged via Firebug and Venkman and you're not abstracted away from where the UI action happens.

Posted by Simon Gilligan on April 30, 2009 at 03:57 AM 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 11:18 AM MDT #

Well .. I guess we can agree to disagree. Even with our collective eons of developer experience I suspect we'll still take a different path. If the products you create are kicking goals, then all power to you.

Posted by Simon Gilligan on April 30, 2009 at 01:49 PM MDT #

Another good comparision! But where is mootools?

Posted by ???? on May 01, 2009 at 02:36 PM MDT #

Wikipedia has a nice feature level comparison: http://en.wikipedia.org/wiki/Comparison_of_JavaScript_frameworks

Posted by Nandatte!? on May 03, 2009 at 12:59 AM 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 09: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 10:13 PM MDT #

Matt, how would you rate YUI's layout management against GWT's? Obviously GWT Swing-Style Panel seem very nice, do you think YUI's layouts are comparable? Thanks.

Posted by Yuval Goldstein on May 17, 2009 at 01:46 PM MDT #

I have done JSF with Richfaces extensively. It is nice.

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 June 01, 2009 at 03:10 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 michelle on June 01, 2009 at 11: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 12:06 PM MDT #

Really... Check this out, its part of a native iphone app which uses an icefaces webapp as its backing server. This will be something like twitter only with images and video. http://web.me.com/cannonwc/Site_6/StoryBoard.html

Posted by michelle on June 10, 2009 at 01:02 PM MDT #

saw the site but not still impressed with the fact that icefaces is basically jsf under the hood while to me personally after frustration from jsf believes that GWT , is whether you like it or not ,JSF GOT RIGHT!

Posted by afolayan on June 10, 2009 at 01:46 PM MDT #

Of course I disagree with you... And you could not do what I did with GWT. at least I don't think so. I needed complete isolation of the webapp from the client. If I remember right there is a tight integration between the web and the client with gwt, like dwr, which is why its hard to combine with other server based technologies. In my example, the client app interacts with the web mostly through the servlet, which acts as kind of a controller. you send an http post to the servlet, it updates info on a singleton which causes the update info to be pushed to all registered sessions. I suppose the rest, the JAI imaging and display parts you could do with GWT.

Posted by michelle on June 10, 2009 at 01:56 PM MDT #

Disagree after you try GWT. It is too easy to start.

Posted by Vinay Soni on June 11, 2009 at 01:29 AM MDT #

That may be true, but I think its a bust for iphone apps, especially native ones, which seem to be the trend. However, I have seen some pretty nice gwt iphone Web applications. Nothing that couldn't be done in icefaces, but nontheless very cool.

Posted by michelle on June 11, 2009 at 10:48 AM MDT #

+1 for Vinay Soni

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 02:41 PM MDT #

Why SmartClient from Isomorphic is not considered?

Posted by 218.186.12.237 on August 30, 2009 at 09:52 AM MDT #

This is an awesome comparison. I love the discussion too.

Posted by laker2000 on October 14, 2009 at 02:07 AM MDT #

It's almost 2 years later ... do you have an update you can give? Would love to hear it. Am working with grails and am looking at using GWT as my view technology vs jQuery and its UI and plugins.

Posted by Ray K on September 20, 2011 at 10:17 PM MDT #

Post a Comment:
  • HTML Syntax: Allowed