[dev] Javascript depency loading

[Jan Schneider]

Zitat von Michael M Slusarz <slusarz at horde.org>:

> 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).

This is not quite true. There is also date.js which is required in  
Kronolith, and soon by the date picker widget, but nothing else (yet).  
date.js requires a locale js file to be loaded first. That means that  
any place that is going to use the date picker must take care of  
loading 3 different js files in the correct order, including a  
variable file name that's going to be injected from the outside.
And I can imagine that we are going to load more js libraries in the  
future that might be the base for other js files. Think of any widget  
depending on scripty. We don't want to load scripty on every page.
We *do* have dependency issues and we have to solve them somewhere.  
This could of course completely be done in PHP, LABjs or similar is  
just one possible solution.

> 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.

I think that lazy loading is just a side-effect of a js loading  
library, I'm not sure we would have any use for it. Probably not.

> 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.

It would still speed things up for the initial load, but again, this  
is just a side-effect and not that important.

> 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.

That sounds good, but doesn't fix the original problem with dependencies.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
URL: <http://lists.horde.org/archives/dev/attachments/20090730/c595be2c/attachment-0001.bin>