I was using smartGwt for a while but then reverted to Gxt. The main reason is that smartgwt had issue when I was combining smartgwt widgets and normal Gwt widgets (things that I had built and wanted to reuse). Things would not layout properly or would not resize... Gxt did not have the problem. I also think that Gxt is better designed in general as it is written in Java, where often you can tell that smartgwt is a wrapper. It seemed to me that there was very little abstraction and inheritance, making it difficult to look at a classes with lots of methods. Though the Data Source concept of smart is good when you have DB intensive apps.
On Aug 15, 1:22 am, Aladdin <alaamu...@gmail.com> wrote: > The only difference that the GWT compiler will not include the JS in > the downloadable files. So the optimization is not only for the speed > it's also for the size of the application. > > If you wanna developed huge project SmartGWT is the way to go, but > remember that your minimum app is going to be 1mb in size because of > the SmartGWT core files. > > On Aug 14, 10:34 pm, ckendrick <charles.kendr...@gmail.com> wrote: > > > Hi Malte, > > > As far as once-ever load time, if you're building an enterprise > > application with several screens and lots of productivity features, > > you're going to be using substantially all of SmartClient - if it was > > written in Java, the impact of the GWT compiler's static analysis > > would be negligible. If you're building something more trivial, just > > a few components and basic interactions, it doesn't really matter what > > you use, anything will do. > > > On performance, SmartGWT is already more than fast enough in terms of > > UI interactions. It doesn't matter whether a menu appears in 40 > > milliseconds or 60, humans literally cannot perceive that difference. > > So, while I would argue that future changes to the GWT compiler are > > not going to beat SmartClient's hand-coded JavaScript, it doesn't > > matter anyway, it makes no perceptible difference. > > > What does matter for real world performance is a feature like Adaptive > > Filtering, which radically cuts down on trips to the server, improving > > responsiveness and scalability: > > > http://www.smartclient.com/smartgwt/showcase/#grid_adaptive_filter_fe... > > > SmartGWT has half a dozen other features that make similar, real world > > impacts on performance. This is what actually matters in a deployed > > application. > > > On Aug 14, 10:59 am, Malte <mlegenhau...@gmail.com> wrote: > > > > Hi all, > > > > For a few month a had the same problems: GXT or SmartGWT and I choose > > > GXT. Ok now why? > > > The main reason was the speed. Cause the extjs team recreated the > > > whole library in pure GWT code, what make it amazing fast. But that > > > was for a few month. Currently SmartGWT has nearly the same > > > performance, but I think the main reason is that the browsers are now > > > much faster (I am using Firefox 3.5). Currently I am thinking again, > > > but I am not a fan of wrapper libraries. I know there is a lot of work > > > in creating SmartGWT, but there are some disadvantages: > > > 1. When the GWT compiler gets better and can optimize more and more, > > > the SmartGWT library will not get any of these advantages. > > > 2. Loading time! Sure after the first load the load time will be equal > > > to pure GWT application. But the first time is the time where the user > > > decides to stay on this page or not... in most cases there is no > > > second chance. > > > 3. Upcoming features like runAsync bring no advantages. > > > > Greetz > > > Malte > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
