Brian, You raise valid points. As I mentioned early in the thread, GWT's sweet spot is rich Internet applications IMHO. In a typical GWT app, the amount of user code dwarfs the JRE. In a relatively small app I've built, the JRE is 43kB and allOther is 169kB. If there were an 11kB core JRE on a CDN somewhere, it just wouldn't help that much.
The use case you've given (many, many widgets that cannot be compiled together) is definitely not in GWT's sweet spot. If your analysis shows that it would be better to use another approach, by all means run with it! For those of you who haven't muted this thread yet in Gmail, here's a size reduction tidbit that's not written up anywhere else yet AFAIK. When you do your final production compile, you can set a property in your .gwt.xml to remove client-side stack trace info, which may save up to 15% in code size: <set-property name="compiler.stackMode" value="strip"/> Happy shrinking! /dmc On Fri, Dec 17, 2010 at 9:58 AM, bkard...@gmail.com <bkard...@gmail.com> wrote: > Stefan, > > Let's lay aside the issue of a windowing toolkit just a moment and > talk about your general comment because I think that there may > actually be two separate issues worth discussing that are stemming > from this same observation/question and there's something I want to > clarify. You said: > > [quote] > ...the code inside this "library" would not be optimized for your > specific application. Moreover it would contain code for all possible > browsers supporting all of their "weird interpretations". One of the > strength of GWT is the compile step and the optimization of the > produced code for one specific application - one specific problem. And > for the next project the code will be optimized again - but maybe in a > different way... So personally I can not honestly see your problem." > [/quote] > > As I have tried to explain repeatedly throughout the thread, I don't > have a problem with GWT: What I have is a specific use case over which > I have no control, for which it seems to me that GWT would be a sub- > optimal choice as things currently stand... But I'm open to hearing > how it could work, or maybe even opening up the discussion as to > whether these kinds of use cases are worth GWT addressing in the > future. I think you are largely responding to the later - suggestions/ > questions around how it might be supported. Nothing that I have said > should imply anything contrary to most of GWTs optimizations - I have > not suggested in any way that GWTs deferred binding and generation of > independent files for N browser permutations is problematic - in fact > - I quite like it and see no reason why the same wouldn't apply. > > Let's look at something a little more finite: Lay aside the WT part > of the problem for a minute. I'm not making up the abstraction of a > JRE for GWT - it exists. JavaScript does not contain things like the > Number abstractions that Java does, so it's ported/adapted by the GWT > compiler. In this respect, JRE and gwtLang are, to some extent, in > every single build of every single GWT compile. IE compile variants > are generally the most pathological and also the least efficient, so > let's look at those as a case study... From my soyc reports I'm seeing > that the JRE size appears to be always _about_ 11KB... It looks to > differ from build to build by only a trivial number of _bytes_. But, > for argument sake, lets say they differed by even roughly 20-25% in > size because of optimization by the compiler... That would be > comparatively kind of huge, but it still means that between 9K and 13k > of essentially "GWT adapter" code is downloaded every time you use > something compiled by GWT. > > If you run a single GWT app for some very specific purpose - you > probably say "who cares". Well, if your premise is that that cutting > out somewhere between a few bytes to 2k is an optimization - my > question is: Is it? > > If you're really aiming for efficiency, there are many things to > consider: download size, number of connections required, the projected > connection speed of your users, runtime speed, interpretation speed, > runtime memory use - and not trivially, your ability to cache it for > long, long periods of time. The fastest download is the one that > never happens. > > GWTs single optimal download/infinite caching is based on a coarse- > grained download for each compile - but the supporting JRE > permutations are roughly the same for an entire GWT release. Which > revs more often - every app that uses GWT - or GWT? Would it be more > optimal to pull those in as a separate download from a CDN? Not for > the first time someone used a GWT app, but from then on - yes - and > it's a benefit that would be realized across every single GWT app that > a user used and doing so would increase the resource usage timestamp > on those, thus decreasing the likelihood that your browser will evict > it from cache (i.e., fewer cache misses). Perhaps that seems like a > small win but compared to the tiny, tiny optimization difference that > is there now for this space of the problem - it's potentially huge, > and you don't even have to have my particular situation: Imagine that > you work for a company whose enterprise has adopted GWT - they might > have 10 or even 100 separate GWT apps that release updates on bi- > weekly schedules. The number of bytes "saved" is number of apps * > number of releases. In fact, if you're real lucky, some of your users > will use some other GWT-based app too and your app wouldn't even pay > the initial price. > > Given the situation above - and mine - there may be additional > benefits to something similar for at least a base of what's required > for WT... At least for this class of problem. > > Anyway - those are just thoughts... I think reasonable people could > disagree, but the more I look at it, the more I think I'm seeing > situations where at least some compiler switch or something for > supporting this sort of thing might be a cool/useful idea if it could > be incorporated. > > -- > 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-tool...@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. > > -- David Chandler Developer Programs Engineer, Google Web Toolkit http://googlewebtoolkit.blogspot.com/ Twitter: @googledevtools -- 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-tool...@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.
