On Sat, Apr 25, 2009 at 11:19 AM, Niclas Hedhman <[email protected]> wrote:
> On Sat, Apr 25, 2009 at 4:36 PM, Guus Bloemsma <[email protected]> wrote: > > A GWT app is much more > > scalable by using the abundance of computing power available on the > desktop > > though. > > Ok, you iterated the basics of how we would like to see the overall > principles of Qi4j in GUI scenarios. I'm missing an equivalent to a per-property status() method on properties though. Or am I missing something? Is this view on GUI's documented anywhere? > > Tell me (I am not much of web developer), don't you a a problem of > transferring multi-MB of javascript to the clients? Is it possible to > have clever enough (probably incl versioning somehow) caching of such, > yet transfer the updated version when needed? > The app I worked on was a bit more than a megabyte when compiled to readable javascript (roughly comparable to the java source). After tokenizing it was about 250 kB. After gzip about 70 k was left. This is dwarfed by the bandwidth needed for images, CSS etc. GWT calculates a hash from the produced javascript and uses that in the URL. That way the javascript can safely be cached. When any code changes another URL will be used. So assuming a factor 10 shrinkage from java source to gzipped js executable, a multi_MB download means a huge application. cheers, Guus > > > Cheers > -- > Niclas Hedhman, Software Developer > http://www.qi4j.org - New Energy for Java > > I live here; http://tinyurl.com/2qq9er > I work here; http://tinyurl.com/2ymelc > I relax here; http://tinyurl.com/2cgsug > > _______________________________________________ > qi4j-dev mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/qi4j-dev >
_______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
