Kai Wähner (Twitter: @KaiWaehner, Blog: www.kai-waehner.de/blog) is an IT-Consultant in the Java EE, SOA, Cloud Computing and Big Data world. In his real life, he lives in Erlangen, Germany and works for TIBCO (www.tibco.com). Besides solving huge integration problems for large companies, Kai writes articles for magazines and speaks at international IT conferences such as JavaOne. Feel free to contact him via Twitter, LinkedIn or Email. Kai is a DZone MVB and is not an employee of DZone and has posted 50 posts at DZone. You can read more from them at their website. View Full User Profile

Lessons Learned: SmartGWT 2.3 – Component Library for Google Web Toolkit

  • submit to reddit

I used SmartGWT 2.3 in my last project (duration: 6 months). I wanna share my experiences with that component library in the following.

IMPORTANT: All information is my personal opinion! I bought the SmartGWT Power license, but I used SmartGWT without commercial training or commercial support. Regard this, when you read my stated CONs!


What is SmartGWT?

SmartGWT is a component library for the Google Web Toolkit (GWT). Four different licences exists. The visual components are free (LGPL). Three further licences exist. These licences offer several additional features and components such as data binding, a “push”-implementation or Hibernate integration. We chose the Power Edition. SmartGWT is maintained by SmartClient. SmartClient also offers commercial support.

Technically, SmartGWT is a wrapper framework for the JavaScript library of SmartClient. The whole architecture is described within the documentation of SmartGWT. To summarize: SmartGWT has a end-to-end application architecture where the client-side is for free and the server-integration is commercial. Of course you can just use the client side of SmartGWT, then you have to implement the server-side integration by yourself. In our project, we used GWT 2.0 and Smart GWT 2.3 Power.



  • Many good components (almost everything you can imagine). Look at the showcase. All components are displayed including source code examples.
  • Verbose documentation and API. Every class has good documentation.
  • Support for many technologies and frameworks (Hibernate, JMS, REST, WSDL, Microsoft Excel, and so on)
  • Good performance. About 5000 data entries are inserted daily into one table. Thanks to “Live-Scrolling”! The initial loading of the web application takes some seconds, but that is no problem of SmartGWT, but a characteristic of every client-centric Rich Client / Rich Internet Application.


  • You have to learn a totally new API. You know GWT, you know JPA, Hibernate or JDBC? Does not really matter! You just use the SmartGWT API. That is a problem especially for getting started and for maintenance, because other developers also first have to learn one more API.
  • Almost no public information available (books, tutorials, blogs, articles, talks at conferences, best practices).
  • No tutorials for realizing some (at least a little more complex) use cases. [UPDATE January 2011:] SmartGWT EE 2.4 released including much more extensive documentation and a good quick start guide!
  • Commercial support is expensive. First we wanted to buy support (for some hundred dollars we thought), but it costs approximately as much as the SmartGWT Power license itself.
  • Sometimes bad forum support. You get an answer to almost every posted question. But that answer often does not help. They ask you things such as “why do you want to do that”. Or they say: “use our tool and do XYZ with it” three times, although again and again I told them this suggestion does not work. After a few answers to a question the final answer is: “you need training, buy our support”. So you can either buy the support or try to find a workaround by yourself – and that can take a long time because you do not know the internals of SmartGWT and there is no public information such as a book, which you can “ask”.
  • Promises to reduce boilerplate code because it automatically does the connection and integration to the database (create, read, update, delete) – that is true. But solely if you do not want to change anything and just use the basic behaviour. If I wanted to change just a small piece, I updated the automatically generated, huge XML mapping files or used setter-methods within the Java Code. If I just re-generated the mapping file, custom changes (e.g. specific WHERE-clauses) were overwritten, too. I could not find a better way. Thus, I do not see any benefit in using this server-side integration of SmartGWT instead of plain Hibernate or JDO and GWT RPC or REST communication. You just have one more abstraction layer to learn.
  • Just a wrapper about a JavaScript framework instead of a native GWT implementation (for a counter-example see Ext GWT). That is no problem, if you just want to use the components. It is tougher, if you want to extend them. (Another myth is a worse performance because of this fact. We did NOT have any performance issues because of this fact)


At first glance, SmartGWT is a gift for you. The components are integrated in your web application easily. Your prototype is realized very fast (with dummy data instead of a real datasource). But the server-side integration is a lot of effort.
We had a lot of problems to solve and workarounds to find. Of course, you also have problems with other frameworks, but you have public information to look at for solutions.

Finally, SmartGWT did not save any development time (in my opinion! Some team members have another opinion and think it saved development time). Additionally, the project cannot be maintained by other developers, expect they also invest a lot of time in the SmartGWT API.

Would I use SmartGWT again?

Yes and no.

The components are great! They are easy to integrate and save a lot of development time. So we would use the client-side again.

The server-side integration is time-consuming and has no advantages for our team (again: my opinion, some team members have another opinion and think it saved development time). If we had used JDBC, MyBatis or Hibernate for persistence and GWT RPC or REST for client-server-communication, then we would have finished the project with the same expenditure of time. But with some advantages: We know what we do. SmartGWT is one more abstraction level, and that is not an advantage in my opinion. Also, other developers can maintain the web application in the future, because they already know Hibernate or EclipseLink or Toplink (if you know one OR-Mapper, you can use them all).

Finally, I (again: me, not other team members) would use the client-side again, but not the server-side. Paradoxically, SmartClient earns money solely with the server-side stuff or the (proportionally too expensive) support.
SmartGWT is a very nice component library, but maybe the guys at SmartClient should rethink about their business model, if they want to acquire more customers.

Do you have the same expericences? Or do you disagree? Please make a post and tell me…

Best regards,
Kai Wähner (Twitter: @KaiWaehner)

