Re: Executing script-inserted external scripts in insertion order

?> Legacy behavior is often illogical.

If we agree that something is illogical, doesn't that make it a good place 
to start in terms of fixing things to be logical in a future revision of the 
spec?

Moreover, you haven't supported by you suggested we are "hacking around with 
async" -- indeed, I think we're doing the opposite of "hacking around" but 
instead are trying to directly address a short-falling of the current spec 
with a solution that narrowly fixes a specific use-case.


> As well as being declarative, the waitFor proposal also supports more
> use cases than the other proposal because it doesn't force a linear
> dependency graph.

The reason I'm in favor of the `async` approach as opposed to "waitFor" or 
several other possible solutions discussed so far is because I think it 
satisfies the use-case while fitting the principle of least effort -- it's a 
narrow fix for a specific use-case.

I'm not suggesting that the non-linear dependency graph you suggest is 
invalid, but it's not what anyone so far in the thread has been asking for. 
I think there'd be a burden-of-proof on someone to show why the more 
complicated solution is necessary and the current more simple solution is 
insufficient.

*Could* LABjs use behavior like to solve what it needs to do? Perhaps. But 
it's definitely more complicated than what I'm pushing for. LABjs currently 
addresses the need to have non-linear dependency by telling its users to 
just use separate independent $LAB chains. For the proposal I've pushed for, 
it means basically that the decision to use `async=false` type behavior for 
order enforcement would be available per-chain, which would let LABjs users 
do pretty much any kind of loading behavior they're likely to need. There 
may be some really niche corner-cases not served, but it's not something 
that I've seen needed in any practice thus far.

--Kyle

Received on Monday, 18 October 2010 06:08:45 UTC