(d) does not apply to SmartGWT. No GWT update has ever broken SmartGWT or broken backcompat.
(e) does not apply to SmartGWT. Nightlies are available for all editions - see smartclient.com/builds (c) presumably means "customizing" a widget by messing with it's DOM or overriding internal methods. SmartGWT has a big range of documented and supported customization APIs that don't involve low-level hacking, and if these break, we consider it a bug and fix it. (a) & (b) [performance stuff] needs to be considered in light of what actually drives performance for your application. SmartGWT is designed for complex enterprise applications, so we do not optimize for first-ever page load experience (doesn't apply to apps used repeatedly and for long sessions). Instead we optimize for maximal data reuse, since round-trips to the app server & database are almost always the thing to optimize in enterprise apps. A deeper discussion is in the SmartGWT QuickStart Guide, Evaluating SmartGWT chapter. In a nutshell: - the drawbacks of Sencha are not the drawbacks of SmartGWT - get clarity on what performance characteristics will matter for your end users, *then* look at performance from that perspective. If you hyper-optimize the wrong thing, your app will be slow for your end users. On Sunday, September 16, 2012 10:26:02 AM UTC-7, Andrei wrote: > > I prefer the third option: I don't use either of them. I build very > complex user interfaces, and so far I never regretted going with pure GWT. > Here are a few advantages of this option: > > (a) Much smaller compiled code size. This also means faster compile times > for developers and faster page load times for users. > > (b) Better performance. I had 3 years of experience with Sencha. Their > widgets look nice (why we chose them in the first place), but in some > complex UIs with lots of data you start to notice the lag relative to pure > GWT. Remember that showcase widgets usually represent a very simple use > case. > > (c) Easier customizations. The simpler the widget, the easier it is to > modify it as you need. There is a lower probability of breaking something. > > (d) There is a lower probability that the next release of a library would > break your code. I remember how much pain we had with Sencha's updates > (2.0, 2.1, etc.) I hope it's much better now as Sencha moved closer to pure > GWT implementation of their widgets. > > (e) Faster updates. Once a new feature is available in GWT, you can use it > right away. With libraries you have to wait until their updates. > > I suggest that you use one of these libraries in two cases: > > 1. Your knowledge of CSS is not great, so you want a professional look for > your app out of the box. > > 2. You see some widgets in these libraries that you absolutely must use, > and you don't want to spend your time building them in pure GWT. > > P.S. Don't let GWT Designer drive your choice of a library. Once you learn > GWT, you may end up never using the Designer. I find it much easier and > faster to build new views in Ui:Binder, and then simply hit a refresh > button in a browser to see how my page looks like. > > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/N01iJIj6y5wJ. 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.
