Sanjiv Comment on ppl argue with Pure Gwt and Javascript Wrapper ( SmartGWT )

Compile output size and runtime performance are two separate issues. A
third party widget written in GWT Java, regardless of how small it compiles down
to, doesn't magically make it run fast. Nor does it make it magically render
perfectly on all browsers. As an example a TableGrid written in GWT Java 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. The GWT 1.6 event API is really neat and SmartGWT users
it. Well written code is what will perform well and display consistently
across various browser.
On the issue of performance, there are numerous posts
made by paying GXT users that the performance of GWT-Ext is still better than
GXT. You can search their forums. This is not to suggest that performance
improvements cannot be made in SmartGWT. If you can give specifics, it would
certainly help in resolving them. But without specifics like whether it was the
initial load time, performance of specific widgets etc it will be difficult to
act on. Feel free to post on the SmartGWT forums or create an issue on the
smartgwt google code project.
On the issue of compile output size : The
SmartClient library is extremely stable and developed over the past 8 years.
If you peruse their forums, you will find that pretty much all questions
are met with an answer explaining how the user can accomplish what they're
trying to do. Their library is virtually bug free. I realize this is a strong
statement, but its true. Only some 4-5 issues were patched
post-release. Compare this to the bugs forum of any of
your favorite libraries. SmartGWT will inherit these attributes
once its past the few initial minor releases and issues are flushed out during
this period. Due to the high level of stability of SmartClient, it can be
viewed as the kernel of your web app which should be configured to be
gzipped with an "Expires Never" header for a given version. This means that the
browser will cache the "kernel" (SmartClient JS files) and the only code that
gets downloaded is your application code, and not any code related to the widget
/ framework. Future releases of SmartGWT will provide a GWT linker that only
pulls in the required files so this should cut down the total size of the
application.
The SmartGWT showcase has some 250 samples which is 6 times more
than the GXT showcase so its not quite apples to apples when it comes to initial
load time.
Finally please read my blog entry http://www.jroller.com/sjivan/entry/smartgwt_1_0_released if
you haven't already done so. I go over the SmartGWT fundamentals, the concept of
a DataSource and how it will lead to a cleaner architecture and can cut
application code significantly. I mention how a master detail page can be
written in as little as 10 lines using a reusable DataSource definition that
describes an entity / model class. Plus the reduced number of lines of code on
the server as well.This is the first release of SmartGWT and while it is quite
stable and has been tested and used by early adopters for the past four weeks,
users can expect any rough edges / bugs / performance issues / better skins etc
to be ironed out over the course of the next few minor releases.As mentioned
earlier, if users have found a library that meets their needs, thats great and
there's no need to look further. And for the others, feel free to evaluate
SmartGWT to see if it helps meet your requirements. If you feel that there are
things that can be improved please post on the SmartGWT forum or create an issue
on the google code project page.