enhancement: script callback about labjs HOT 7 CLOSED

I appreciate your time to explain your request for LABjs. I'm not really sure this use-case fits cleanly onto the intended API philosophy for LABjs. What you're asking for is a valid, but rather niche, use-case, which is two separate scripts that:

1. have a common script (or scripts) as dependencies in the upstream of the chain; AND
2. download in parallel; AND
3. execute in first-come-first-served order; AND
4. each has a different set of coupled-code that should execute after it finishes

It's specifically #4 which throws the wrench into the general design philosophy of LABjs, which is to organize trees of loading logic into separate, single-path branches (chains). Because you're basically trying to create a conditional-branching path chain with coupled code execution.

In LABjs' design philosophy (and achieving by default the maximum parallel loading performance), you can have 1+2+3 or 2+3+4, but not really 1+2+3+4.

1+2+3:
$LAB.script("a.js").wait()
.script("b.js")
.script("c.js")
.wait(...);

2+3+4:
// notice, no upstream "a.js" dependency
$LAB.script("b.js").wait(init_b); // these are totally separate chains, and thus execute first-come-first-served
$LAB.script("c.js").wait(init_c);

So, how do we get 1+2+3+4:
$LAB.script("a.js").wait(function(){
$LAB.script("b.js").wait(init_b); // these are totally separate chains
$LAB.script("c.js").wait(init_c);
});

This will work ok. BUT, it has the disadvantage that b.js and c.js will not be downloading in parallel with a.js. So, you lose some performance with that pattern. So that's the caveat with the 1+2+3+4 niche of use-cases.

Also of note... some browsers (FF, Opera) do not support the use-case of first-come-first-served execution , if any of the scripts are remote, without exceptional hacks (extreme brittle cache preloading) that LABjs does not employ. So this feature use-case would be irrelevant (meaning "b.js" would ALWAYS execute before, and thus block execution of, "c.js") for users in those browsers in that case. In general, I don't design a functionality unless it can reasonably be supported cross-browser.

The question remains... should I extend (and complicate) LABjs to support this use-case (for IE/Webkit)? In general, I'm leaning toward "no". I think it's a rarer use-case in the broad scope of things, with the additional negative of being limited to only some browsers. Simplicity of code (leads to smaller, faster loading code) and simplicity of API design call for minimalism and for trying to serve, generally, the majority use-cases.

This is all to say, it's not an outright no, but I'd have to be more convinced that the use-case is less niche than it seems to me at the moment. I'd have to be convinced that the performance degradation of the workaround I provided is worse than the extra baggage of baking this natively into LABjs. If you find more concrete examples of why this is a necessary addition, please do share.

from labjs.

As i see it, this use case is fairly common. not niche at all. lets put some realworld names on this thing.

a.js: jquery-1.5.2.js
b.js: somecaoursel_or_slider.jquery.js
c.js: lightbox.jquery.js

b.js depends only on a.js
c.js depends only on a.js

i have multiple pages, most using lightbox and slider/carousel on same page. this is the scenario the example proceeds with.

on each of these pages, it is different elements that needs to be activated with the slider and lightbox, in addition, there are callbacks for various events of the sliders/lightbox(IE user cclicks on carousel, or views a lightbox, for whatever reason). The callbacks are also different on a pr-page basis

features of a.js are framework, all my javascript depends on it.

I extend a.js with b.js and c.js to give additional features

b.js and c.js adds unique and separate features. these all have equal importance on my pages.
b.js and c.js are upstream features, meaning, they are found on CDNs and all sorts of stuff, thousands are using them.

my choices as of now are these:

1:
load a.js, block until done
load b.js, c.js, block until done, execute my code that initiates b.js and c.js features.

this way, they will both be activated simultaneously, however, this also means that one of the features will inevitably be waiting for the other.

2:
load a.js, block until done
load b.js, block until done, load my initiate code
load c.js, block and load initiate code.

i have manually decided which feature is most important, and which will be loaded and run first.

I could also combine my initiate code with the b.js and c.js directly, but that would lead to multiple copies for each page, and as far as i see, only downsides compared to 1 and 2.

so my proposal is alterations so that i can add a callback for each script that is executed, and a method of specifying equal priority scripts.

As to how much realworld performance is gained, i cannot say, however, this is a scenario that hits nearly all jquery/mootools etc using sites, also, the fact that as of now, things are done in a way that screams "suboptimal", which to me is very unappealing

from labjs.

Hmm, couldnt this possibly be solved for the hosting-yourself case, by xmlhttprequest the items, and then eval them?

from labjs.

In your scenario, you didn't address why "slider.js" and "lightbox.js" have to be able to be initialized in "first-come-first-served" order... that's the specific part that I think makes your use-case more niche.

LABjs will in fact run the files themselves in that fastest-first order (in IE/Webkit), if you do:

$LAB
.script("jquery.js").wait()
.script("slider.js")
.script("lightbox.js")
.wait(function(){
    init_slider();
    init_lightbox();
 });

But they won't initialize until both of them are ready to initialize. You still however get the most benefit out loading your scripts in parallel (all 3 will load in parallel), and the only tradeoff is that the initialization of one of the plugins may be held up until both are ready to initialize.

But, I'd argue this is better UX in general, for end users, rather than to have part of the page initialize but another part of the page be still unusable. When I go to sites like that, it's frustrating to me.

Keep in mind: LABjs' simple design goal is to make loading and executing of scripts as fast as possible (for the general case). It's not so much about making scripts run as soon as humanly possible.

If two scripts really are completely independent, you can achieve complete separation by doing the separate chains. If they're not independent, then I think it's more trouble than it's worth (from the code and API perspective) to support this mixed mode where there's sort of run-time conditional dependencies within the chain.

As stated before, the other possible tradeoff to make is:

$LAB
.script("jquery.js").wait(function(){
    $LAB.script("slider.js").wait(init_slider);
    $LAB.script("lightbox.js").wait(init_lightbox);
 });

That basically accomplishes what you want, except that the plugins wait to download until after jquery loads.

I think either of those two (while a slight compromise performance wise) is a decent concession/work-around while preserving the design philosophy of the LABjs API.

Hmm, couldnt this possibly be solved for the hosting-yourself case, by xmlhttprequest the items, and then eval them?

Yes, you can easily accomplish it with XHR, if all the scripts in question are local. However, LABjs is focused on the general case, where some or all scripts come from remote locations. As such, it has to assume that it may not be able to use XHR.

I generally don't design a feature for LABjs that only works if you happen to choose all your scripts to be local, because all the other people who use LABjs where some scripts are not local don't benefit from the feature, and in fact, in some cases, a feature may outright not work for them. So, I only consider features which have reasonable behavior for the general "worst-case" type scenario.

from labjs.

the xmlhttprequest comment was more of a curiosity question, i also think its bad to have it work only local.

essentially, i dont think this is bad for usability. consider the things its doing here, a slider or carousel, theres no reason one shouldnt start as soon as its done.

i am well aware of the options you mention for doing this, and it is indeed the only way i see of doing it now, allthough i would prefer to do it in the way i specified. nevertheless, if you feel its too much of a hassle for too little good, then okay

from labjs.

i just don't think the value outweighs the cost... yet. but i may be convinced otherwise if i see more use-cases.

from labjs.

this will likely not make it in for 2.0, as i still have doubts about the value compared to the extra script complexity. but i will revisit the topic after 2.0 is stable. closing for now, will re-examine later.

from labjs.