Someone off-list took some of my comments the wrong way. I'd just like to clarify, as long as GWT is targeting the ultralight use case of an application that must be as fast as possible on first access, it makes sense for GWT to rely on browser layout and just provide direct CSS for skinning. It's not something I'm saying is a flaw in GWT or a bad design decision, in fact, it's the same decision I would make in addressing that use case.
The reason is simply that it takes a certain irreducible amount of code to really build layouts that don't depend on native browser behavior, and that's too much to deliver for the ultralight use case. It's just different designs for different use cases. I hope the core GWT widgets continue to focus on the ultralight use case, because there's just nothing comparable, especially for mobile. On Mar 12, 12:44 pm, ckendrick <[email protected]> wrote: > And here are the authors to disagree :) > > 1) Yes, we make intentional departures from the GWT way, such as.. > > 2)SmartGWThas better cross-browser consistency than GWT itself. > Why? Because GWT relies on native browser behavior and CSS for > layout, and this is where all the quirks come from. We do layout with > layout manager classes, more in the style of Java Swing. Yes, GWT has > layout managers, but what they're actually doing in many cases is > relying on the browser interpretation of sizes and layout rules. > Also, re-skinning your application with GWT is straight CSS, > whereasSmartGWTprovides an abstraction that separates styling-as-such from > layout. > > 3) The library is cached, so you only increase the first-ever load > time. If you have a site where you are trying to display something as > fast as possible for a visitor who comes only once, this may matter. > If you're building an enterprise application and people use it > regularly, it doesn't matter, the extreme productivity benefits of > theSmartGWTgrid (and other components) are much more important. On > broadband,SmartGWTapplications come up faster than the launch time > of Word or Acrobat, so it's right in line with user expectations for > enterprise/desktop applications. > > As far as the future, my take is that GWT cannot both retain an > ultralight footprint *and* provide the features of an enterprise > platform likeSmartGWT- static code analysis just isn't a strong > enough approach to code trimming to enable this. I covered this in > depth here: > > http://www.mail-archive.com/[email protected]/msg34... > > You've also got to consider the state of the art, of course. Will > your customers be doing a head-to-head comparison on functionality and > productivity between your competitor, who usedSmartGWT, and your app, > which uses plain GWT grids? That's going to go very badly against > you. > > On Mar 12, 1:58 am, Nathan Wells <[email protected]> wrote: > > > I would say you are correct on the disadvantages ofSmartGwt. There > > are those (most notably the author(s)) who I know disagree with me. > > GWTers recognize the need for a more robust, data-backed table > > solution, and it's currently in the works, targeted for 2.1. Our > > company decided to go withSmartGwtfor now, then migrate to a more > > "Gwtfull" solution later. > > > On Mar 12, 1:29 am, mariyan nenchev <[email protected]> wrote: > > > > Try scroll paging table from gwt incubator, i think it was updated to gwt > > > 2.0. > > -- 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.
