Comments on: Lazy Loading http://www.zimbrablog.com/blog/archives/2007/03/lazy-loading.html All Things Zimbra Tue, 06 Jan 2009 10:26:06 +0000 http://wordpress.org/?v=2.3.3 By: And The Winner of the Browser Wars is…. » Zimbra :: Blog http://www.zimbrablog.com/blog/archives/2007/03/lazy-loading.html#comment-8775 And The Winner of the Browser Wars is…. » Zimbra :: Blog Tue, 17 Jun 2008 22:41:56 +0000 http://www.zimbrablog.com/blog/archives/2007/03/lazy-loading.html#comment-8775 [...] user experience faster with the Zimbra Web Client. We’ve talked about Jetty, YUI compression, and Lazy Loading, but now there’s just one burning question: Which browser is fastest? There’s some amazing [...] […] user experience faster with the Zimbra Web Client. We’ve talked about Jetty, YUI compression, and Lazy Loading, but now there’s just one burning question: Which browser is fastest? There’s some amazing […]

]]> By: Conrad http://www.zimbrablog.com/blog/archives/2007/03/lazy-loading.html#comment-313 Conrad Wed, 04 Apr 2007 09:18:20 +0000 http://www.zimbrablog.com/blog/archives/2007/03/lazy-loading.html#comment-313 Actually, that's exactly what we do. Almost all our SOAP requests to the server are sent asynchronously (check the code for calls to the function sendRequest(), and you'll see the parameter 'asyncMode' is set to true). That happens through a set of classes which wrap XHR and provide support for a reusable pool of request objects, fault handling, timeouts, etc. For loading code we use a very thin wrapper around XHR and issue requests synchronously. Actually, that’s exactly what we do. Almost all our SOAP requests to the server are sent asynchronously (check the code for calls to the function sendRequest(), and you’ll see the parameter ‘asyncMode’ is set to true). That happens through a set of classes which wrap XHR and provide support for a reusable pool of request objects, fault handling, timeouts, etc.

For loading code we use a very thin wrapper around XHR and issue requests synchronously.

]]> By: Zuhair Naqvi http://www.zimbrablog.com/blog/archives/2007/03/lazy-loading.html#comment-312 Zuhair Naqvi Wed, 04 Apr 2007 00:22:32 +0000 http://www.zimbrablog.com/blog/archives/2007/03/lazy-loading.html#comment-312 That sounds refreshing wish you all the best with the code clean up. However, the application is not lazy only at the start up it is slow in over all working, like when I click on something, it halts the entire script for a few seconds. My analysis tells me that the real reason for laziness is not the way code is loaded but the way data is: Generally in XHR mechanism you have two options in the send command you can either keep the communication asynchronous or you may keep it synchronous. I suggest that you load the code synchronously but load the data asynchronously this will save a lot of script memory and keep data loading separate from code loading in a running script That sounds refreshing wish you all the best with the code clean up. However, the application is not lazy only at the start up it is slow in over all working, like when I click on something, it halts the entire script for a few seconds. My analysis tells me that the real reason for laziness
is not the way code is loaded but the way data is:

Generally in XHR mechanism you have two options in the send command you can either keep the communication asynchronous or you may keep it synchronous. I suggest that you load the code synchronously but load the data asynchronously this will save a lot of script memory and keep data loading separate from code loading in a running script

]]> By: James Burke http://www.zimbrablog.com/blog/archives/2007/03/lazy-loading.html#comment-311 James Burke Mon, 02 Apr 2007 22:03:53 +0000 http://www.zimbrablog.com/blog/archives/2007/03/lazy-loading.html#comment-311 Expanding on Brad Neuberg's comment: Dojo does use script tags for cross-domain (xdomain) loading. A custom build of the modules are done to wrap the module code in a function so that the module code does not execute immediately on load. Then, Dojo's resource loader orders the module dependencies correctly, then calls the functions to define the modules. This is how we are able to host all of Dojo's modules on a CDN to allow anyone to use them without having to download Dojo to their server. The Dojo build system also supports "layered" builds now too, where you can bundle up a set of modules into one file, for faster load time. Debugging with using an XHR-based loader: If you have an "onload" registration mechanism (Dojo has dojo.addOnLoad()), and a dojo.provide()-like method call to inform you when a module loads, then you can use XHR to map the module dependencies, then use script tags to attach one script at a time. When you get your "module loaded" call (in Dojo, it is dojo.provide() is used), set a timeout to load the next module in the dependency graph. A timeout is used to make sure the whole script file has been evaluated before adding the next script tag, since the dojo.provide() calls are normally at the top of the files. That is the approach Dojo's xd loader takes when trying to debug local/same domain modules (which are loaded via XHR). The caveat with that sort of debugging model: you cannot rely on the modules loading synchronously, so you need your code in your top-level page to wait to be called back when all the modules are loaded. dojo.addOnLoad() is used in the Dojo case. Expanding on Brad Neuberg’s comment:
Dojo does use script tags for cross-domain (xdomain) loading. A custom build of the modules are done to wrap the module code in a function so that the module code does not execute immediately on load. Then, Dojo’s resource loader orders the module dependencies correctly, then calls the functions to define the modules. This is how we are able to host all of Dojo’s modules on a CDN to allow anyone to use them without having to download Dojo to their server.

