IE6 sometimes gets stuck in “loading” mode forever (often if you have a 404 image or something of the sort by accident), so if you go for loading the javascript after the page has rendered you might never get it. I think if this is the route you want to take you should set a small timeout to download it instead of waiting for the page to be fully rendered.

If you only download functionality when the user wants to perform the action that’s even worse for perceived responsiveness. If you’re on a really fat pipe you might not notice but anyone with dialup (yeah, there are still a lot of them) will cringe at how sluggish your app is. People are used to a page taking a while to load when their connection is slow and don’t mind waiting (well, not as much at least) but waiting each time they want to do something once the page is “already loaded”, they don’t forgive.

In a not too complicated environment every programmer can choose for himself what to load at what time. And: modern browsers do not need the script tag in the head so we could also add our script tags just below the end of the body right? That should solve the progressive rendering problem steve describes.

The UIZE Framework, that is used throughout the zazzle.com Web site, provides a mechanism to facilitate deferred loading / load-on-demand / lazy loading / whatever-you-want-to-call-it. The JS client interaction of all pages is managed by a single instance of the “page widget” (this is a concept that UIZE introduces). Because UIZE, at its core, offers a feature called a widget hierarchy, child widgets on the page can access features provided by their host context, in this case the page widget. It is the page widget that offers support for loading components on demand (the concept of receiving functionality from a parent on the widget tree is a concept I call the “abundant context”).

Finding the balance between caching benefits of static JS libraries and load-only-as-much-as-needed is kind of an art form. I think it’s still best left to developers, although you could argue that with enough machine intelligence and data upon which to base decisions, a server could provide the “split” points. It seems like an incredibly complex problem to solve, and its solution could be quite intrusive into coding practices and framework architecture, and I fear that it’s a problem that’s more “cool” to solve than incredibly compelling – kind of in the diminishing returns territory.

Secondly, there the proposal for the GWT.createAsync() method, which I believe they have already proven via a prototype. This differs from Microsoft’s approach in that the developer chooses the splitting points, and then calls GWT.createAsync() to instantiate a lazily loaded class. The compiler will then compute the transitive closure of every reachable method from that lazily loaded class (that is not reachable from the entry point of the program), and ensure that those classes/methods are placed in a separate JS file.

This has pros and cons and differs from Doloto:
Con: you have to manually pick the split points.
Pro: You avoid the issues with trying to make the stub functions synchronous (since the JS has to be loaded asynchronously).

I think the Doloto approach, like the Volta approach for tier-splitting suffers from a leaky abstraction. They try to hide too much from the developer, whereas I think achieving an optimal split between progressive loading, or client/server that maximizes user experience takes a little bit of developer forethought and probably can’t be totally automated.

Anyhow do you any open source projects or tools like Doloto

http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/2ebaed0b9ce252bc/6219c92867f81b6a?lnk=gst

Bruce said that they were discussing this but I’m not sure how much concrete work has been done.