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.
