"Native" browser support of GWT. Is it possible?

[Olostan]

Hello.

I am not very good specialist of plugins development for Firefox, but
as I understand, all plugins are written in JavaScript. So there is
idea of how to speedup loading GWT application - to move
implementation of core GWT classes into some kind of plugin.

So when loading GWT application, script would check is current browser
have already that core part of GWT (same version) and would use it
instead of downloading from server. If not, ordinary loading process
would be perfomed.

As for me, it would significantly speeds up loading process, lowing
bandwidth usage, etc.

Now it is only "raw" idea without any deep investigation of GWT and
Firefox internals. So for now I am just curious about is it
technically possible and opinions about this idea.

May be this idea already discussed?

WBR,
Shybanov Valentyn
http://olostan.org.ua/

[theClassConnection]

I've never thought about this before, though it seems to hold promise
for intermediate/advanced firefox users at least.

Unfortunately for this idea, I remember reading something about the
development team working toward totally custom generated javascript as
opposed to custom generated javascript bootstrapped by a totally
generic library. I don't remember where I read this, but I think it
was in the context of minimizing download size. However, it could have
been a part of a discussion on increasing the mash-up potential of gwt
applications... If they do go the custom library, it could be more
difficult to implement a 'browser-native' library; although I suppose
a browser library that contained everything that was possibly required
would work... A bloated browser library that's downloaded once
instead of a slim custom library occasionally downloaded after being
flushed out of a cache still sounds like a savings to me...

I don't suppose anyone knows if there is any potential for an IE
'browser-native library' plugin or anything...
-Joshua Yanchar

[Reinier Zwitserloot]

Considerable effort for minimal gain. The basic footprint of GWT will
never go much above 60k or so, I bet. The rest is your code.

You could also add in a whole host of commonly used GWT extensions and
try and keep them automatically updated somehow, which would have a
little more impact, but realize this:

You will have to modify the GWT compiler to output another permutation
- the 'we can hitch a ride on the preloaded JS code' one. This will
increase the time needed to compile. If GWT doesn't ship 'out of the
box' with the functionality completely in place, the majority of GWT
projects out there won't be using it, and as a result your firefox
plugin will be useless.

Dojo and the like are looking at this because their footprints are so
large. GWT's footprint is much smaller due to, amongst other things,
the permutation system. No other toolkit out there has this right now.

I like YUI-EXTs creative management of browser caches more (all YUI-
EXT libraries are downloaded from yahoo, so every yui-ext app out
there is using the same .js file, which will probably be in the
cache).

Regardless: Check cache settings. Normally, revisiting your webapp
should be a much smaller download due to most of the GWT JS code being
cached. If you try and check what happends by reloading the page,
well, that won't work well (though IE's reload is half assed enough
that it might, I don't trust it) - that will explicitly clear all
caches of related content.

So you're saving the one-time download of maybe 150k. Be reasonable:
How many people would install that plugin? My personal feeling: About
15.

A harsh wake-up call perhaps, but: So not worth the effort. You'd be
better off carrying a teaspoon full of water from the ocean to your
drain to counteract rising sea levels.

On May 3, 10:51 pm, theClassConnection <theclassconnect...@gmail.com>
wrote:

[Reinier Zwitserloot]

Oh, and Joshua:

You misunderstand.

GWT is -already- a totally customized build of javascript files. The
only 'generic' bit about it, right now, is the 'gwt.js' file which
isn't very large at all.

GWT 1.4 does away with gwt.js, instead combining gwt.js and the app
bootstrapper (which is different for each app). On the downside, you
can no longer pull a centralized caching theme for gwt.js*, but on the
plus-side you save a HTTP roundtrip, and the combination gwt.js+app
bootstrapper was larger than the current unified gwt.js+bootstrapper
in one.

*) on caching gwt.js: A firefox plugin is ridiculous. All you'd need
to do there is petition google to host all gwt.js at http://www.google.com/gwt.js
and browser caches will take it from there. Almost as effective as
your plugin, except it works for every browser and for every one,
without a need to install a plugin. Moot point, gwt.js is no more.

On May 3, 10:51 pm, theClassConnection <theclassconnect...@gmail.com>
wrote: