On Mar 13, 2:39 pm, John Tamplin <j...@google.com> wrote:
> On Fri, Mar 13, 2009 at 8:36 AM, lkcl <luke.leigh...@googlemail.com> wrote:
> > i have a post-processing compile step in which i just go "ok, let's
> > assume everything was globally imported" and make sure that the first
> > thing an app does is dynamically load aaabsolutely everything (in the
> > right order of course).
>
> Ok, so all this is buying you is savings on the total size of scripts at the
> expense of dramatically increasing the number of round trips for app
> startup,
roundtrips, no - each level of dependencies is fired off
simultaneously, resulting in a raather large number of overlapped
module loads. the kitchensink example has 122 cache files (!!) and
about ... ten levels of dependencies, so the actual total delay is
only the ten longest dynamic loads.
surprisingly, this actually ends up being incredibly quick.
> which is actually the opposite of what runAsync is trying to do --
> there the goal is to get the app up and running as quickly as possible, and
> let code needed later (or not at all) by the user get loaded later.
yes. unfortunately in python, people tend to put "import" statements
globally at the top of the module, rather than putting them into a
module-local function or class.
... oo, i have an idea.
at present, what i've done is create a javascript function (object)
per module. to initialise the module, you call the function:
ui = function() {
if (this.__initialised_already) return;
this.__initialised_already = true;
// you're into the ui "init" stage now, setting up classes etc.
};
and then you get a ui.Button module, which does:
ui.Button = function() {
if (this. .....
};
the idea that occurred to me is this: instead of making that ui.Button
you make it ui().Button.
and you do this:
ui = function() {
if (this.__initialised_already) return this;
this.__initialised_already = true;
// you're into the ui "init" stage now, setting up classes etc.
// all done - return self
return this;
};
or, instead of ui().Button() you do, oh, i dunno.... this:
moduleget("ui").moduleget("Button").some_userfunction_in_button_module
()
... *thinks*.... what i was envisioning was that it would be possible
for moduleget() to be able to wait for a dynamic-load of a module to
complete before proceeding
... but, there is no "sleep" function in javascript - you'd have to do
a 100%-cpu-load loop - to wait for the asynchronous loads to complete
- before proceeding.
can you (or anyone!) think of a solution, here?
> The
> number of HTTP round trips is a huge factor in the perceived performance of
> a web app.
tell me about it.
> I think a better way to approach this would be to have a server component
> that dynamically builds the response from small pieces so you get the entire
> thing in one HTTP request but shared code can be shared between all the
> permutations. Ie, for permutation n it knows modules A, C, D, G are
> required so it simply reads those from storage and prepends them (in the
> right order) to the permutation-specific file and sends it to the browser in
> response to the request.
i like that idea a lot.
the only fly in the ointment is that of sharing modules _between_
apps, and also sharing modules between third party AJAX Frameworks
such as dojo, extjs, prototype etc.
if you have third party apps which are using the gwt and the pyjamas
compilers - or even if you decide for one mad moment to share cache
files between gwt and pyjamas (good grief, what a thought) - such
optimisations terminate such possibilities.
ha.
that would be _well_ cool. pyjamas apps being able to import
dynamically-loadable GWT precompiled modules, and vice-versa.
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