[Content from my Blog: Lessons Learned: SmartGWT 2.3 - Component Library for Google Web Toolkit (GWT)- Kai Wähner's IT-Blog]


Published at DZone with permission of Kai Wähner, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Dejan Krsmanovic replied on Mon, 2010/12/13 - 5:02am

(Another myth is a worse performance because of this fact. We did NOT have any performance issues because of this fact)
Did you have performace issues when running application in GWT development mode? In our case, application is so much slower in development mode that it almost becomes useless. However, we are using custom GWT-RPC data sources so this might be the reason as there are much more JSNI calls.

Aleksandar Vidakovic replied on Mon, 2010/12/13 - 5:23am

Thanks for the nice overview. I was almost tempted to use SmartGWT, because of the really rich choice of components. But finally decided to use Vaadin which is a lot nicer concerning integrating other frameworks (in my case mainly Spring Framework) and the license (Apache 2.0). And Vaadin really has a nice choice of components too (although fewer than SmartGWT). I am wondering why the JBoss RHQ guys made the choice to use SmartGWT for the next generation of their UI...

Kai Wähner replied on Mon, 2010/12/13 - 11:38am


 I added one PRO i forgot! Please read it again. We had no performance problems. The GWT development mode worked without any problems.

And we also used some GWT-RPC calls to call some EJBs (but we do NOT use JSNI / handwritten JavaScript at all).



I also like Vaadin. I think it is a great alternative if you want to realize a server-centric web application.

Chad Retz replied on Mon, 2010/12/13 - 1:18pm

I have used SmartGWT on numerous projects (after getting really frustrated w/ Ext GWT's licensing terms like lots of others). Sanjiv has done great work porting the SmartClient library. I only use LGPL stuff which means I never use any of the server side components, so I cannot comment on them. As far as the client side, I have used it with success. I have even been able to successfully integrate gwt-platform's MVP pattern with it.

Having said that, the interoperability between SmartGWT widgets and regular GWT widgets is horrible. For the most part, either go all SmartGWT or no SmartGWT, not a hybrid approach. Also, with complicated screens containing list grids and tree grids, there is an extreme slowdown on browser resize. This is due to the fact that even though widget dimensions are expressed as percentages, it is all translated to literal pizel widths. Complex screens will really hurt browser/CPU performance when resizing.

Finally, I have become increasing concerned with the LGPL side. 2.3 is STILL not out yet for LGPL. The Isomoprhic blog said 2.3 would be ready a "few days" after the EE 2.3 release, and that was in August. Then they said in another blog they are going to skip 2.3 LGPL and synchronized w/ 2.4 and that would be out by 11/14. NOPE! I know I can't expect much since I am relying on a free, commercially-friendly licensed library. All I expect is some disclosure. The LGPL update stream stopped many months ago. I'm not scared though, because I see commits to the repo frequently.

Kai Wähner replied on Mon, 2010/12/13 - 1:39pm

[quote]I have even been able to successfully integrate gwt-platform's MVP pattern with it.[/quote]

 We also used the MVP pattern. I can recommend it to everybody! Also, since version 2.1 the MVP pattern is integrated in GWT.

[quote]the interoperability between SmartGWT widgets and regular GWT widgets is horrible[/quote]

That is true. But because every GWT widget is also available as SmartGWT widget, that is no problem, isn't it? So you do not have to combine both.


Best regards, 

Kai Wähner (Twitter: @KaiWaehner)

othman El moulat replied on Mon, 2010/12/13 - 1:43pm

I used The Free smartGWT edition and found it slow rendering components even in the client side. I haven't used any smartGWT server side functionality and Yet just clicking a ListGrid row to show a ListGrid Editor form took about 5 seconds to open ListGrid row editor. in development mode the slowness is worse.

I'm surprised by your statement that smartGWT performance is good . the component rendering seems slow for me . or am i wrong?


Kai Wähner replied on Mon, 2010/12/13 - 2:04pm in response to: othman El moulat

I can only report from our project.

We use some tables with thousands of data entries (with live-scrolling). We use Buttons and Dropdown Boxes to Open new Windows. These windows also load data form the DB to manipulate them (CRUD). The new windows are loaded within some milliseconds. New data is auto-refreshed. If we store data, it shows up in the GUI instantly.

It is not that complex GUI! And it works really fine. Maybe there would be performance issues with huge or complex GUIs, but for us the performance is good and sufficient!


Best regards, 

Kai Wähner (Twitter: @KaiWaehner)

Charles Kendrick replied on Mon, 2010/12/13 - 6:38pm

Kai, some of your criticisms are out of date and some are.. well it's hard to see where you're coming from.  I'll respond to each:

  • No public information available (books, tutorials, blogs, articles, talks at conferences, best practices).
  • No tutorials for realizing some (at least a little more complex) use cases.

The SmartGWT QuickStart Guide was released shortly after the version Kai was using (2.3).  It contains materials that get you all the way to doing complex joins that allow editing - much further than most tutorials with other products take you, because far more is done for you in SmartGWT.


Alos, if you look at the Pro/EE Showcase (Kai linked only to samples for the LGPL edition of the product):


You'll see many examples of tough use cases handled with very little code: master-detail with full load and save to Hibernate, multi-row transactional drag and drop, etc.

In other products' Showcases you'll typically find read-only samples with canned datasets, or at best, simple CRUD for one enitity with no customization.  We feel that SmartGWT goes much farther that other products in addressing tough use cases in samples and tutorials.

  • Promises to reduce boilerplate code because it automatically does the connection and integration to the database (create, read, update, delete) – that is true. But solely if you do not want to change anything and just use the basic behaviour. If you have to change just a small piece, you have to create huge XML mapping files (as with hibernate or JDO). So, the benefit is gone in almost every enterprise project.

Have to really emphasize this: this is absolutely, 100% percent completely false.  The fact that you ended up writing some kind of "mapping files" suggests that you badly misunderstood how the product is meant to be used and did something unnecessary.  Isomorphic itself and Isomorphic's many customers build extremely large, complex enterprise applications and we never end up with weird extra mapping files.

We've carefully designed the server framework so that you can leverage the automatic CRUD functionality and yet be able to override any part of it easily.  Here again one should look at the QuickStart Guide, which explains how you can write Java code to get involved in any phase of the automatic persistence behavior. 

  • You have to learn a totally new API. You know GWT, you know JPA, Hibernate or JDBC? Does not really matter! You just use the SmartGWT API. That is a problem especially for getting started and for maintenance, because other developers also first have to learn one more API.

This "totally new API" is what automates away all the boilerplate code typical of direct use of JDBC, Hibernate, etc.  For example, the following one-liner provides full CRUD connectivity to a target SQL database, and automatically provides default component definitions for grids, forms, detail viewers and other UI components based on SQL metadata.  This can then be customized at fine granularity without throwing away any of the automatic behaviors:

    <DataSource ID="contacts" serverType="sql" tableName="contacts" autoDeriveSchema="true" />

And, you are always free to drop down to direct Hibernate or JDBC usage, in fact, we make it very easy to have SmartGWT call pre-existing Java methods where you are directly using Spring / Hibernate / etc (via DMI - see the QuickStart Guide).

The only part of this that's true is that SmartGWT's widgets are different from core GWT widgets, although very little effort is required to learn the differences (it's the same concepts, just different property names generally).

  • Commercial support is unbelievably expensive. First we wanted to buy support (for some hundred dollars we thought), but it costs approximately as much as the SmartGWT Power license itself.
  • Often bad forum support.

I am amazed by this critique.  Here are Kai's actual posts (user KaiW) so you can judge for yourself:


Kai's team declined to purchase a support plan, yet the support team helped him with a number of issues, even delivered a bug fix in 2 days.

Second, as far as pricing, we're typical of other similar plans from competitors.  Don't be fooled by what appear to be unlimited support plans that are actually credit-based.

@Chad: resizing performance: we're not getting reports of end users complaining about resize performance, but if you have a bad case, try posting it to the forums.  Also, in 2.4 we've made signficant across-the-board performance improvements. As far as the 2.3 release, we are going right to 2.4 for LGPL.  In the meantime, LGPL users have always been free to download nightly builds (smartclient.com/builds) that match the timestamps of official releases for Pro et al (we probably did not make this clear enough regarding the 2.3 release).

Obviously customers get more, but our practice is typical of other source projects - for example SpringSource requires a license/support purchase to get certified builds.

Finally, re: Vaadin - it's a good technology but only if you are willing to accept all the limitations of a server-centric approach:

1. offline is impossible

2. due to more server trips to run server-side logic, the application will always feel sluggish relative to a client-centric solution, especially when latency is high (mobile) or the server is heavily loaded.  This reduces end user productivity.

3. advanced drag and drop scenarios in which logic must run on every mouse move basically cannot be achieved with acceptable user experience & server load. Likewise anything where you want to run custom logic per-keystroke.

4. scalability issues because of greatly increased server load, due to:
 - many additional server requests
 - server-side memory footprint of having the entire UI component model represented server-side
 - replicating the server-side UI state between servers in a high-availability clustered environment.  No, sticky sessions doesn't solve this; sticky sessions aren't always available (GAE) and even when they are, high-availability cluster environments still replicate to at least one other cluster member to avoid data loss on server failure.

Chad Retz replied on Mon, 2010/12/13 - 6:59pm in response to: Charles Kendrick

Charles, thank you very much for your response. If, in 2.4, my TreeGrid resize concerns persist I will post it on the forums. Hopefully 2.4 LGPL is dropped soon because my peers simply wouldn't accept a nightly build to support our production app.

Kai Wähner replied on Tue, 2010/12/14 - 7:25am


Thanks for your extensive comments. I do not disagree with a lot of your post, but remember: This is our experience! Some things you posted may be true, e.g. this one:

[quote] Have to really emphasize this: this is absolutely, 100% percent completely false.  The fact that you ended up writing some kind of "mapping files" suggests that you badly misunderstood how the product is meant to be used and did something unnecessary. [/quote]

Yes. Maybe you are right! Maybe I did not understand some part of the product.

But the problems we had to solve were not in any tutorial or guide (by the way: I am not the guy who posted most of our problems in the forum). And the forum support could not help us with some of these problems. So maybe you can do this without mapping files, that is great! But unfortunatelly we could not make it, also if it may be possible!

So again: this is my experience with the product after one and a half persons worked some months with it (WITHOUT training or commercial support). I do not want to make things bad if they are not, I just wanted to report MY experiences! To make this more clear, I will add this information to the beginning of the article!

Next time, if we have to decide to use the server-side integration of SmartGWT, we would probably decide against it or also buy support, because in my opinion it is absolutely necessary to use SmartGWT successfully.


Deepak Jacob replied on Tue, 2010/12/14 - 11:57am

I have used SmartClient 6.5.1 ( SmartGWT's parent ) and I do not really appreciate the development experience. 1. The UI works when the application is only doing things that it is expected to do ( Expected means - you should try out the only things which have been displayed in their examples ). 2. The memory management is really really poor ( better say there is no memory management). A single form with 15 - 20 controls will take up 6-8 MB memory and will be never released when it goes out of view. 3. The rendering and the layout ( part of framework) will take at least 5-6 seconds per screen in addition to the network latency. 4. In version 6.5.1 the product does not natively support a select all check box in the grid header. You need to code for that ! ( minimum 50 lines code - for the custom component) 5. The code base is really very old and there is no such thing called custom events. Or more clearly I feel like old code base prevents the development team from doing any sensible refactoring and performance improvement which will make the product better. 6. The forums really suck ( as said earlier all suggestions/ answers will indirectly ask the developer to go for support. No other source of knowledge other than forum and support ( no blogs / no books ) 7. Another big issue is that auto complete wont support more than 50-60 items. The control wont show any results after the earlier specified limit. 8. Long release cycles and uncertain future of the framework. Really cannot be compared to any other open source / closed source AJAX framework. 9. No pagination support in grids ( I know that you guys support pagination from primary memory and this is a no-no as I have millions of records for the matching condition in database) Hope this will help people who are evaluating this framework.

Charles Kendrick replied on Tue, 2010/12/14 - 3:46pm

Kai, I appreciate that you added a disclaimer up top, but the problem both with the original article and how you've modified it is that you state this:

"If you have to change just a small piece, you have to create huge XML mapping files (as with hibernate or JDO). So, the benefit is gone in almost every enterprise project."

 You state this unequivocally.  You do not say "we could not figure out a way to avoid huge XML mapping files", you say that if you just want to change a small piece you "have to" create mapping files.

 And again this is 100% unequivocally absolutely false.   I hope you will choose to rephrase this key part of your article as it is misinformation that is damaging to our product and our community.

 @Deepak This is an obvious troll full of obvious falsehoods, most of which are immediately disproved by a brief glance at the online showcase.  No, there are no layout delays (just see the showcase), no leaks as you claim (just measure the showcase), pagination is very well supported and performance is very good (as Kai noted), and there are extension points everywhere that make it easy to build whatever you want

The truth is that SmartClient is used by many of the world's largest banks, defense contractors, life sciences companies, insurers - dozens of $1B+ institutions.  It is used to build critical business applications that are used all day long without reloading the page.  None of what you say about the technology could possibly be true given that usage.

Furthermore you are making a random feature attack on a 2.5+ year old release, and pretending that there is uncertainty about the product?  The rate of innovation in SmartClient and SmartGWT is faster by far than in any competing solution, and I would invite anyone who has any doubt about this to look at the huge list of new features in our 7.0 and 8.0 releases:



As you will find, most of these powerful features are not available in any competing product.

Kai Wähner replied on Wed, 2010/12/15 - 4:08am in response to: Charles Kendrick


I agree with you, that the "I perspective" is missing in this part! I do not want to damage anyone. So I also changed this part a little bit to make clear, that this is MY personal experience.

Probably, I still would use plain Hibernate and GWT RPC next time instead of the server-side integration of SmartGWT.

But there is no question that you can also build good, complex enterprise web applications with SmartGWT - of course you can! If someone wants to use SmartGWT server-side, the support must be bought, too (in my opinion).


Best regards,

Kai Wähner (Twitter: @KaiWaehner)

Dino VV replied on Wed, 2010/12/15 - 12:33pm

A friend of mine used SmartGWT for his project and had the exact experience as you. He likes the components, but the support from the forum is simply under par.

Alexander Kleymenov replied on Fri, 2010/12/17 - 4:45am

Would recomend SmartClient for rich client applications: rich and consistent component set, good performance, well documented code, clean library design, simple API, excellent showcase and reference guide (made in form of dogfooding web application), works well in conjuction with other js libraries (jQuery), LGPL..

The only problem is with its not quite open source development model - no public code repository, no mail lists, no bug tracking system. Hence lack of community involvement (patches, features, blogs, discussions, etc) and fear for the library (investment) future.

BTW: forum is a mess! But better than nothing.

There was smartclientexperience.com but now it's gone :(

Charles Kendrick replied on Sat, 2010/12/18 - 5:35pm

@Kai your clarification now explains your whole experience.  As explained above, and prominently mentioned in the very first page of the QuickStart Guide chapter on the Server Framework, you are intended to use attributes in the DataSource file to indicate what SQL table or POJO/entity fields should be derived from, like so:

    <DataSource ID="contacts" schemaBean="com.sample.Contact"/>

This declaration causes one DataSource field to be created per Java Bean property.  You can then override any single field definition if you want to change something.  No re-running generators or having changes wiped out, and to try out changes, just reload the page.

Hopefully now that we've made this so prominent in the documentation, no one else mistakenly goes down the path you did.

As to support, I would again invite people to check out the actual forums.  First of all, no one posting here purchased a support contract, so they have never actually experienced support at all.

If you look at supported users on the forums, there is a constant stream of thank-yous and wow-that-was-fast comments.  And despite claims to the contrary, our support rates are industry standard.

Finally, to correct several mistatements by Alexander:

1. public code repository (Google Code) for SmartGWT

2. nightly builds with source: SmartGWT / SmartClient

3. public bug tracker

There are also several blogs, and users frequently post patches the forums, which are rapidly incorporated.  For one, SmartClient Experience simply moved, and the content is better than ever.  We are also about to roll out a public wiki.

In a nutshell, we have a very active community with a high level of participation, as well as a very very long list of $1B+ institutions who rely heavily on our software for their core business.  We're innovating faster than anyone else, and that's not going to change.

David Johnson replied on Sat, 2010/12/18 - 11:11pm

@Alexander, the SmartClient Experience blog still exists it just moved to smartclientexperience.wordpress.com.

Alexander Kleymenov replied on Tue, 2010/12/21 - 7:34am

@Charles, I meant SC's code repository and bug tracker. Sorry for confusion!

@David, Thank you for running the blog! Happy to read updates.

Charles Kendrick replied on Wed, 2010/12/22 - 10:24am in response to: Alexander Kleymenov

@Alexander  SC source is available nightly at the URL provided above.  The bug tracker, while technically hosted at the SmartGWT project, is shared (most bugs are bugs in both systems if they are legit).

So again: source access, bug tracker, nightly builds, forums, blogs, wiki (soon) - everything you'd expect is there.

Mark Johnson replied on Sat, 2010/12/25 - 6:40pm

Take a look at -> http://code.google.com/p/crmdipity/

Its a sample application that provides a practical introduction to GWT, gwt-platform (e.g. MVP, dispatch) and smartGWT application development.



Kai Wähner replied on Wed, 2011/02/02 - 5:05am

Meanwhile, Smart GWT 2.4 (LGPL and EE) is available. Besides some very good new features such as offline capability or some more powerful components, the quick start guide is much more extensive than some months ago. I really appreciate that!


Best regards,

Kai Wähner (Twitter: @KaiWaehner)

Miamaria Von Knutte replied on Fri, 2011/03/11 - 8:02am

Isomorphic support (paid licence) sucks like nothing else. My opinion is that if you pay for someone to help you, they should help you when you need it. Isomorphic seems to be of the opinion that if someone pays you, they’re suckers and should not be helped, even in the least. Honestly, I’ve yet to report a single bug, or ask for help with a problem, and get a satisfying answer to my problem. At best they ask you to provide a stand-alone test-case (very time-consuming work), but even when you provide this there is very little help coming out their end. As a company, they’ve very much failed to make me want to buy anything of theirs ever again.

Isomorphic's claims that paid support is worth it are just not true. Do not, under any circumstances, be tempted into paying these people for support. Better yet, chose another widget lib, you'll be happier off without this company in your life.

Finally, a point about their api. The interfaces are totally bloated, disorganised, inconsistent and frustrating. The design of the api is really poor, and this is visible in the vast amount of questions in the forum of the type “what method should I use to do foo?”. There is also a huge amount of string parameters used to control behaviour, which is both ugly and unsafe. Again, absolutely horrible.

Ryan Blace replied on Sat, 2011/08/06 - 11:39am

We're building a web app, and we actually started with Vaadin. About 30 hrs in, I had an almost complete representation of what we were trying to build. I found their model really nice because I could use a server-side UI Model to handle all of my event brokering and the management of data and the persistence layer.

Our customer directed us to move forward instead with SmartGWT because it is GWT based so their devs would be more familiar with it. We're using the latest versions of both - and trialing the Power license for SmartGWT.

I have to echo most of the comments on this post so far. Vaadin is SUPER easy to use. It has limitations, can be a little tricky to track down bugs, etc... BUT, the documentation is fantastic. I think I found the solution to almost every problem in the Book of Vaadin. If not, I could search and would almost always find a solution in an online forum somewhere. They have a good community of plugins and themes and support. And it's free.

SmartGWT has honestly been a bit of a nightmare. Maybe its cause we did the Vaadin one first, but SmartGWT is a PITA to get working with Maven. It runs differently in Dev mode and in Web mode. It'll work in dev mode and then not work at all in Tomcat, and give no errors or log messages or anything to help you figure out what you broke. It requires a LOT more code and configuration (especially if you want to customize stuff). There aren't many themes available and most of the ones that are don't look all that great. And best (worst) of all, it's practically impossible to find support. Yes, I've read the documentation. Yes, I've gone through the forums. This opinion is based on all those experiences. The documents are extensive, but not particularly precise so I read them and usually am left with many questions. The forums are amusing... I'll find a post by a user who had my same issue, and the Isomorphic response is "RTFM" (not in those words obbviously). Then the user posts a response with "I did. I didn't find a solution." And then no one will respond until the original user a week later will figure it out on their own and post the solution. And there really just isn't a lot of information out there on the intertubes about SmartGWT

I was originally psyched to use SmartGWT because it had every widget we could imagine. But, we quickly realized that there are limitations if you aren't going to use the LGPL version (e.g. the live grid). So we end up having to pay for licenses. I would def go back and stick with Vaadin if I could.

Jessie Mear replied on Wed, 2011/09/07 - 6:44am

Using GWT, developers can rapidly develop and debug AJAX applications in the Java language using the Java development tools of their choice. java programmers

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.