>> I'd say the first syntax is a bit verbose for what I was dreaming 4 years
>> ago when I started asking for a simple script preloading mechanism, but
>> it's just this side of acceptable. If we have to take the second approach,
>> I say that's unacceptably more verbose/complex and falls short of my
>> opinion of "everything we need for sane & versitile dependency loading".
> It's everything we need but perhaps not everything we desire.

If "everything we need" was the only standard, then the proposals we had 
discussed years ago should have been pushed through, years ago. Those 
discussions were bogged down because, as you say in the next sentence (quoted 
below), there were some on this list who insisted that mechanisms which 
couldn't be markup-only were insufficient, not just undesirable.

For my part, I hope our current discussion thread is signaling a shift from the 
previous dogmatism (on all sides).

> Last time we
> went round with script loading the proposal for high-level dependency
> declaration got weighed down by use-cases that should have been left to
> lower level primitives. These are the lower level bits, something higher
> level is still possible. For legacy-free project, modules + promises for
> non-script assets are the answer.

It was never a priority of *mine* to support zero-script-loader capability. I 
think, and always have, that script loaders are the place where logic for 
anything beyond straight-forward loading *should* occur.

But there was clearly a LOT of noise in the past whenever I pointed out 
advanced use-cases, and this noise led to suggestions about markup-only 
(zero-script-loader) mechanisms for handling all or most of the use-cases in a 
way that theoretically could eliminate any need for script loaders. Recall all 
the discussions of `depends='...'` attributes being able to annotate one 
script's dependencies on another script or scripts?

I was only trying to call out the fact that there had been a very clear 
intention in the past to get some silver-bullet solution that implies 
zero-script-loader, and what we're currently discussing (.loaded() promises) is 
NOT that.

If we are, at this point in the years-long arc of discussion, ready to set that 
requirement aside, and admit that markup capabilities (<link rel=preload> and 
<script>) are for the straight linear a->b->c use-cases, and that the more 
sophisticated use-cases (like dynamic loading, independent widgets, etc etc) 
require logic that belongs in some form of "script loader" (whether a lib or a 
set of inline boilerplate code) that handles all the promises-negotiation, then 
I'm fine with that approach. I say "fine" relatively, because I don't really 
like the ugliness if we have to ensure order ourselves (maybe we don't!?), but 
it's not a deal-breaker either way.


Reply via email to