[Javascript] Organizing onload events

[paul at juniperwebcraft.com (Paul Novitski)]

At 9/22/2006 08:06 AM, Triche Osborne wrote:
>The more I use unobtrusive methods, the longer my external onload 
>script gets and the more often I run into situations where I have 
>events that are only required for given pages. Is it standard 
>practice to include all of these event attachments in a single file 
>which is loaded for every page, regardless of whether the page needs 
>the script (and the overhead), or do you tailor the scripts to a 
>given page or section?
>         Also, what of scripts that require arguments for the 
> functions called by the attached events? Example: an optional popup 
> function that requires the pathname, width and height of the image 
> it is to display. Since I'm often creating these pages via PHP and 
> want to keep them as simple as possible for the end-user to style, 
> I've thought of assigning a class="popup" and coded ID to the 
> thumbnail (something like id="img12345678-300-400").
>         This seems awkward, but so does writing out an associative 
> multi-dim array for the page's affected elements. (Since the event 
> may or may not need to be attached, depending on whether there is 
> an enlargement available, I can't just grab all IMG children within 
> the item DIVs.)


Hi Triche,

This is a really great question. and I hope the responses reflect the 
richness of the topic.

One of the cool things about javascript, like PHP and some other 
scripting languages, is that you can test whether a function already 
exists -- if (!jsDoSomething) -- and load it as needed, analagous to 
DLL architecture.  I imagine this would only be practical when the 
optional functions were quite large, to justify the necessarily long 
time it takes to load anything of any size from an internet server, 
but the mechanism is there for when we need it.

The primary trade-off seems to concern cache:  if you can tolerate a 
long initial load, then the big js file is in cache and won't be 
loaded again (until the user clears their cache or explicitly reloads 
the browser content).  If you break your script down into many 
smaller parts and load them as needed, then you distribute the 
response time lag more evenly over the experience of browsing the 
site.  Which way you go on any given project will depend on a dozen 
variables, including your expectation of how long (for how many 
page-views) an average user is likely to stay and how big "big" is, 
even on dial-up.

With regard to your suggestion of img id="img12345678-300-400" you 
should remain aware of the relationship between markup and behavior 
and of your presumed desire to separate the two.  The more details 
you hard-code into your markup, the less separable it is from your 
script.  I'd recommend writing generic markup with ids & classes and 
generic behavior in javascript, then joining them together with 
datasets that contain the specifics.  That way you are much more 
likely to be able to modify the markup or the behavior or the data 
without necessarily having to tweak all three at once.   Project 
management will lighten accordingly.

Regards,
Paul