Hi Nathan,Thanks for mentioning me under the "Benefits" section :)
As always, constructive criticism is welcome and helps improve the product. For example it was primarily due to user feedback the the new Enterprise skin was quickly delivered by SmartClient. I'd like to respond to some of your concerns "1) Incompatible or redundant APIs. Specifically, I'm thinking of a. Redundant event system b. Datasource c. TreeGrid has approximately 160 methods." Can you clarify b) ? DataSources are a very powerful concept and most SmartGWT components support being bound to a DataSource. As you probably know, this means that any changes made to the data in the widget - whether it be cell edits, or tree node reordering, or drag and drop across separate databound components are automatically reflected in the underlying local data, or propagated to the server for you to act upon the change operation. Thanks to datasources and their inbuilt capabilities, this can save the application developer from writing a whole lot of code to manage these operations per-widget per-screen. The TreeGrid does have a lot of methods. An advanced tree is a sophisticated component and the philosophy of SmartGWT is that pretty much any feature or customization that the user may require is supported out of the box and can be settable via a simple property. As you noted, the SmartGWT Tree component is very powerful. Here's a link to the TreeGrid javadocs for the benefit of the users : http://www.smartclient.com/smartgwt/javadoc/com/smartgwt/client/widgets/tree/TreeGrid.html If you have a closer look, you'll see that there are listeners for numerous events and properties like canAcceptDroppedRecords that turn on local or DataBound drag & drop. It would be interesting to see what the API for the incubator Tree looks like when it supports all these features - and I say this in a positive way with the best of intentions. "2) Lack of GWT Compiler optimization" The SmartGWT API's are optimized by the GWT compiler such that only those methods used are part of the compiled output. You're right that the underlying SmartClient JS files are not going to be aggressive pruned by the GWT compiler however there are other benefits to this. For example the core SmartClient JS files can be have an expires header set to the future to enable caching and even deployed on a CDN. So when the users application code changes, and a new set of GWT md5 based files are generated, the only file that gets refreshed when a user accesses the site is the smaller GWT compiled files, and not the core "kernel" SmartClient JS files as they are cached. As you say its about trade-offs but what is important to keep in mind is not dismissing SmartGWT due to this, but rather focus on the end result once your real world application is build. The SmartGWT showcase is a good example of this which comparable, if not larger than many real world applications. A good apples to apples comparison would be to compare a GWT based application with as many screens and similar featureset. With this in place it would be a good basis for total file size comparison. The GWT version will no doubt be smaller. If every single KB is important to you, that might be a factor but you have to ask the question about how much more application code did you have write to build your enterprise application? I can state with confidence that if you are building a data intensive enterprise application, SmartGWT can cut down application code by 50% or more compared to home grown solutions and this is due to the combination of a lot of configuration properties being supported out of the box, and the strong data-binding capabilities. In my blog I have a complete example of an end to end CRUD sample that supports filtering, sorting, inline edits and more with as little as 20 lines of client side SmartGWT code and a 20 odd line server descriptor file. Moreover no code generation is involved. No other AJAX based technology that I know of can deliver so much with so little coding. On the other hand if you're looking to simply include a couple of widgets in your page that interact with client side data only, SmartGWT is probably overkill. "3) no use of ImageBundle" 100% agree with this. This is on the roadmap and hopefully will make it for the next major release without code changes for the end user. "5) No intuitive way to customize styling" SmartGWT, by virtue of SmartClient does have a very powerful skinning system. A key advantage is that users can customize styling using a Java API in cases that make sense, while using CSS in others. If you look at SmartClient's different skins you'll notice that essentially everything can change, including the use of completely different widgets in different places (eg switching ListGrid headers between pure CSS, 1 image, or triple image representations). As another example, have a look at the tabs in the TreeFrog skin. Perhaps users can take the initiative and create a lightweight theme for SmartGWT similar to GWT's theme that is simplified and involved way less media. It certainly is possible. I'll be happy to try to answer any other questions / concerns here, or if you have specific questions or suggestions for improvement you can post on the SmartGWT forums as well. Thanks, Sanjiv On Fri, Aug 14, 2009 at 8:45 AM, Nathan Wells <[email protected]> wrote: > > I would like to add a dissenting voice... As always, it's a matter of > trade-offs > > Benefits: > 1) Pretty, usable, full-featured widgets, with very small up-front dev > time. > 2) Very responsive dev team (you're awesome Sanjiv) > > Problems: > 1) Incompatible or redundant APIs. Specifically, I'm thinking of > a. Redundant event system > b. Datasource > c. TreeGrid has approximately 160 methods. > 2) Lack of GWT Compiler optimization > 3) no use of ImageBundle > 4) b/c of 2 & 3, very request intensive. > 5) No intuitive way to customize styling > > Right now, our team is using TreeGrid, because no comparable widget > exists, but I've been thinking we should take a look at customizing > the gwt-incubator tree grid. > > On Aug 13, 11:54 pm, Daniel Jue <[email protected]> wrote: > > Now, how about an MVP/Eventbus version of SmartGWT showcase? > > =) > > > > > > > > On Fri, Aug 14, 2009 at 1:31 AM, shay <[email protected]> wrote: > > > > > I Highly recommend SmartGWT, been using it for months now. > > > > > Sanjiv and the smart client team have done a great job. Kudos! > > > > > The architecture is clever and robust , way better then Ext. > > > > > Shay > > > > > On Aug 13, 9:03 pm, Sanjiv Jivan <[email protected]> wrote: > > > > Hi Daniel,Please try upgrading to SmartGWT 1.2. Hosted mode should > > > perform > > > > better. You're right that most of the resources from a compile > output > > > are > > > > not used and so if you're benchmarking, best to actually see what's > > > > transferred over the wire rather than the size of the output > directory on > > > > the server. The default com.smartgwt.SmartGwt module bundles all the > > > > readable source versions that have a lot of documentation, the > obfuscated > > > / > > > > minified ones, various tools like the Developer Console and a lot of > > > other > > > > resources that are pretty much never used in deployment. I'll look > into > > > > creating a module that outputs the minimal resources which will save > some > > > MB > > > > of disk space on the server. > > > > > > As for runtime performance, you can have a look at the SmartGWT > showcase > > > > which is comparable is size to a real world application having ~260 > > > samples > > > > and includes most widget types. If you're not using Calendar, or > TileGrid > > > > etc you can exclude these resources. > > > > > > Sanjiv > > > > > > On Thu, Aug 13, 2009 at 8:18 PM, Daniel Jue <[email protected]> > wrote: > > > > > It is slow in hosted, although I'm on SmartGWT 1.1/GWT 1.7 at the > > > moment. > > > > > Deployed it is better, but its' still chunky. However it's full of > > > features > > > > > that I don't have the time or desire to recreate, so it works for > me. > > > It's > > > > > definitely not a lightweight, but it's not bad. There's just a lot > > > going on > > > > > behind the scenes. The full "sc" directory that gets put in the > war is > > > like > > > > > 18.7 MB (19,630,389 bytes) worth of Js files. I'm guessing 98% of > > > those > > > > > won't be touched/loaded. I like SmartGWT so far and have > recommended > > > it to > > > > > some people. > > > > > > > On Thu, Aug 13, 2009 at 8:03 PM, Chris <[email protected]> wrote: > > > > > > >> It is slow in hosted? But how is it deployed in > > > > >> a regular browser? > > > > > > >> On Aug 13, 4:00 pm, Daniel Jue <[email protected]> wrote: > > > > >> > I am using it. Once I got the extra layers of code implemented > for > > > the > > > > >> RPC > > > > >> > Datasource (mostly from off thier forum), It's been pretty > painless. > > > I > > > > >> came > > > > >> > from GXT 2 because I was having some rendering problems and > wanted > > > to > > > > >> try > > > > >> > something else. SmartGWT _is_ painfully slow in hosted mode, > but > > > the > > > > >> > widgets are very nice and full featured. > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
