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