Why I give up using SmartGWT

I guess that most of you agree with me that UI is one of the most painful aspects of building Web applications (at least if you compare it with backend development). Well if you are building a Web application using GWT you may be tempted to use SmartGWT as it provides really cool widgets. Well, that’s true, their widgets are really cool and the themes are great. However, I would like to explain my experience using SmartGWT for a personal project (a first version of the app is shown below).

First version using SmartGWT

My application is pretty basic, just a couple of forms, windows, tabs and toolbars; nothing more crazy than that. The main intent of the application is to allow people to take personal notes. The development went pretty well the first 2 weeks while I was working with the basic stuff; then I realize that I need to use a simple autocomplete field and though SmartGWT doesn’t provide an Autocomplete field OOTB I tried to use a custom solution using the ComboBoxItem; a really bad idea…

First, ComboBoxItem doesn’t work as a field in Calendars so big problem; lucky I found a workaround to fix the issue. Then I tried to make the ComboBoxItem’s datasource work with a remote GWT call though SmartGWT doesn’t provide a OOTB datasource that works with the GWT paradigm. Again, a big mess digging into the javascript code where SmartGWT is implemented

Ok, so let’s try to fix the autocomplete problem using the SuggestBox that GWT provides OOTB. Well, another bad idea as SmartGWT randomly works with GWT and they clearly mentioned in their docs that it is not recommended to mix both.

Finally let’s try to extend the framework to make it work in either case. Well, here is the main issue I found with SmartGwt: the GWT UI classes that they provide delegate most of their behavior to plain javascript that is inside the JAR file. Oh my God, how do you expect developers to extend your framework?

The answer may be: either open the jar and do it yourself or move to Smart GWT Pro (license based). Open the jar or extending at the javascript level lowers the level of abstraction and that’s something I don’t want and the main reason I’m using GWT and not jQuery.

I’m my case it is ridiculous paying for a license and I must say that I’m used to the business model that other open source products have (e.g. Mule, Spring, Hibernate) that you pay for support though you are able to extend the framework easily.

A small suggestion from a disappointed engineer: you have one of the best GWT UI libraries in the market that look perfect and your widgets are really cool, don’t screw it up with this mix which is NOT easy to extend.

