Debugging in Firebug is something that I'd like to avoid as much as I can. Especially for a GWT app which usually are pretty big. The nice thing about Ext-GWT is that I don't need to do that (probably once in the blue moon on a very extreme case).
Knowing the internal Ext-GWT which is written in pure GWT also helps a lot. How about SmartGWT ? Do I need to know all the JS stuffs? Eventually I do if I want to do something more than the framework has to offer. I suppose one nice thing about wrapping JS is that you only deal with one low-level code-base. Other than that, I don't see any advantage. At the end of the day, I can only wish SmartGWT takes Ext-GWT approach. Last time I did a lame comparison on Ext-GWT and GWT-ext, Ext-GWT is much snappier compare to GWT-ext. I have couple questions though: 1) How do you guys do deferred binding in SmartGWT/SmartClient? 2) How do you optimize SmartClient for a specific browser? 3) How does the serialization work? if I recall last time, in GWT-ext someone has to purchase something else? On Nov 24, 10:56 am, ckendrick <[EMAIL PROTECTED]> wrote: > Lest anyone get the wrong idea from francesco, when using SmartGWT you > can debug your GWT *application* code normally within hosted mode. > > If you had a need to debug the core SmartClient libraries (normal > users will not have a need to do this), you'd use debugging tools like > Firebug and SmartClient's Developer Console. Calling this being "out > in the cold" is bit of hyperbole given that SmartClient's very long > track record of success has always been based on this approach, which > works well, and will work even better with the next crop of browsers, > *all* of which have Firebug clones. > > Finally, on performance - the real world performance of enterprise > RIAs is dominated by the number of trips to the server and the > intensity of database load. In this extremely key aspect - again the > primary determinant of real-world performance - SmartClient/SmartGWT > has a very dominant lead, which is due to it's sophisticated data > binding architecture (particularly adaptive client-side operations and > intelligent data caching). By comparison, possible code size > differences caused by a different mix of JSNI vs Java code is at best > a 3rd or 4th tier performance concern, and is frequently has literally > zero impact on actual performance of delivered applications. > > Using JSNI has distinct advantages - as Sanjiv touched on, we are able > to optimize things at a very low level within the SmartClient runtime, > and we can more easily profile and tune core framework code because > it's not going through a Java->JavaScript translator. This is very > much like the mix of native C++ and higher level languages like C# > within a .NET CLR - different languages for different tasks. > Personally, for the kinds of applications that SmartGWT is designed > for, I see it as a tremendous architectural advantage. > > On Nov 24, 12:32 am, francescoNemesi <[EMAIL PROTECTED]> wrote: > > > Hi Sanjiv, > > > thanks for your reply, agree with your comments. Re-reading my post I > > agree it might look like I was, in a way, attachingsmartGWT. It was > > not meant to come through that way, nor was my intention to praise > > GXT. > > > It was only meant to be a comparison between approaches, JSNI vs Pure > > GWT, and I definetely think that using JSNI as the foundation of any > > GWT framework is not the right thing to do. Smart Client is an amazing > > framework, but it is a JavScript framework. Using JSNI leaves you in > > the cold when you need to debug, as an example, but I am sure you know > > all that. > > > I think you have done a great job withsmartGWT, it looks really great > > and I am sure it will have the success it deserves. > > > Regards, > > Francesco > > > On Nov 23, 8:34 pm, "Sanjiv Jivan" <[EMAIL PROTECTED]> wrote: > > > > Hi Fransceso, > > > If you found a library that meets your needs, then good for you. > > > 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 andSmartGWTusers > > > 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 inSmartGWT. 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 theSmartGWTforums or create an issue on > > > thesmartgwtgoogle 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.SmartGWTwill 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 ofSmartGWTwill provide a GWT > > > linker that only pulls in the required files so this should cut down the > > > total size of the application. > > > > TheSmartGWTshowcase 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 > > > entryhttp://www.jroller.com/sjivan/entry/smartgwt_1_0_releasedifyouhaven't > > > already done so. I go over theSmartGWTfundamentals, 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 ofSmartGWTand 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 evaluateSmartGWTto see if it helps meet your requirements. If you > > > feel that there are things that can be improved please post on theSmartGWT > > > forum or create an issue on the google code project page. > > > > Thanks, > > > Sanjiv > > > > On Sun, Nov 23, 2008 at 5:49 AM, francescoNemesi <[EMAIL PROTECTED]> > > > wrote: > > > > > Hello, > > > > >smartGwtlooks very appealing and very rich in features, but it is > > > > very slow. This is due to the fact that it is a JSNI wrapper around > > > > the Smart Client framework. This means loosing all the benefits of > > > > having a pure GWT implementation (I will not go into details on this). > > > > > I think a comparison with GXT (also known as GWT Ext, at this address > > > >http://extjs.com/products/gxt/) does not make any sense as GXT is a > > > > pure GWT feature implementation and it is lightining fast once > > > > compiled. > > > > > The only appropriate comparison would be with gwt-ext (http:// > > > > code.google.com/p/gwt-ext/) which is JSNI wrapper around the ExtJS > > > > javascript framework (developed by the same company that developed > > > > GXT), much likesmartGwtis a JSNI wrapper around the Smart Client > > > > framework. > > > > > This forum is full of people complaining about how slow and cumbersome > > > > gwt-ext is, and I think exactly the same problems will be encountered > > > > withsmartGwt.On the other hand GXT is not affected by any of these > > > > issues. True, GXT at the moment is not as rich in features at the > > > > moment, but they are getting there. > > > > > I do not work for the ExtJS company, I only talk from experience. I > > > > used the JavaSciprt ExtJS framework for a big project for a full year > > > > and I understand exactly when people say the documentation is poor and > > > > performance slow. Having embranced GWT to progress and to make my life > > > > easier, I would never want to to have the same problems again with Js > > > > frameworks, even less with GWT frameworks with embed the same old Js > > > > issues, like gwt-ext orsmartGWT. > > > > > GXT is a completely different matter and I think it is a top > > > > framework. I have been using it for a few months now and never gave me > > > > any major issues. It is a pure GWT implementation, no javaScriptObject > > > > or JSNI. Period. > > > > > Huge credit to Sanjiv for his work onsmartGWT, but personally I think > > > > this is the wrong approach to any GWT framework. JSNI is very useful > > > > if used to integrate the odd js function here and there, not as a > > > > foundation to a framework itself. > > > > > Regards, > > > > Francesco > > > > > On Nov 23, 10:33 am, "Juan Backson" <[EMAIL PROTECTED]> wrote: > > > > > Hi, > > > > > > I am wondering if the performance is due to too many items inside the > > > > demo > > > > > or it is just slower than gwt-ext? In gwt-ext, the demo is much > > > > > smaller. > > > > > > On Sun, Nov 23, 2008 at 10:27 AM, rakesh wagh <[EMAIL PROTECTED]> > > > > > wrote: > > > > > > > great job Sanjeev. Keep up the good work. Always love smart-client. > > > > > > Smart client is much better compared to ext-js as far as licensing > > > > > > is > > > > > > concerned. However the showcase looks little slow compared to the > > > > > > original js based smart-client as well as gwt-ext. > > > > > > > Thanks! > > > > > > > On Nov 22, 6:48 pm, Tim <[EMAIL PROTECTED]> wrote: > > > > > > > Excellent Job! > > > > > > > > some things are rough around > > ... > > read more » --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
