> So maybe a concept of optional dependency would be useful? > 1. not all dependencies are JS files, e.g. authors use plugins to load > template files, JSON, images, etc.
> 2. not all dependencies are usefully satisfied immediately after their JS > file is loaded, e.g. some libraries may need asynchronous initialization. These are relevant statements of other use-cases that are common. I just want to point out that my <script preload> proposal easily handles (via a script-based script loader, not markup-only) both of these use-case variations, no matter how deep you chase their rabbit holes. In my proposal, the script loader (or module loader, or whatever) is fully in control of when the next waiting script is told that it's eligible to execute, so it can accept any arbitrary amount of complexity into its configuration for how to decide that it's OK to proceed from A to B. For example, if, in the execution of A, A registers that it needs C, then B won't auto-run just because A finishes. If C is not a script, but is a template or stylesheet or series of images or Ajax call for some data or whatever... none of that complication affects the <script preload> mechanism whatsoever. It simply leaves "B" preloaded, paitiently waiting around until it's told that its dependencies are fulfilled, and the script loader can wait as long as it needs to until A and anything A needs (C, C*) are loaded and processed. In the <script dependencies> proposals and variations, we have to follow the rabbit trail of inventing micro-syntaxes or other attribute complexities to handle these markup expressions of dependency that are not as trivial/simplistic as "a prior completed network connection and, if applicable, parsing and processing", as you're seeing in Kornel's two messages. ***** Of course, I don't share the same mindset of some here that any markup-only solution we could invent, no matter how complex or intricate or involved, is better than a script-based equivalent. ***** To me, markup should be able to handle the majority case(s), and minority cases (while important) should be handled in script-based loading. <script preload> (including the markup extension I suggested) does exactly that: it handles basic preload/dependency annotation with markup-only, and it provides the full preload-defer-execute mechanism to the script-based loader for handling *everything* else you can dream up (AND you can mix-n-match). By contrast, the prior simple statement of <script dependencies=...> proposal (without Kornel's extensions) handles basic preload/dependency annotation in markup-only, but then the other more complex use-cases appear to have to be filled by pulling in and weaving together other (proposed) mechanisms like Navigation Controller. I'm not saying that's a bad option, but we need to be able to compare what the script-based approach is going to look in both scenarios, and see which one is more suitable/practical/desireable. --Kyle