At the end, I tried for a couple of days to implement a workaround, the solution was not stable enough to be used in a real application. I end up implementing a basic window and toolbar in plain GWT using GWT Drag and Drop and reuse some of the SmartGWT styling. The results are shown below; now I have an extensible solution that I can fix in case of problems :) but with the overhead of having to fix it myself :( .

Custom solution with Gwt drag and drop


80 Responses to “Why I give up using SmartGWT”

  • AllanC Says:

    I did a bake-off between SmartGWT and GXT and ended up with the latter winning due to the lack of extensibility and lack of integration with real GWT widgets.

    Too bad.

    • Esteban Robles Luna Says:

      Hi Allan,
      Thanks for pointing that. I also checked GXT but I had a license issue with the product.
      SmartGWT seems really good from a look & feel point of view, but sadly, 80% is coded in JS :(

  • Charles Kendrick Says:

    People extend SmartGWT with custom widgets all the time, there are many samples in the Showcase that involve subclassed & composed widgets, there is even a smartgwt-extensions Google code project.

    You’ve made an assumption that you need to reach into the JavaScript in order to build custom widgets, this simply isn’t true. No one is doing this because there is simply no need. None of the above-mentioned custom widgets involve JavaScript-level coding in any way. Instead, they use pure Java subclasses, pure Java method overrides, pure Java event handlers, etc.

    We do (in the FAQ and QuickStart Guide) strongly recommend against GWT-RPC, because we think it’s just not a very productive approach compared to the very strong alternatives SmartGWT provides.

    We likewise (in the FAQ and QuickStart Guide) strongly recommend against mixing widgets from two different frameworks, this is true also of GXT and core GWT or any third-party GWT widget: you can get some early apparent success, but you will ultimately fail with this approach because of issues with tabbing order, different look and feel, accessibility support (ARIA screen readers), and other subtle problems that will be prevent your application from meeting tough enterprise requirements.

    In a nutshell, if you hadn’t gone against SmartGWT’s well-documented best practices in two different ways (GWT-RPC and mixing widgets from different vendors) you would never have had any trouble with SmartGWT. So we would suggest that when you need to build something non-trivial, you revisit SmartGWT and follow best practices, and see what the system is really like.

  • Esteban Robles Luna Says:

    Hi Charles,
    I only wanted to share my experience. Having a mix between Java classes that delegate most of their behavior to Javascript code isn’t a good practice to me and makes things really hard if you need to debug in Dev mode.
    I agree with you that all the existing libraries have the same problem about mixing with pure GWT and if you read my post I clarify it.
    However, I disagree with you with respect to RPC because you are not making the transition from GWT to SmartGWT easy. In addition, extending SmartGWT to use RPC will provide a lot of advantages to your product as it will help adoption by the community.
    HTH

  • Charles Kendrick Says:

    Esteban, I understand and appreciate that you wanted to share your experience, however please also respect that your experience is based on going against our explicitly stated best practices in two major ways :) Your post might be retitled “Why you should really really follow SmartGWT best practices, and what happens if you don’t”.

    As far as GWT-RPC, we explain in both the FAQ and the QuickStart Guide our reasons for not recommending it – we believe the data binding approaches we actually recommend take less work and produce a better result.

    However even if you insist on using GWT-RPC, there is a community-created and community-maintained GwtRpcDataSource class which is 100% Java based on the very flexible clientCustom DataSource API.

    So you are publicly stating that there is a problem with extensibility and that it is somehow related to JavaScript, but in fact the scenario you wanted to address is handled in pure Java.

    Also, we disagree strongly that having JavaScript code is a bad practice. This gives us tremendous advantages in terms of the flexibility of the framework, including the ability to troubleshoot live applications, using the Developer Console, where the facilities of GWT hosted mode would be made useless.

    This is an extraordinarily important advantage, especially when you have a very important customer reporting an issue that you aren’t able to reproduce in your development environment, and you need to solve it ASAP.

    This is also one of the reasons we recommend against GWT-RPC – to difficult to debug with a live site. Some of these things, you only really learn when you support sites where it costs money when a problem occurs, and you need to solve it yesterday :)

  • Esteban Robles Luna Says:

    I tried GwtRpcDataSource (I checked it in the forum) and it was not stable. When you have this problem and the project is open source, you try to get into the internals of the framework using its source code. But it was hard to debug in this case because of what I said before.

    Just a clarification to the SmartGWT community: this is a corner case, if you ever need to debug the internals of SmartGWT with the tools that we have today, remember that it may hurt a bit

  • Charles Kendrick Says:

    That’s very surprising, given that I know of at least one major bank and one large biotech firm, both using GwtRpcDataSource for a lot of transactions every day! :)

    It’s definitely a stable piece of software with a lot of production usage, we have deep familiarity with it because we hired one of the original authors, and because we do recommend it for the corner case of an organization that has already built a lot of GWT-RPC services and is migrating to a SmartGWT UI (at least temporarily), so we have supported it before.

    Please Esteban, I would really appreciate it if you could try not to drop any further bombshell statements like this one! You ran into some problem with GwtRpcDataSource evidently, if so, it would have been great to see you post it to our forums. But to claim it is “not stable” when it’s obvious that there’s a large group of developers happily using it – that’s a bit much!

  • Esteban Robles Luna Says:

    Sure charles, as I said before, it is only my experience though it seems that more people had similar issues too.
    To sum up, do you agree that the debugging issues are still there?

  • Charles Kendrick Says:

    Actually, I’ve never seen a report about a problem with GwtRpcDataSource related to “stability”, by which people usually mean that there are intermittent errors or problems under high load. On the contrary, I know of multiple deployments where it’s under very high load with no issues. Of course, all software has bugs, and we’ve seen specific GwtRpcDataSource issues, not related to stability, just related to functionality, but they’ve already been addressed or workarounds provided. There’s a lot of GwtRpcDataSource sample code out on our forums, and it just works.

    On debugging: with SmartGWT you can debug your own code with Eclipse, just like any Java code, breakpoints etc all work.

    We also have really great tools, especially the Developer Console “Watch” tab and “RPC” tab, really great logging and diagnostics you can enable, and we also log very useful stack traces when there’s an error. Most of these capabilities do not exist in core GWT.

    When you have these tools, it doesn’t make sense to fall back on the very slow, very painstaking process of stepping through framework code and learning undocumented internals that you can’t rely on anyway. That’s just really ineffective. Stick to the tools, and stick to the docs so you don’t end up relying on some internal detail you found out about that isn’t a supported behavior.

    In a nutshell, debugging is an area where we feel SmartGWT has major advantages. This is especially true when it comes to production deployments, where step-through debugging isn’t available, yet SmartGWT’s tools function normally.

  • Allahbaksh Mohammedali Asadullah Says:

    I agree with you. SmartGWT provides good functionality but it is heavy weight and difficult to debug because of JSNI. Please use GWT Mosaic http://code.google.com/p/gwt-mosaic/. It is one of the coolest open source library. The guy George is nice and he fixes the bug very soon. They also provide commercial license on case to case basis.

    • Esteban Robles Luna Says:

      Hi Allahbaksh, Thanks, I will take a look at Mosaic. IMHO JSNI should be used with care and only for primitive invocations

  • realvalkyrie Says:

    Yes , SmartGWT has compatible problem with GWT.

    It’s writteng in native javascript will cause browse compatible and performance problem.(see the latest release of smartgwt :add IE 9 and Firefox 5 support)

    • Charles Kendrick Says:

      realvalkyrie, SmartGWT back to 1.0 works in IE9 and Firefox 5. The release announcement is just making it official.

      The reality is also that SmartGWT has been announced browser compatibility ahead of core GWT a number of times, specifically mobile Safari among others.

  • Alex Says:

    Esteban, we’ve used SmartGWT in one of our projects for bank intranet application. The UI was quite complex and we faced the need to extend standard components. I can support all your statements and add even more:

    1. The “documentation” for SmartGWT is a joke. Several bits are hidden somewhere in the FAQs deep inside the forum. No Javadocs at all. When you have to put many untyped values and keys to the map in Java code (wow that is not like it is advised to be done in Java!) and then it all will be passed to Javascript part and there is no any description of what can be put into there – this may become a problem.

    2. I’m used to established frameworks like Spring, which consist of pure Java code. When the excellent documentation and Javadocs are not enough, I go dig into the code in debug mode and see what’s the problem. We had several major problems with SmartGWT related to bugs in their code or just lack of documentation and debugging the Javascript code of SmartGWT is a nightmare.

    3. Because it was intranet app we had strong requirement for application to be able to run in IE7 – the only target browser. You couldn’t even imagine how many tricks are put into SmartClient/SmartGWT code to overcome IE6/7/8 incompatibilities with other browsers. I appreciate the work done, but when you just want to run in IE7 (not in IE6), everything that is more than 2 buttons and 3 fields will hang as hell in this browser. Sometimes it doesn’t work at all in IE. I had to go to the Javascript code and remove many IE tricks just to allow the application to work in the target browser.

    4. When you want just use 2 buttons and one autocomplete box from SmartGWT library, you have to include several megabytes of Javascript. Guys, are you serious about this?

    5. SmartGWT versions always are not recent. Sometimes there is a major bug in Javascript (we’ve seen this a few times), it is already fixed in the new version of SmartClient, but there is no appropriate version of SmartGWT. To have recent SmartClient Javascript with a bit older SmartGWT you have to include all those huge Javascript files yourself on the page. In this case again, nobody would tell you the order in which the Javascript files should be included and which of them you actually need for your application. I personally spent a couple of days just mixing several JS files in different combinations and checking if our code still works with such combination.

    6. You can extend a component only when you read the Javascript code. If you couldn’t use the components in your usual code because of lack of documentation, then sure to extend the component you must know how it works EXACTLY. And this is not understood from the Java wrapper part at all. Furthermore, I spent quite a bit of time trying to extend in Java one of the 2 combobox components (another one was just simply not working) and ended up extending it in Javascript. Suggesting to extend it in Java is like suggesting to extend any Java class, but without seeing any of its fields, half of its methods, having all the rest of methods just as wrappers over something else and not understanding how it works (and not even having any source of information to understand that).

    7. All frameworks have bugs, even the most established ones, this is OK for me. But when you faced a bug in SmartGWT – you are in trouble. First of all, you receive no message about the issue at all. It just simple doesn’t work. Then you understand that this can possibly happen in Javascript part. Then you find out that you have to enable Debug mode for SmartGWT’s JS part. After that you see a big dump of Javascript code in an alert and still no message in browser console. Then you dive into the Javascript code, search for something similar to what you’ve seen in the alert and if you have luck, then you can even find it. In case of no luck, you have to review the functionality in Javascript step by step, putting your own alerts in their code until your next alert won’t show before error. Here we are! That is our desired string with bug, a line before the alert. This is so different from using pure GWT.

    In conclusion, when you don’t have big budget – use plain GWT. It might be very easy to extend default widgets and you can apply any styles you want in acceptable time. I personally had very exciting experience with GWT’s default widgets. They are customizable and extensible in all ways.

    • Esteban Robles Luna Says:

      Hi Alex,
      Thanks for taking the time to give all these details. I agree with all your points and add some comments below.
      Would you mind adding them to: http://www.dzone.com/links/why_i_give_up_using_smart_gwt.html?

      1. I agree that this could be an issue but I understand that it is really hard to keep it updated. That’s the main reason why debugging is extremely necessary.
      2. I faced the same issue regarding the Calendar field and that was another point where debugging would be really important.
      3. To be honest, I didn’t had the chance to try my small app in IE 6/7 :)
      4. Agree
      5. I’m not sure, but if you are a customer do they provide patches to previous version? I guess so, Charles could you confirm?
      6. 100% true and I’m totally agree with you. It’s impossible to extend by subclassing without knowing how it behaves internally. If you extend by composition it would be ok if the interfaces of the classes are well documented and behave as expected (which is not what happens in reality).
      7. We are definitely in sync. Another path I tried was this one by changing the dependency to SmartGwtDebug in my GWT module and I see an alert when the page loads. It makes it completely unnatural and really hard to work with.

      I also had a good experience with plain GWT but as mentioned in the post, I felt tempted to use it because of the cool widgets. The experience helped me as a POC to decide which UI library I was going to use and it last only a couple of weeks.

      • Alex Says:

        Sure, np. Can you somehow do this automatically or should I just copy it there?

      • Charles Kendrick Says:

        Alex, sorry to hear about your bad experience, but the problem for you was #5. You should never ever mix SmartClient and SmartGWT resources – this is like taking two versions of a .jar file and creating a mixed .jar with classes from each – we all know that absolutely anything could happen from then on.

        This is why it says in bold right at the download page at SmartClient.com: “Each download is self-contained. Do not mix resources from Smart GWT and SmartClient packages”.

        Nor is there ever any need to do this. Nightly builds of SmartGWT are available right at smartclient.com/builds. It’s simply not true that there is ever any issue getting the latest code.

        Everything else you complained about stems from this one huge mistake:

        1. you must have run into all kinds of problems that you thought were bugs, but wouldn’t be reproducible by anyone else.

        2. you had some IE6/7 problem – in reality there are no such problems – see our forums – no one reporting anything like this

        3. you broke error reporting – in reality any JavaScript error leads to a nice clear stack trace in the Developer Console and in the Eclipse console, a very valuable feature – but mixing resources from our two different products would prevent this

        4. you couldn’t extend components in the normal way – mixing resources from our two different products would prevent this too

        5. because normal extension didn’t work, you would be looking in the documentation for information that you normally would not need. In reality, our JavaDoc routinely receives compliments and the volume of documentation there is longer than the bible, but if you’ve broken the normal, correct approach and are looking for a hack, of course that won’t be in the docs.

        6. again because you’d broken the normal extension mechanism, you went off and tried to hack the JavaScript – everything went even more wrong from here.

        We’ve basically got a couple of people complaining because they *assumed* they would need to hack JavaScript to get something done. In reality this is never required.

        There are very simple best practices with SmartGWT, very very prominently documented and in multiple places. As long as you stay within the best practices, you’re going to have a great experience, just like our huge community of developers, just like our long list of name brand customers.

        • Alex Says:

          I have never mixed SmartClient and SmartGWT on the same page. That would be stupid :) All your arguments are based on this ill assumption that I mixed them, so everything you said in your last post is just not relevant.

          What I really did is I tried to use the usual version of SmartGWT, found major roadblocking bugs in it, then understood the bugs came from Javascript part. After that I replaced SmartClinet files in the SmartGWT bundle with the most recent ones, and really some bugs disappeared. But some left. So this is not me doing something wrong, if bugs can disappear when I just change JS part. The second thing that I tried was using the night builds of SmartGWT and that also didn’t change anything to better. It is difficult now to remember what exactly was wrong, but I remember for sure that me and my colleague spent huge amount of time just fighting bugs of SmartGWT, then fighting absence of documentation, then fighting absence of extensibility, and so on down the list.

          BTW some of the bugs are reported by many people on the forum (for example, one of the combobox widgets is reported to be not working and it is advised to use another one). Also I wonder if somebody has ever tested the library under Internet Explorer, because there it works especially bad (or does anybody test this library at all?..)

          Also if we speak about your code, do you think freaking 14255 lines in http://code.google.com/p/smartgwt/source/browse/trunk/main/src/com/smartgwt/client/widgets/grid/ListGrid.java is ok? How do you suppose anybody understand this?

          It’s very good that you have so many time to defend SmartGWT library. But I would rather put this time and efforts to fix all the major bugs in the free version. Currently it is not usable in any serious project. And even after that, again, I would say the idea to have a very thin Java wrapper around a huge piece of Javascript is very, very bad idea and I would not advise anybody to do this.

          • Charles Kendrick Says:

            Alex, thanks for confirming that you mixed resources from our two products. Once again that explains all of your difficulties from that point.

            You make a vague mention of encountering some bugs before then, and you recommend that we focus on fixing bugs..

            But, you have not actually reported even a single bug.

            At this point it is not clear that you ever encountered a bug at all, vs simply made mistakes in your code. It is very common for developers to believe they have encountered a framework bug, but ultimately trace the problem to their own code.

            In reality, we are extremely aggressive about fixing real bugs that have clear test cases, and for this reason, many people have commented about the extremely low number of bugs in our releases, and our issue tracker consists almost solely of enhancements, not bugs.

            Given that we have 400 samples covering a huge range of use cases, almost 2000 automated tests that run every time a developer commits changes, and a huge number of developers who try out nightly builds every day, it’s easy to see why we enjoy such a high level of stability.

            If you’re going to assert, in contradiction of so much highly visible evidence to the contrary, that our product is riddled with bugs – then where is the proof?

      • Charles Kendrick Says:

        Esteban what an astonishing thing to say!

        “It’s impossible to extend by subclassing without knowing how it behaves internally.”

        This violates the fundamental computer science principal of encapsulation, which says that you shouldn’t need to know about the internals of a class to use it.

        It doesn’t matter whether you extend by composition or by inheritance, encapsulation still applies.

        It’s extremely important to avoid relying on internal details because they are not guaranteed and will change over time. This is why it’s so important to *read the documentation* rather than use a step-through debugger to try to discover a class’s behavior.

        Like all SmartGWT widgets, the ComboBoxItem was designed with extensibility in mind. There are many extension points with documentation that spells out exactly what to expect and how to use the extension point.

        The only concrete extension scenario that’s been discussed is calling a GWT-RPC service. This is well covered by the existing extension points, can be done in straightforward, pure Java, and does not require knowing anything about the internals of the ComboBoxItem.

        Yet in trying to tackle this scenario you somehow ended up assuming it involved JavaScript changes and repackaging .jars etc, none of which is true.

        It’s becoming more and more evident that the issues you had stem from a fundamental assumption that you should dig into the internals of any class you use rather than consider it’s documented extension points – but this is bad practice with *any* software framework.

  • Esteban Robles Luna Says:

    Hi realvalkyrie,
    I understand the issue but that lowers the level of abstraction a lot. I guess that if the guys from the Google Plugin add some support for JSNI invocations everything would be much more simpler

  • Ivan Says:

    How does anyone expect to code javascript without coding javascript? The world thinks that javascript is a simple layer that can be removed, but its not, for exactly the same reasons that everyone hates learning it – which is why you have to learn it.

    • Esteban Robles Luna Says:

      Hi Ivan,
      I guess that your point is that JS can not be removed and that’s true. GWT’s purpose is to raise the level of abstraction (which I agree for 80 or 90% of the cases). For the rest you can always code in plain JS.
      I also know how to code in plain JS and makes me remember my days with Smalltalk though the differences between the paradigms (prototype and OO). However, sometimes it is much faster and simpler if you use GWT.

    • Jon Says:

      Ivan, actually javascript knowledge is not required to do GWT development. I’ve been involved in numerous GWT projects and I can count the number of lines of javascript on my hand.

  • Roger Says:

    I really dislike disparaging open source projects.. but lets be clear here.. SmartGWT blows.

    Now.. it is agreat.. the first 5 hours are great.. maybe even that first week is great.

    but anyone who builds a large, long term “GWT App” with SmartGWT is drinking straight poison.

    Stay away, don’t waste your time or your companies money.

    • Alex Says:

      Couldn’t agree more. My feelings were exactly the same as yours and exactly in the same order. Cheers.

    • Charles Kendrick Says:

      Roger, given your somewhat juvenile attitude of saying a product “blows” with absolutely nothing to back it up, I have my doubts about whether you’ve ever actually worked with SmartGWT, or are even a professional developer at all.

      However, if you really have any critiques of SmartGWT, you should post them in our forums. It’s quite likely that you have misconceptions about the right way to build things, and just went down the wrong path.

      And finally, if you are building a complex enterprise application, as James points out you may have requirements such as: “locked columns, filtering, grouping and multi-column sort, capturing user grid configuration preference..”.

      Attempting to build such features on top of core GWT as it stands today is essentially tantamount to writing your own, extremely sophisticated grid component from scratch – very conservatively, this is multiple man years of R&D, just for those specific features.

      This is why so many companies building sophisticated enterprise applications turn to SmartGWT.

  • James Wolfe Says:

    Actually my experience has been quite the opposite. In my opinion SmartGWT is the most powerful library out there that is great for building large, long term “GWT Apps” and that is what we have built in our company. It helped us get rid of so many layers of homegrown UI controller and persistence code and we have made significant strides in an extremely short amount of time.

    I have not read every comment here but the general theme of people having a bad experience seems to stem from them simply not having read the Quick Start Guide. It should be a prerequisite for anyone using the library. If a trial-and-error approach is used by scavenging code from various places, then you’re missing the big picture and how to best design the application.

    My 2c..

    • Esteban Robles Luna Says:

      Hi James,
      Thanks for sharing your experience. Did you had the chance to face any of the issues that Alex and I ran before?
      How do you work with the debugger?
      Cheers

  • James Wolfe Says:

    Hi Esteban,
    I went through all the comments. Here are some additional thoughts of mine.

    A little background : I work for a rather big company in B2B space and the application requirements are quite complex, require a rich set of widgets, especially ListGrids and Forms and strong integration with our Java backend is a must. I am not an open source enthusiast looking to build brand new widgets that are not already part of SmartGWT. Our company is willing to sponsor development of such widgets should the need arise.

    In our evaluation SmartGWT out-shined others because it has the most advanced widget set with solid databinding capabilities. For example the ListGrid component has features that we absolutely need like locked columns, filtering, grouping and multi-column sort, capturing user grid configuration preference to name just a few. We could have started with plain GWT, Mosaic, ExtGWT or Vaadin but one must not underestimate the cost of adding these features inhouse using a “pure GWT” library like GWT, Mosaic, ExtGWT or a server side library like Vaadin. It’s just too expensive and build and maintain. We started out app using core GWT so we know..

    It would have been nice if SmartGWT wasn’t a wrapper over a JS library as this would allow people to create brand new widgets (like a Gantt chart) in pure GWT but it was certainly not a deal breaker for us. I have only needed to try to look under the hoods in the JS code on one occasion and for that I inherit the SmartGwtDebug module which uses formatted JS and I can set breakpoints in Firebug, or Chrome Dev Console. On all other occasions I simply post a question on the forum with a testcase and I’m corrected on usage or the dev team quickly incorporates the fix.

    If I were an OSS enthusiast I might have wanted to do a deep dive when I suspect I’ve hit a bug, but being part of a company that cares about building our product, I’m happy to report the bug and have the SmartGWT dev team figure it out and provide a fix.

    Quite honestly I have yet to encounter the issues Alex reports. There were absolutely no IE specific issues that I ran into. I also found the documentation to be very comprehensive. The other complaint of SmartGWT being too large when all a user wants is a combobox is really not valid IMHO because if all he needs is a combobox, then I don’t think SmartGWT is the right choice. If you want to build a larger application where initial size of the one-time download of the SmartClient JS is not a issue, SmartGWT is a great choice.

    Again, this is just my experience based on our product requirements.

    • Esteban Robles Luna Says:

      Hi James,
      Thanks for sharing your experience.
      I agree with you that there should be an analysis regarding the effort to maintain a solution and create a new one. That’s something that Mule’s customers (the company that I work for) also evaluate when they try to build a integration solution. If you have the money to pay for support that’s great, however if you don’t and you need to dig into the code you may suffer Alex’s experience.
      If I had the same context than you, I would also pay for support for sure :)
      Cheers

    • Charles Kendrick Says:

      James, thanks very much for dropping by and sharing your perspective, which is typical of SmartGWT users as a whole.

      Just a note that creating a Gannt chart component is perfectly straightforward in SmartGWT without reference to JavaScript code or any internals – customers have created Gannt charts and similar custom components entirely in Java many times.

      SmartGWT has no special limitations in this area – just like creating a custom component in Swing or any other Java UI framework, you read the docs, use the designed-in extension points, and go.

      • James Wolfe Says:

        That’s good to know Charles. Admittedly I was guilty of just assuming that creating a complex component like a Gantt Chart would require more extension points but I never did try it. It would be great if a non-trivial *new* component can be written in SmartGWT alone and open-sourced to put such claims to rest.

  • James Wolfe Says:

    oh, I didn’t know you worked for Mule. I perused your blog and it has some interesting articles. Subscribed to your RSS!

  • Jeff Says:

    I tried SmartGWT too… to say I hated every moment of using it would be an understatement. I couldn’t figure out what was going on. It felt way too much like coding against a black box and trying to understand what is going on when you dig in and all you ever get are jsni wrappers made me insane.

    • Charles Kendrick Says:

      Hi Jeff,

      It’s funny, we just don’t get criticisms of this kind on our forums, via email, etc – indeed a lot of the feedback we get is users amazed at how easy it is to use SmartGWT.

      Anyone can verify this for themselves by simply going to our forums: forums.smartclient.com.

      As it stands, your comment looks like a competitor trying to do a little product bashing (we’ve caught them red-handed at this before).

      Apologies if that’s not the case here – constructive criticism is always welcome, as you can see from our forums, we address any reasonable criticisms, and quickly.

      • Jeff Says:

        Why would I bother to post on your forums that I despise pretty much everything about your product? That seems like a waste.

        I find it impossible to believe that you don’t get critisisms about it being like coding against a black box. That is exactly what it is. JSNI wrappers all over the place.

        I have no competing product. I’m using straight GWT widgets currently for our product, and I am able to debug and figure out what is going on always. With SmartGWT, I just have to trust. I tried reading your documentation, but didn’t gleam anything all that useful out of it.

        I didn’t see any reason to log into your boards just to flame your product. What good would that do? I hated all of the choices you made and because of that decided to roll my own instead of using your product.

        I would imagine there are a lot of other people who feel the same way. People who don’t like a restaurant just don’t go back. I don’t like the “food” you’re serving, so I decided to stay home and cook my own.

        • Charles Kendrick Says:

          Jeff, when a real, professional developer reviews a product, they will indicate that they liked some things and disliked others.

          There are so many amazing things about SmartGWT which people compliment all the time, from the skins to data binding to feature depth to just specific features they love, that even when you find someone who had misconceptions that led to a bad experience (like Esteban), they’ll *still* admit that there are great things about the product.

          So I’d like to give credence to your post – but it just doesn’t sound real, sorry.

      • Brandon Says:

        Easy to say when you remove all of the bad posts from the forums…

        • Esteban Robles Luna Says:

          Hi Brandon,
          Sorry but I had to remove the previous comment as it was offensive. We are all trying to give our feedback about SmartGWT and in some way helpinh its community (I hope you understand).
          Thanks for providing your feedback
          Esteban

  • Mark Says:

    My development team has built 5 medium-sized, non-trivial corporate web applications with Ext-JS and Ext-GWT since 2005. In 2010, we built a 6th using SmartGWT.

    Our experience has been this:

    From the very first project, when using Ext-JS or Ext-GWT things went quickly and smoothly. Things snapped together and the pieces and parts fit well. They worked in an coherent way. The API was narrow. The framework design coherent and complete. When we needed extend something, fix a bug we found, or just build something entirely new, “it just worked”.

    The documentation both in the code and online was entirely adequate to guide us. We rarely, if ever visited the forums – just did not need to go there — nothing was ever so serious that we could not easily figure it out ourselves in 15-30 minutes.

    SmartGWT has been challenging to use. After almost 8 months now, I’d say we’ve never experienced that same ease of development. While we’ve successfully delivered a system, it was not smooth nor quick. The application we built had similar complexity and size as the other 5 and yet took about 3x as long to build.

    Why? In my opinion, its because of the EXACT same issues raised by Alex and Estaban.

    Ext GWT just works in that Apple sort of way. With SmartGWT you still get there, but you look back and say “I know it does not have to be like this”.

    • Charles Kendrick Says:

      Mark, when using a new product you should expect an initial ramp-up, and if you are familiar with another products’ design, its easy to dislike a different design, even if it’s superior.

      If your anecdotal note has any more meaning than this, I’d love to help identify why you had trouble with our product where so many others are succeeding, but of course there are no details at all..

      This blog has attracted a curious number of anonymous, first-name-only posters who complain in entirely non-specific ways about a product that enjoys wide adoption all across the globe, and which attracts all kinds of positive feedback on a daily basis.

      But in all of this, not one concrete bug, missing feature, or limitation of the product has been identified.

      If there’s any *real* feedback available on what could be made better in SmartGWT we’d love to hear it. We’re constantly improving all aspects of the product based on user feedback.

      In the absence of such feedback I have to give more credence to what I know for sure:

      1) when you have tough requirements – as James mentioned “locked columns, filtering, grouping and multi-column sort, capturing user grid configuration preference..” – then it is just not feasible to build such an interface in any other GWT technology. It’s going to take far longer just to replicate those features than to build the whole app in SmartGWT.

      2) you can see the tremendous volume of public feedback we get from real users here: forums.smartclient.com. You will see lots of positive feedback, rapid resolution of reported bugs, people making good use of our diagnostic tools to figure out issues, etc. This is the reality of SmartGWT development – see for yourself.

  • Reply to Comparing Java Web Frameworks « henk53 Says:

    [...] Why Google Web Toolkit Rots Your Brain Google Web Toolkit Follow-up Why I give up using SmartGWT (not GWT itself, but popular extension) Addressing Misconceptions about Google Web [...]

  • Michael Wallace Says:

    Hey there , I am making a popular forum and I think some of your articles would fit the context good. Am I allowed to copy your article?

  • Harry Says:

    For me, one of the biggest reason for giving up SmartGWT is their support. Just browse through 20-30 posts on their forum and you’ll know what I mean. People are outright humiliated, especially those who are using the LGPL version (and sometimes even those who’ve bought licenses). There’s no such thing as courtesy on their forum. I haven’t had a bad experience personally, but from the way I’ve seen others being treated on the forum, I refrained from posting anything to avoid risk of getting the same treatment.

    If a company doesn’t treat its customers properly, I would not give my business to that company, no matter how good their products are.

    Now Charles Kendrick can go on and on, but the truth is evident in their forums. You just need a neutral pair of eyes to see it. Perhaps the time he’s spending responding to the comments here could be better spent on introspection.

  • Fairoz Says:

    Hi Harry,
    I totally agree with you, I am using the licensed version of smartGWT but now my company feels we have wasted our money. There is no support/reply from the admin of the forum, Its a big trap from these people, even if you buy the licence they will not reply to your queries so that you will be forced to buy their support.
    A BIG NO to SmartGWT.
    And Charles you continue defending yourself we don’t give shit to that.

  • Harry Says:

    Fairoz,

    My observation is the same. I’ve seen people who’ve purchased licenses, literally begging for help on the forum. Sometimes, they are outright snubbed.

    Their forum is not to help people, but get people to help them for reporting bugs. Another unfortunate thing about their forum is that it’s not community driven like most other forums for open-source software. The atmosphere is built such that there’s hardly any member-to-member interaction.

    IMHO, it’s not a “support forum”. It’s more like a issue reporting system where you report problems, and if you are lucky, you may get a response back.

    It’s a shame that companies operate on such models.

    It’s good that this thread was started. The skeletons are starting to fall out of the closet.

  • Marla Barkley Says:

    My my! what a collection of feedback. despite the writings of Charles SmartGWT, I have my vote against anything smartgwt. it sucks. I have worked on these things and plain old javascript (jquery etc) for 5 years now. I have not seen a more bloated API than smartgwt. like someone else said, its great for the first few weeks, then it just falls off a cliff. if you are building something long term and know that your users demand very accurate compliance to requirements, smartgwt is a VERY BAD choice. Its best to go with GWT alone and have a graphics engineer build the fancy imagery and css for you. As developers, all these packages are great tool. Further, if your users are not too demanding or are on an intranet where they come for submitting service requests and such, this is all great. If you have a public facing web app, dont bother with any tool. build straight from GWT. Charles notwithstanding.

  • Brandon Says:

    I feel compelled to put my feedback here. Let me start by saying that I have been using SmartGWT 2.5 and 3.x for almost a year now. I have lost my love for programming as a result. The solution is half-baked at best, and members of my team find bugs on a weekly basis that are corrected in the nightly builds.

    Charles oversold this product to our group. We needed or thought we needed to move away from Flash. Big mistake. We should have used JQuery or Ext instead. The number one complaint I have about this framework is what they use as one of their strongest selling points. Datasources. You will wish you never, ever, and I mean EVER laid eyes on this API. You have to jump through hoop after hoop by letting them manage your data. Something that easy to accomplish RPC and arrays in every other framework I’ve worked with takes 10s of lines of code to accomplish in SmartGWT.

    Let me address my half-baked comment. Every widget looks cool, great, slick on their showcase. But they’re simply showing a few common uses. Try to do anything outside of the normal use case for something like a combo box (like have one in a DynamicForm and not tied to a datasource) and you’ll be sorry you tried.

    Charles seems to always have a comeback, and it would be nice if he spent as much time answering questions on the paid-for support forums as he did defending this monstrosity.

    If you’re curious in SmartGWT, heed my words. Stop now and keep moving. You will thank me for it, and if you end up using it. You will be back here on this thread posting that we were right. Keep your sanity and your money, stay far, far away.

    • Charles Kendrick Says:

      Brandon, if you think the DataSource architecture is fundamentally flawed, I have bad news: everyone is copying it. You are doomed :)

      In all seriousness if you track the last few releases of ExtJS, Dojo, YUI etc you can see them hewing closer and closer to our architecture. I wouldn’t go so far as to say it’s direct copying, but when a prospect arrives and says “why can’t it work like this?” because they’ve just seen one of our samples.. well you can see what happens next.

      The reality is, the DataSource architecture is what (rightly) attracts people to our products, and is what they love about it.

      If my guess is right about which group you’re with, you’re in the midst of a JPA nightmare unrelated to our products – and you got there because you directly ignored our (repeated) best practices advice.

  • Gomes Says:

    That’s truly the worst framework I’ve ever worked.
    Brandon os absolutely right, I would prefer work directly with JS. On the notepad. On a 166mhz computer.

  • Davide Cavestro Says:

    I agree with James Wolfe.

    I choosed SmartGWT some years ago and I have to say I’m happy with it:
    * they surely have a bloated api
    * maybe their support is too strict with careless users on forums
    * I’d certainly prefer if it was not a wrapper over a JS library
    * and yes, as every software they have bugs 8-|

    But once I’ve recognized Client datasources and nice widgets could be very useful to me I adopted them (btw is there any competitor providing a feature set comparable to ListGrid?).
    Having requirements that left me some freedom, I’ve always found a way to workaround SmartGWT bugs/limitations.
    I’ve used the LGPL version and implemented the server side with Grails and REST (jaxrs). This way SmartGWT does what I feel it is definitely good for: a nice and REALLY COST-EFFECTIVE ajax user interface. I’ve never tried the server side part.

    I guess various disappointment for SmartGWT often arise from misconceptions: if you are looking for a silver bullet don’t use it. But once you understand the nature of SmartGWT, it’s worth it for several scenarios.
    I’d surely do it again… in fact I’m going to use it again :-)

  • toni Says:

    I’m going to start my first GWT project and I was wondering whether to use SmartGWT or not… Thank goodness I read this post!

  • Timothy Says:

    I was reading some forum posts at Smartclient.com and there are some unhappy users there. Presumably this Charles person answers the posts. His answers are condescending and vague… My vote is ExtJs or Jquery. No thanks SGWT.

  • Daniel Says:

    Hi started using smartgwt 2 years ago and I think it is a great product, however I had some issues:
    1.-I never got answers from some post in the forum, I created small reproducible test cases as they said but never got an answer.
    2.-Forget about fixed position in smartgwt, you can’t have a fixed position layout
    3.-Flash.- I used the google maps api for gwt and I had a lot of problems with street view, no click on chrome and safari when showing the StreetviewPanoramaWidget inside a Smartgwt Window

    • Charles Kendrick Says:

      1. can you provide links? If these are bugs in our product, we’d like to address them.

      2. if you mean CSS position:fixed, yes, there are too many browser bugs to recommend using this directly, but you can accomplish the same thing with our layouts very easily.

  • Csaba Says:

    Smargwt is a great product, if you strictly use the documentation, forum and best practices. If you want to follow your own head, you will be failed. Best advice is first learn and adopt the way of smartgwt thinks. It was not easy, but after couple of month, I’ve realy used to it, and really like it.

  • AMcCulley Says:

    Work for a very large company with a multi-million dollar enterprise app being developed for some clients. I’ve been working with SmartGwt for a little over a year now.

    It isn’t perfect but I have to say it is pretty awesome. We have written tons of custom widgets, integrated FontAwesome from Twitter’s Bootstrap, used 3rd party charting apps like High Charts, etc. We’ve had a couple of hiccups but it all works.

    The datasources are awesome – it is a very flexible and customizable approach to data access. We’ve even extended this with our own attributes – we can do so much without changing any code.

  • André Pietsch, SCAI Says:

    We are working with SmartGwt for several years now. We had some very big problems but most of them turned out to be caused by our design. There are still some problems but I’ve worked around them and did not open a bug report, yet. Take this as a measure of how big the problems and the workarounds are.

    It is surely a huge library and my feeling is that it takes a while on slow systems to initialize, but I honestly never profiled it.

    Two major advantages of SmartGwt have been stated here already:
    * Feature rich components like ListGrid: These are really powerful. It’s like Word: You almost never get to use more of 5% of the functionality it provides (meant as compliment in this context :) )
    * Data binding: The Datasource concept is implemented in a really great way. I integrated it all against a Grails-GORM-based server solution using a (heavily) extended GwtRpcDatasource and I can now support SmartGwt-based filtering and sorting from the client side through to Grails-GORM-projections. This is really cool.

    Honestly, I thought many times about giving this piece of code back to the community, but my fear is, that it would hurt the business of the SmartGwt-guys since they get their money from selling the enterprise suite which provides the server side integration as one major selling point. If there would be a solution to combine SmartGwt against Grails I fear it would hurt their business model too much, and I do not want that.

    SmartGwt has its problems like any other framework I used in the last two decades I used in programming but it is not in the way that it is unusable. And: The only recommendation/best practice I found out that could be ignored is the one to not GWT-RPC. I only rely on exactly this mechanism and get good results, even though I had to code the whole server integration myself (this was due to migration from a Grails-only solution, where a lot code was implemented already).

    Regarding all other best practices: I learned that I need to follow them :)

    As with most big frameworks: If you do not use one of the major architectural advantages, you might be better off using something smaller. Surely SmartGwt’s advantages are not resolved by having a designer adding fancing graphics stuff to GWT components. The datasource binding concept was the main advantage for us, that we decided to use it.

    About the tone in the forums: Yes, inpoliteness or harshness is not so seldom there, but more than often the question was stupid, incomplete, or RTFM-related. But, yes, I noticed answers in a questionable tone to questions where the previous criteria did not apply, too. This is the internet: It never forgets, even if you have a bad day, and we all have one from time to time. However I have the impression (and as an impression it is not proven by any measurement), that some questions could receive a more detailed answer. But I got this impression in more forums than in SmartGwt’s forum and most of them it is worse than there.

    We have still some workarounds there because setting components to read-only does not work the way we expected it to work. Also, data paging in listgrids and unexpected DataArrived events caused us some headaches (we might not have had these if we used the SmartClient Server, though I doubt it). We worked around them.

    To sum it up: I want to give a positive feedback on SmartGwt here. We had negative and positive experiences. The positive ones outweigh the negative ones. I never used a product where I made only positive experiences. I used products where I had more positive experiences. And: I did not take into account that my company did not pay a single dollar for SmartGwt, since we use only the LGPL part of it. If I would take this into account, it surely would not change my statement to the negative :)

  • SmartGWT Customer Says:

    If the company doesn’t treat its customers well, it doesn’t matter how good its products are.

    • SmartGWT Customer Says:

      That’s not to say that I’m satisfied with the product either. The support is extremely horrible and rude. Go check their forum for yourself.

  • Warren Says:

    Painful to try to get a comboboxitem working with a datasource. 3 hours into it, not luck yet. documentation is lacking. Use showcase supplyItemId as basis, which is overly complicated itself, I think to show you all the bells and whistles or something. Keep getting blank combobox.

  • DavidA Says:

    I’m using SmartGWT extensively since 2 years.

    At the beginning, it was very hard to understand the server part and they fixed many bugs on the client widgets, but very quick.

    We also had to extend the client and server part with some fundamental functionalities like i18n, security and performance boosts.

    Today, we have the experiences, and we benefit from the concepts a lot of: data-bound components,
    rich ListGrid API, flexible generation and extendability of the server part and the bugs went almost down to 0.

    I think the problem with the forum are missing examples in the showcase and to frequently extend the documentation, to prevent people asking the same questions all over( I want to see more, without static mock data).
    So many people are asking the same questions all over and Isomorphic is tired to reimplement and try to reproduce for every single question.

    The fact that SmartGWT wraps JavaScript leads to the fact, that you will/should never debug to core JavaScript and to rely on their API, but to make Isomorphic solve it. The code you’ve written, is easy to debug – no difference to GWT.

    @Kendrick, if you’re interested I can share some ideas of the extensions about the SmartGWT framework, we’ve implemented.

    • Charles Kendrick Says:

      Hello DavidA, sure, we would be interested in your extensions, however, it does sound like you might have jumped in early, when these areas did not have the extensive solutions and docs we have today.

      For example, 3.0 radically simplified server-side DataSource i18n and added a huge i18n overview doc. 2.5 introduced a Declarative Security subsystem for role-based security, which was further enhanced in 3.0.

      We are constantly adding new samples and docs, and I should point out we *already* have approximately double the samples of any competitor.

      Finally, our Showcase for the LGPL edition doesn’t use mock data, it uses DataSources, which is a key distinction – DataSources can be swapped with any other DataSource that provides the same records, without changing UI code.

      If you want examples of connecting DataSources to various providers such as SQL, Hibernate, JPA or WSDL services, there are many, many such samples in the Pro/EE Showcase here:

      http://www.smartclient.com/smartgwtee/showcase/#main

  • Matthew Weiler Says:

    I just wanted to give some feedback on my experiences using SmartGWT.

    Starting about 2 years ago, for about 1.5 years, I was working with 3 other developers to create 2 fairly complex enterprise applications using GWT & SmartGWT.
    The reason it took so long wasn’t because of SmartGWT but rather the users kept demanding new features and they always got their way… it was infuriating.
    At the beginning of the development cycle, we were very impressed by the complex components that one could build with very little time.

    In order to get the client-server communication that we wanted, one of my coworkers developed a JSON based communication wrapper which could be married with a ListGridWidget (extending ListGrid); this made developing data grids ridiculously easy and fast.

    After the ListGridWidget we began created many shared components which we used between the 2 applications.
    Shortly thereafter I discovered that we could JAR our shared components and simply import them into each project that needed them, this made for the development of shared components again very fast and transportable.
    We always knew JARing of components was possible but it’s another thing to figure out how to do it :)

    Not everything was perfect however, when developing complex components they were often plagued with exceptions (only in IE) “error at line 0″. We discovered that these issues were due to too much Javascript being executed at a single time, and IE can’t take too much :(
    Since our users were all in-house, we also modified their registry settings to allow IE to tolerate longer instances of Javascript execution.

    To work around these issues we had to make a lot of the cleaning-up of complex objects asynchronous; we’d overwrite the destroy() method and make the whole destruction process asynchronous using timers to ensure that not too much Javascript was being executed at any given time… IE can’t handle much at all.

    Another down-side was the debugging; granted we could debug (using Eclipse) the client-code but that stopped when we hit the Javascript internals; the black box that everyone is talking about. But all things considered, it wasn’t a deal-breaker.

    After we delivered the final applications we had mixed feelings about SmartGWT; we all agreed that it allowed for fast development of complex components, but debugging issues can be very time consuming.
    Also, some of the SmartGWT components don’t act like you’d expect them to and aren’t all well documented, this forced us to created more custom components, extending SmartGWT components, than we would have liked to.

    I would say that SmartGWT is certainly a great contender in the are of pretty GWT frameworks, but certainly not perfect.
    It does take some time to get used to it, but once you know what to expect it’s fairly decent.

    If you’re developing a smaller-medium complexity application I wouldn’t use SmartGWT but for larger complexity applications SmartGWT is a decent choice.

    I recently left that company and began working at a new one; they also use SmartGWT and I’m not upset :)

  • Trevor Hastings Says:

    I used SGWT for two years, and had mixed feelings. I even bought support and thought it was decent. The responses were rude or “canned” at times- “read the QuickStart” got old, but sometimes they were right. Other times they were pretty fair, and fixed bugs in the product.

    Then I started exploring other technologies, and I realized that SGWT is really for people who hope to source a lot of work they would normally have to do to “The Experts”. At least in my case, I was hoping that I could rely on the farmework to solve things like drag and drop, data access, layout etc.

    SGWT does this, and in some ways they do a good job, and in some ways, one could argue they fall short (CSS, customization for example).

    The approach that works best if you end up using SGWT is to be honest with yourself from the start. If you don’t REALLY know java web development, go with their advice. They built the framework, and they know best when it comes to its use.

    If you have experience with hibernate, spring, struts, etc. venture out a little, but don’t fight the framework. Use it like you see it used in the showcases, and learn the API. And of course read and re-read the QuickStart.

    You can accomplish some cool stuff in SGWT, but realize and accept that you are committing to working within the constraints of someone else’s paradigm. If you do this, you’ll find a powerful tool. If you don’t realize this, you’ll be discouraged and frustrated.

    If you’ve made it to post, you’re searching for a way to develop web applications that . Evaluate SWGT, but check out Grails, Twitter Bootstrap, Backbone.js, Knockout.js, Angular.js, Node.js, NoSQL databases, and all the the templating engines, and of course, JQuery.

    These are the direction the web is going, and they have many benefits, as well as challenges. Put together they are pretty awesome, and can be combined to create something not achievable, or at least easily achievable in SGWT or other Similar frameworks.

    Think about who you want in charge of your project. And if you are okay working within the boundaries of SGWT, go with it. It will serve you well. If you want more flexibility, check out some of the newer tech.

  • firebet Says:

    I found this article quite an interesting read. We adopted SmartGWT for a number of projects about 2-3 years ago. I come from a Struts/JSP/Servlet background but have used JQuery and Dojo/Digit in the past. I think the first thing to note is that SmartGWT is a full framework, make no mistake, so trying to splice other technologies into a comprehensive framework will invariably lead to problems. e.g. Mixing GWT/SmartGWT widgets into the same app = bad idea. The documentation does make this clear. I found the concept of DataSources took a while to get used to, but like any reasonable developer, I read the available documentation, looked at the showcase examples, read the forums and experimented with code to figure out what works and what doesn’t. I am now comfortable with what is going on ‘behind the scenes’ but it took a while to understand and adjust my code to fit the framework.

    In terms of the comments about the SmartGWT forum – I’ve read all the comments on this article and I recognize some of the posters from their forum posts. I agree that in some cases, the forum moderators have responded negatively to some posts, but generally this is in situations where either the poster has not included the required information in the original post and then got angry at the lack of response, or have not read and understood the available documentation or the moderator’s response (‘understanding’ being key here!) It goes both ways, rudeness begets rudeness – some of the posters have been quite rude in their approach to asking questions. Slagging off the framework probably won’t get you a polite response from the developers who created it! However if you reference the documentation and post example code, you generally get a helpful response. In my personal experience, most of my problems have stemmed from simply not understanding the framework well enough. The API is quite vast and the learning curve can be quite steep depending on your past experience. I have spent many hours pouring over the many possible method calls on the various widgets to figure out what settings to apply in order to achieve desired functionality, but I have always found a solution to any issues I’ve faced to-date – sometimes through the forum, but usually thorough personal experimentation with the API. Of the posts I have submitted to the forum I have either received a helpful response, or figured it out myself before a moderator has responded (and posted my own findings to help anyone else hitting the same issue).

    WRT the product itself – I use the Pro Edition, including server-side DataSources. I have built quite sophisticted-looking applications in fairly short timeframes that would have taken much longer using older servlet/JSP technology. The majority of my use has involved developing a pure SmartGWT GUI using the majority of different widgets available and tying them into DataSources that make calls on traditional DAOs. I have extended various widgets in order to provide custom functionality in my apps and this has worked quite well. We don’t use any persistence frameworks so I can’t comment on integration with Hibernate or JPA. But once I became familiar with the ‘magic’ behind DataSources I have found them to be quite straightforward to work with – although it has taken some time to get truly comfortable with how and why they work the way they do, then developing my own server-side design patterns in order to make best use of the available API. I concede that I am probably not building the most complex systems out there but on the whole, so long as you don’t ‘stray-from-the-path’ the framework works pretty well.

    What I would like to see are more ‘best-practise’ seminar video’s/examples. The showcases are useful, but what would really have helped me would have been things like: In servlet technology you would probably do X but in SmartGWT this concept is now irrelevant and you might approach it like Y. Perhaps this is too vague and wide-reaching a topic, but I had to figure a lot of this stuff out on my own and it did take a while in some cases. For Charles Kendrick – have you considered posting a full working example EE application online highlighting as much SmartGWT ‘best-practise’ as you can? Perhaps comparing approaches with other frameworks? This might help developers migrating from other technologies. The showcases are very useful, but you’re often left to fill-in-the-gaps in understanding yourself and the complex requirements of enterprise-systems often go way beyond the showcase examples.

  • Paul Says:

    I have been using SmartGWT for some time now and I have never used a technology that frustrates me so much! If its not not debugging plugin tools or the layouts, or bugs in the library that causes problems its the time having to spend on trying find the errors that get reported by the eclipse plugin. Which by the way are then different for production mode!!!

    If anyone ever asked me to use the technology again, or asked me would I recomend it I would have to say no! it does not make life easier in the long run.

    With all that said and done yes it has lots of capabilities from its rich component library (which are sometimes a real bitch to style again by the way as there is no control over what they have hard coded in widgets themselves!) and it is all type safe. Which is why I guess there is such a need for a technology such as this. But boy, I am and every day get more and more unsatisfied with the library!

    Bring back true MVC architecture where you have control over html. Yes for sure it brings complications and yes it causes bugs as binding/re-factoring was always a problem. But the daily output was better spent on creating a real product.

    never never again please OOOOOOOOHHHHHHH please dont make me do it!

  • sunny Says:

    I’m using SmartGWT LGPL for a production deployed application in a large company, and also on the way with two other applications using the Power edition.

    Having come from gwt-ext some of the SmartGWT features were a blessing. As others have already mentioned:

    1) SmartGWT is a complete solution. Trying to use bits of it (or replacing bits of it with your own implementation) will end in tears. I find most of the time the cause of this is the dev not having a definitive understanding of the SmartGWT way of doing something and trying to do/implement something they already know and understand, and when it doesn’t fit with the rest of the SmartGWT paradigm it’s just a world of pain trying to determine what’s going on.

    2) The SmartGWT showcase does ‘showcase’ many things, but that’s exactly it – it showcases every generic use cases that usually doesn’t reflect real world applications of the widgets. I think a more useful showcase would be downloadable, standalone IDE projects that developers can instantly import and run to see what is happening in specific use cases. Be prepared to make these yourself if you really want to understand what’s going on.

    3) The forums can be a good source of information – if someone has already done what you’re trying to do. I find questions are in two categories: a) the very basic questions that usually don’t get a detailed useful response, or b) the questions with very specific use cases which may or may not get a response. I’ve had reasonable luck on the forums so far with reporting bugs (maybe 4-5 now?) and in each case it was fixed. It was just a little annoying to wait a couple of days first without any response not knowing whether or not issue was being investigated while work was blocked (Isomorphic: even a ‘hey we’re looking at this issue’ message would be good). Isomorphic is definitely looking at well reported bugs on the forums, but actual technical support is another question – as someone has already mentioned, sometimes it feels a bit more like a bug reporting forum than anything else, getting help usually is hit and miss.

    I think its a great solution if you need to develop an data-driven enterprise webapp, but only if you’re willing to invest the time in learning it in its complete form and working within its ecosystem/wallgarden.

  • Charles Kendrick Says:

    Thanks to the last few posters who shared balanced viewpoints based on actual experience. A couple things I’d like to point out:

    About CSS customization: SmartGWT 3.1 introduced “CSS3 mode” in which far more of the appearance is controlled via CSS and there are very very few images used:

    http://blog.isomorphic.com/css3-mode/

    So this has been greatly, greatly simplified. It also provides a nice performance boost.

    As browsers improve, we will continue to simplify the DOM and provide more control from CSS.

    About advanced samples: we have a number of more in-depth samples on the public wiki (https://wiki.smartclient.com) – things like example integrations with specific authentication systems, connecting the CubeGrid to Mondrian, etc.

    If you have an idea for a *specific* sample, please do post it to the forums.

    Finally, about perceptions of rigidity or a “walled garden” – SmartGWT is *extremely* flexible. Most of the time, if people perceive a rigidity problem, they just aren’t aware of a key override point, or they are taking the wrong approach entirely and are reinventing the wheel (as one poster mentioned above).

    Here again, if anyone has a *specific* limitation in mind, we’d love to hear about it on our forums, so we can either explain an approach or, if there’s a real issue, fix it!

  • Dansteve Says:

    A much better framework is sencha touc 2.2

    And is MVC based

    Check it out at sencha.com

  • Zach Says:

    Just so everyone reading this is aware – Charles Kendrick works for Isomorphic (the creators of SmartGWT). Based on this long series of comments and other posts I have seen online (try Googling “Charles Kendrick”), I have to think if Charles or Isomorphic spent half as much time writing code as they do writing lengthy responses to valid criticisms online, then maybe SmartGWT would actually be worth using..?

  • Lola Says:

    There is very little good reason to use any form of GWT anymore. There are several very mature and powerful JavaScript frameworks out there that excel at making enterprise-grade browser applications.

    MVC/MVVM frameworks like AbgularJS, EmberJS, BackboneJS, and KnockoutJs can be used to write pure JavaScript web applications, and you don’t have to be a JavaScript expert to use them.

    Combine any one of those with something like Twitter Bootstrap and JQuerUI or KendoUI, and you have a really nice toolset to work with that costs little or nothing compared to SmartGWT.

    JavaScript isn’t going anywhere, and working directly with it in concert with CSS and HTML is far easier than trying to get GWT or SmartGWT to do what you want it to with your layouts.

    The tooling around JavaScriot in the past couple if years has also matured, and there are so many helpful applications to help developers develop great applications. GruntJS, Yeoman, Sass/Compass are a few. All free and none have the crazy compile and wait time that comes with GWT projects.

    So, there really isn’t a good reason to go with a GWT-based solution these days, unless you are afraid of JavaScript or unless yo really just like writing Java and having it compile to JavaScript for you.

  • Bill W. Says:

    We built verison 1 of our application in SmartClient (not SmartGWT!), and although it worked well, our latest version is using a combination of Angular.js and Kendo UI. Kendo provided angular directives for their full set of widgets so they easily integrate with Angular scopes. It moved us away from pages completely rendered in Javascript to a well structured MVC with HTML/CSS templates where we can use responsive friendly Bootstrap components. In my opinion this combination can’t be beat!

    Cheers,
    Bill

Leave a Reply