Earlier this month, SmartGWT 1.0 was released. SmartGWT is an API for building GWT applications using the SmartClient Javascript component library. SmartGWT was developed by Sanjiv Jivan, the same developer who previously lead gwt-ext development, and subsequently ceased his involvement due to licensing issues.
InfoQ had a chance to discuss SmartGWT with Sanjiv Jivan and get his perspective on the new project, comparisons to gwt-ext, and the plans for the project.
What are the main features that SmartGWT supports?
SmartGWT makes the complete APIs of the SmartClient AJAX RIA platform available in GWT. SmartClient is very different from other Ajax libraries in that it provides not only a very complete widget set, but also handles the hard problems involved in building enterprise applications: not just loading and displaying data, but propagating user changes back to the server, and handling all of the consequences of those changes - server validation and other error handling, cache updates across multiple components, etc.
SmartGWT's data-aware widgets - such as Tree, Grid, Calendar and several others - provide complete end-to-end user interactions like tree reordering, dragging events in a Calendar, which automatically generate appropriate server requests to update data with a simple protocol that's easy to customize. This subject is key in understanding the true value SmartGWT provides and a more detailed introduction can be found here.
A few other features worth mentioning:
- SmartGWT supports live grids that not only lazy load rows from the server on demand, but also lazily render columns as the user scrolls horizontally. Most browsers can't handle rendering a large number of columns in tables and the lazy rendering capabilities of SmartGWT grids makes displaying large tables a breeze without a performance hit. The TreeGrid which supports multiple columns, editing, lazy loading of nodes, and virtual scrolling is also very powerful and something that many applications require.
- Adaptive sorting and filtering in grids is pretty neat feature. When the data is filtered down to a number that fits in the local buffer, additional filters applied by the user no longer results in roundtrip calls to the server and data from the local buffer is used. It transparently reverts back to making calls to the server when the the data required to fulfill the request is not in the local buffer. This makes a huge difference in the real-world responsiveness and performance of enterprise apps, by cutting down on trips to the database and giving users instant responses instead
- Relogin: For applications requiring authentication, if a request is made and the session has timed out, SmartGWT makes it easy to implement a workflow where the user is prompted to relogin and on being authenticated successfully the original transaction is resumed without loss of data or context
What is the primary difference between gwt-ext and SmartGWT?
Besides the obvious difference in the actual functionality provided by each underlying library, in gwt-ext, there a is a fair amount of glue code to "fix" inconsistent API's and funky rendering behavior in ExtJS. In working with SmartClient, everything pretty much worked right away. The widget component hierarchy is consistent and object oriented so a direct translation to SmartGWT worked out real well.
SmartGWT also uses the standard GWT 1.6 event API which is much cleaner and flexible compared to its predecessor. As a result users no longer have to deal with listener adapter classes.
Another important difference is that SmartGWT has the full support of SmartClient where users can make feature requests, expedite bug fixes, get support and training and not worry about hitting a roadblock. Additionally, users have the benefit of a commercial friendly LGPL licensed library. Its the best of both worlds.
Having worked with both ExtJS and SmartClient, how do the two component frameworks compare?
ExtJS is certainly feature rich and looks sharp. It was the reason that I started gwt-ext a while ago when Ext was LGPL. However when working on GWT-Ext, there were a lot of corner cases, gotchas, deferred rendering workarounds and inconsistent class hierarchies in Ext where glue code had to be added to "fix" some of these inconsistencies. For example some layouts allow you to dynamically add new components while a couple of key layouts don't support it. Also another key issue is that a good percentage of widget properties cannot be changed after the widget has been rendered, and in some cases users need to set a property and sometimes they need to call a method to accomplish the same thing.
SmartClient has been developed over the past 8 years and it is extremely stable and virtually bug free. The component model is consistent and it is highly dynamic allowing users to change most properties post-render with the changes reflected immediately. It has significantly more functionality and handles server integration really well. If you browse the SmartClient forums, a few things become quickly apparent:
- You almost never hear that "this feature is not available / supported". Pretty much everything that users request is available.
- The number of bugs reported in next to zero.
- You don't find any unanswered questions.
Another thing that you'll notice if you view the source of the samples in their Showcase is that so much can be done with so little code. A master-detail screen that also sends updates to the server can be written with as few as 10 lines of code when passed a reusable DataSource definition.
Do you have any comments for users on SmartGWT being a wrapper over SmartClient versus being a complete rewrite?
A common misconception that users have is that any third-party library written in GWT magically runs fast, is completely leak free, and renders perfectly on all browsers. As an example a TableGrid written by a third party in GWT from scratch could still perform really poorly, and not display consistently on all browsers. There are obviously several aspects to GWT that helps avoid leaks and such but this does not mean that any third party code written in GWT is 100% leak free. What actually matters is that the framework code is well written and carefully tuned and well tested.
The reality is that SmartClient is fast and stable and provides an excellent base for SmartGWT. In fact, in my experience, SmartClient actually does a better job of solving browser inconsistencies than pure GWT third party libraries. SmartClient offers an accurate and consistent cross-browser layout with an object-oriented skinning system that doesn't require deep CSS expertise or knowledge of browser quirks.
In May you blogged about your decision to step down from the gwt-ext project due to the controversial licensing changes with ExtJS. How has that decision been received by the community?
The community has been very understanding and the other team leaders of gwt-ext have also stepped up and done a great job. Most importantly the community that really grown and its great to see users helping other users.
I've had conversations with the gwt-ext team leads and they have expressed that having an option for users that feel limited with gwt-ext to migrate to SmartGWT is a healthy option. Assistance will be provided to users who are interested in migrating. Ofcourse the gwt-ext project will continue to run the way it currently is.
The evolution of SmartGWT to version 1.0 has been very quick, even assuming you started development in May. Were there lessons you learned in developing gwt-ext that you were able to apply to SmartGWT?
Working on an open source project is mostly about personal satisfaction and the "feel good" aspect of being involved in a project that is of use to several other users. It is also a great learning experience that helps personal development.
On the technical side of things, I was able to apply my learnings during the development of gwt-ext towards SmartGWT while improving upon the common issues faced by the users. I also learned it was very important to pick a project that doesn't involve politics and something that is motivating.
It was extremely distressing to frequently receive emails from the owners of Ext, LLC threating to sue me if I didn't play along with their plans. For instance they wanted me to switch to GPL or else they would find me in violation of their license. Again, no details were provided. I also received another threat where they said that I would hear from their lawyers within 24 hours if I didn't allow them to post on the gwt-ext forum. And this was after I put in a lot of effort building a project which directly supported growth and sales of their own library.
In contrast, the folks at SmartClient have been fully supportive of SmartGWT, providing technical assistance and a safe home for SmartGWT which will be operated under their umbrella. They even wrote a public letter indicating that they will not switch licenses of their LGPL offering. It feels great to be back working on technical stuff with what I consider a superior product.