The Dojo build system also supports “layered” builds now too, where you can bundle up a set of modules into one file, for faster load time.

Debugging with using an XHR-based loader:
If you have an “onload” registration mechanism (Dojo has dojo.addOnLoad()), and a dojo.provide()-like method call to inform you when a module loads, then you can use XHR to map the module dependencies, then use script tags to attach one script at a time. When you get your “module loaded” call (in Dojo, it is dojo.provide() is used), set a timeout to load the next module in the dependency graph. A timeout is used to make sure the whole script file has been evaluated before adding the next script tag, since the dojo.provide() calls are normally at the top of the files. That is the approach Dojo’s xd loader takes when trying to debug local/same domain modules (which are loaded via XHR).

The caveat with that sort of debugging model: you cannot rely on the modules loading synchronously, so you need your code in your top-level page to wait to be called back when all the modules are loaded. dojo.addOnLoad() is used in the Dojo case.

]]> By: Brad Neuberg http://www.zimbrablog.com/blog/archives/2007/03/lazy-loading.html#comment-310 Brad Neuberg Wed, 28 Mar 2007 17:46:53 +0000 http://www.zimbrablog.com/blog/archives/2007/03/lazy-loading.html#comment-310 No prob not adopting Dojo's package system, but Dojo supports the idea of a package being a collection of files as well as a single file. For exmaple, you could say: dojo.require("dojo.off.*"); which will get all of the files comprising the Dojo Offline system. Or you could do: dojo.require("dojo.sync"); which would just get the sync.js file (neither of these are available yet, btw, until Dojo Offline is finished in a few weeks). Dojo does do XHR, but that is because you have no control over the order of how SCRIPT tags load -- what happens if you have 5 packages across 5 different script tags, with dependencies, and they load out of order? With XHR, Dojo can enforce that they are loaded in the correct order. Best, Brad Neuberg No prob not adopting Dojo’s package system, but Dojo supports the idea of a package being a collection of files as well as a single file. For exmaple, you could say:

dojo.require(”dojo.off.*”);

which will get all of the files comprising the Dojo Offline system. Or you could do:

dojo.require(”dojo.sync”);

which would just get the sync.js file (neither of these are available yet, btw, until Dojo Offline is finished in a few weeks).

Dojo does do XHR, but that is because you have no control over the order of how SCRIPT tags load — what happens if you have 5 packages across 5 different script tags, with dependencies, and they load out of order? With XHR, Dojo can enforce that they are loaded in the correct order.

Best,
Brad Neuberg

]]> By: Conrad http://www.zimbrablog.com/blog/archives/2007/03/lazy-loading.html#comment-309 Conrad Tue, 27 Mar 2007 17:12:08 +0000 http://www.zimbrablog.com/blog/archives/2007/03/lazy-loading.html#comment-309 Sorry, they didn't make it into 4.5. They're slated for 5.0, which is scheduled for Q3/Q4 (it's our next major release). Of course, they're available in the open source download if you want to check them out. Sorry, they didn’t make it into 4.5. They’re slated for 5.0, which is scheduled for Q3/Q4 (it’s our next major release). Of course, they’re available in the open source download if you want to check them out.

]]> By: Bart http://www.zimbrablog.com/blog/archives/2007/03/lazy-loading.html#comment-308 Bart Tue, 27 Mar 2007 11:29:49 +0000 http://www.zimbrablog.com/blog/archives/2007/03/lazy-loading.html#comment-308 Sounds great! :) In what version will these changes be made available? Or are they already in 4.5? Thanks a lot! Sounds great! :) In what version will these changes be made available? Or are they already in 4.5?

Thanks a lot!

]]>