I used SmartGWT 2.3 in our last project (duration: 6 months). I wanna share my experiences with that component library in the following.
IMPORTANT: All information is my personal opinion! We bought the SmartGWT Power license, but we used SmartGWT without commercial training or commercial support. Regard this, when you read my stated CONs!
SmartGWT (http://code.google.com/p/smartgwt) is a component library for the Google Web Toolkit (GWT). Four different licences exists. The visual components are free (LGPL). Three further licences exists (see http://www.smartclient.com/product). 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 (http://www.smartclient.com/smartgwt). 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: http://www.smartclient.com/smartgwt/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: http://www.sencha.com/products/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.
I 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.
Yes and no.
The components are great! They are easy to integrate and save a lot of development time. So I would use the client-side again.
The server-side integration is time-consuming and has no advantages for our team. 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
In the age of digitization, the concept of pricing is no longer fixed or manual.…
In the rapidly evolving landscape of intelligent traffic systems, innovative software provides real-time processing capabilities,…
In the fast-paced world of finance, the ability to prevent fraud in real-time is not…
Choosing between Apache Kafka, Azure Event Hubs, and Confluent Cloud for data streaming is critical…
In today's data-driven world, understanding data at rest versus data in motion is crucial for…
If you ask your favorite large language model, Microsoft Fabric appears to be the ultimate…
View Comments
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. http://www.smartclient.com/releases/SmartGWT_Quick_Start_Guide.pdf Alos, if you look at the Pro/EE Showcase (Kai linked only to samples for the LGPL edition of the product):
http://www.smartclient.com/smartgwtee/showcase/ 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: http://forums.smartclient.com/search.php?searchid=373665Kai'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.
@Charles:
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 we 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 did not post most of our problems). 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 worse if they are not, I just wanted to report OUR experiences! To make this more clear, I will add this information to the beginning of the article!
Hi Kai,
Thanks for the post.
I think Isomorphic Software should also consider a client-side only licensing model (both open source and commercial).
Cheers
Rob
Hey Rob,
that is exactly my opinion.
Best regards,
Kai Wähner
Thank you kai for posting your experience, I found it helpful! And thank you to Charles Kendrick for unintentionally showcasing the difference between trying to help other people with something useful and trying to sell something.
The bizarre quote about money and power wasn't left by me (obviously).
Mike, take a look at Kai's article where it was posted at Dzone - we got to the bottom of his problem and why he thought he had to create "huge XML mapping files" - he misunderstood how the framework was meant to be used in a way that is now prominently covered on the very first page of the QuickStart Guide's chapter on the server framework.
http://java.dzone.com/articles/lessons-learned-smartgwt-23-%E2%80%93
Telling people to look at the QuickStart Guide was the right answer in terms of helping people, and the only one that could be given since Kai had not given any specifics about why he thought he had to create mapping files.
I deleted the "spam post" by the anonymous guy pretending he is you...
Well, also after looking at the QuickStart guide, our developers could not realize OUR use case without changing the huge XML files to add operation bindings. Maybe it is also possible in our (complex) use case, but we could not find out how...
So my conclusion is still the same as before: SmartGWT is powerful and has great widgets, but if you use the server-side too, then you should always buy the support!
Best regards,
Kai Wähner
Kai you still seem to be assuming that you're going to be generating large XML files to disk, then editing them. But we show right at the beginning of the Server Framework chapter of the QuickStart Guide that there would be no need for a large XML file at all - literally a one-liner is enough.
The relevant except is right here, at the bottom of this post:
http://blog.isomorphic.com/?p=227
I should also point out, you can extend the XML descriptor with your own properties, and you can dynamically provide the XML descriptor to the system as well. So even if you perceive a need to put any kind of redundant information into XML (honestly we've never seen such a use case), you can easily provide the information dynamically and eliminate that redundancy.
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)
I also tried SmartGWT (LGPL version only). I played with the portlet sample and it was easy to embed GCharts inside the SmartGWT portlets.
But when it comes to database/server connection it was not that easy. There are no samples how to use the datasource with the LGPL version of SmartGWT and since GWT RPC is not recommended I didn't use it either.
After 2 hours I gave up and stick to Vaadin. The integration of the GWT chart took some time but the documentation (integrating GWT widgets) helped a lot. The documentation of Vaadin is way better than SmartGWT's doc.
Since Vaadin is a server-oriented RIA, database connection is plain Java (JDBC, OR mapper...) and thus easy and communication between GWT chart and Vaadin also pretty straightforward.
SmartGWT has a huge widget library and it might be powerful in conjunction with its proprietary server stuff. But Vaadin is easier for Java developers using the standard tools. In addition Vaadin's documentation is much better and you get working results (server-client communication, database access, AJAX client behavior) at no costs compared to the need for the commercial license of SmartGWT.
Thank's for this interesting article Kai,
btw: do you have any experience using Ext-GWT?
Regards,
Dieter
Hey Dieter,
I have no practical experience with Ext GWT. But probably, most of my pros and cons are true for Ext GWT, too. You also have to learn a new API, you also have great widgets, and so on...
One difference is, that Ext GWT is a real Java / GWT framework while SmartGWT is "just" a JavaScript-Wrapper. But this does not matter, except you want to build you own widgets (and because there are so many good widgets, you probably do not have to build your own widgets).
You should try out both and compare their widgets to decide whether you want to use a component library instead of plain GWT, and then decide which one to choose by comparing especially the widgets and server-integration.
Best regards,
Kai Wähner (Twitter: @KaiWaehner)
I enjoy S'GWT day by day! ;-)
Sure, both client and server side require some learning effort. logically. I do not plan to write my own widgets as S'GWT gives me all I want, so GWT compliance here is not an issue to me. Using the declarative power of the S'GWT container widgets I don't even miss any user interface builder.
My only issue so far is the initial load of the isc js files. For 99% of the scenarios this is not a big thing, in 1% it is and I don't know how to solve this. I tried to load only a subset of those files but at the end of the day I don't think that this is a useful approach. Maybe GWT optimizations are also an issue to S'GWT as it uses JS stuff (SC) rather than native GWT code but so far I do not face any run-time issues (once the isc files are loaded).
Meanwhile I created a powerful class library, integrated several own Web services, with extended S'GWT controls and really love to think about UI design and workflows, software architectures, re-usability and patterns rather than cross-browser issues, signature/data flattening and structuring, CSS nightmare, untyped, non-namespaced JS, etc.
Ekki
I've worked with the SmartGwt components for the last year, and even though I now have a working app, I've spent the last 6 months regretting my choice of components. There is no denying that the data-bound components are handy, but there are so many bad sides to this lib that totally outweigh the good ones, so in the end it doesn't really matter if the back-end connectivity is simple or not.
For me, the bad points have been:
1. 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?".
2. 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 and get a satisfying answer to my problem. At best they ask you to provide a stand-alone test-case, but even when you do 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.
3. The showcase is too limited. At first glance, the showcase looks very impressive, with over 300 different samples. At closer glance, this is all superficial. There are very few good examples of data bound components using JSON, nothing at all on dynamically generated and data-bound forms, and there are several cases where the code in the sample does not render the same behaviour as that in the sample.
4. As soon as your use-case diverges just a little bit from what is in the showcase, things turn really ugly. I, for example, have a tree where the same element can be present at several places at once. This is the nature of my data, but since the tree component in smartgwt doesn't allow duplicates, my duplicates are simply removed, which has the effect that my data is incorrectly rendered. The workaround is utterly tedious, with manually generated id-strings and a lot of back-end nonsense to make sure that any changes made to one version of the same object gets propagated to all the rest of the versions in the tree. The resulting code is nothing short of monstrous, and it really isn't my fault.
In the beginning I would recommend people to use SmartGwt in their projects, but nowadays I just advise them to stay far, far away. I wish someone had given me that advise a year ago...
Mia, I'm having some trouble believing that you are a real person who has actually used our product. Our competitors have a habit of posting fake reviews.
My apologies if this is an incorrect assessment, but it would be very simple to convince everyone here:
1. can you point to just one instance of a standalone test you provided that demonstrated a bug that wasn't fixed? Because we very often provide overnight fixes for bugs, even if the user reporting it doesn't have support
2. if there is any sample that doesn't work outside of the showcase, congratulations on being the first ever to find it! Can you point out which one?
3. there's a huge number of Showcase samples related to dynamically generated and data bound forms - in fact I'm not clear what you could mean by this since all the samples show Java code - so it's all dynamic already? I'm not sure how anyone could have worked with our product at all and say something like this - could you clarify?
4. the tree allows duplicate nodes, just not duplicate node ids. On a number of projects we've dealt easily with duplicate nodes, I'm not sure how you ended up with "monstrous" code, but I feel pretty confident a simplification was available. If you can share details, I can help.