[dev] Javascript depency loading

[Michael M Slusarz]

Quoting Jan Schneider <jan at horde.org>:

> I already had a short discussion with Michael Rubinsky on IRC two  
> weeks ago, and two events reminded me about it: The necessary fixes  
> to correctly load tooltips.js and the required prototype.js, and  
> Ajaxian mentioning LABjs (http://labjs.com/description.html) again.
>
> Here's the IRC log:
>
> (18:04:12) yunosh: is it worth to use a depency loader like  
> http://feedproxy.google.com/~r/ajaxian/~3/Vq4qcO7idLI/labjs-simple-abstraction-for-loading-dependencies-correctly to solve the js file loading order  
> issues?
> (18:17:21) mrubinsk: yunosh: looks interesting, though I guess we'd  
> need to test to see if it would work well with pages that might have  
> had the same js file added via Horde::addScriptFile() in other  
> places....or were you talking as a general solution to implement  
> within Horde::addScriptFile()?
> (18:18:57) yunosh: rather something to replace addScriptFile(), or  
> actually something that's build from addScriptFile() instead of  
> plain <script> writing. That would require dependency support on the  
> php side too of course
> (18:19:03) yunosh: just brainstorming here
> (18:20:47) mrubinsk: sounds like it's worth looking into more  
> thoroughly then...
> (18:22:05) yunosh: i'm not sure if it's adding more overhead than  
> necessary for things that we can sort out manually with a bit of  
> patience
> (18:29:09) mrubinsk: yea, it's also not clear how well it would  
> behave with adding scripts in multiple paces in the code
> (18:29:56) mrubinsk: at least from my cursory look :)
>
> I want to re-start this discussion because such a solution could not  
> only help us solving the dependeny issues, but also speed up page  
> loading. Beside that, we could load more script files directly from  
> JS code on-demand. The latter would keep the after-loaded scripts  
> from using our JS cache, but it might be worth for some rarely used  
> scripts, and it's an added bonus anyway.

My thoughts:
1.) There is (should be) no dependency issues.  *Everything* requires  
prototype.js to be loaded first.  After that, it doesn't matter the  
order the files are included.  If there is, then the script is broken  
and needs to be fixed (all initialization should be done in a domload  
event handler - this eliminates all issues with dependencies).

2.) I am against adding another layer of complexity on the browser  
side.  To me, lazy loading scripts is of dubious value, and of even  
less value in a framework environment.  I could potentially see the  
benefit if you control the entire page and can tweak every element in  
that page.  But once you start using framework elements to build the  
vast majority of your page, it is just adding too many layers of  
complexity.

3.) By the time caching/gzipping/code compression is factored in, the  
actual load time should be fairly slight, especially for pages (such  
as dimp) that only need to load this stuff once a session.  So  
delaying loading is not going to speed things up considerably.

4.) That being said, the next optimization is going to be to break out  
prototype.js into a separately served cache file.  Since every page  
uses it, it can be cached against all horde pages which more than  
makes up for the extra HTTP request needed to check its cache status.   
Along those same lines, it might be possible to do this for horde CSS  
also - although the CSS should remain the same for all pages in a  
single application so there's not as much of a benefit to do this.

michael

-- 
___________________________________
Michael Slusarz [slusarz at horde.org]