> Surely our goal should be to make script loaders unnecessary.

There's unquestionably a lot of folks on this thread for whom that is their 
main concern. I think it's a mistake to assume that because they mostly seem to 
be working as browser developers (which strongly influences their perspective, 
I believe) that this is a universal goal.

In fact, I would say I have the opposite goal. I currently, and have always 
(for the 3-4 years this discussion has been languishing), wanted to make script 
loaders better and more capable, not get rid of them.

Two primary reasons:

1. A "hand-authorable markup only" (aka "zero script loaders") approach is, and 
always will be, limited. Limited to what? To the initial page load.

A significant portion of the discussion in the long and sordid history of this 
thread of discussion is indeed centered around browsers wanting to optimize 
markup loading using their pre-scanner, etc.

There's a strong implied assumption that zero-script-loader 
hand-authored-markup-only page-load-only script loading is the most important, 
and in fact the only important, concern. I have registered already many times 
my strong objection to this mindset.

Originally, my participation in the thread, and my many proposals and 
variations along the way, actually didn't really care nearly as much about this 
initial page-load case. But let me clarify: it's not that I don't care about 
initial page-load at all, but that I care *more* (much more, in fact) about 
enabling and making easy-to-use dynamic in-page on-demand loading use-cases.

The proposals I made for improving that usage also degrade to letting the same 
script loader logic handle the initial page-load using the same mechanisms.

IOW, my focus is on on-demand loading capabilities, via a script loader, and 
the initial-page-load script loading (via script loader) is a simple degraded 
base-case for the same capabilities.

The reverse is not true. The hand-authored-markup-only solutions being proposed 
largely don't care at all about the script loaders use cases, and certainly 
don't degrade in any reasonable way to improving the outlook for dynamic script 
loading (see the initial quote above). In fact, they sometimes make those use 


Because the markup-only solutions make lots of assumptions that don't apply to 
on-demand loading, such as "availability of DOM elements", "order of parsing", 
etc. Some of the concerns have analogs in script loading logic, but they're 
awkward and inefficient from the script loader point of view.

The majority of markup-focused solutions thus far proposed favor 
hand-authored-markup-only, and seem unconcerned by the fact that they will make 
the on-demand script loader use-cases harder.

For example:

var s1 = document.createElement("script");
s1.id = "some-id-1";
s1.src = "http://some.url.1";;

var s2 = document.createElement("script");
s2.id = "some-id-2";
s2.src = "http://some.url.2";;
s2.needs = s1.id;

var s3 = document.createElement("script");
s3.src = "http://some.url.3";;
s3.needs = s1.id + "," + s2.id;

document.head.appendChild(s3); // append in reverse order to make sure `needs` 
is registered early enough

This is a super simple distillation of generated script loader logic to load 3 
scripts, where 2 needs 1, and 3 needs both 1 and 2. If you author JS code like 
this by hand, it seems somewhat tractable.

But, as the chains get longer (more scripts) and the dependencies get more 
complex, this becomes increasingly difficult (in fact, approaching 
impossible/impractical) to actually generate via a generalized script loader.

Why? Because the script loader has to know the entire list of scripts (IOW it 
needs to make its own internal queue/s) in this group, before it can reason 
about how to generate the ID's and wire up the attributes.

By contrast, most good script loaders right now that take advantage of the 
`async=false` internal browser loading queue can start loading in 1->2->3 order 
in a streaming fashion, not having to wait for all 3 to start. Why? Because the 
`async=false` loading queue that the browser provides implicitly handles the 

The result? Current script loaders can load 1. Then later 2. Then later 3. And 
regardless of how long or short "later" is, or of how quickly things load, or 
if all 3 are indeed loaded "at the same time" -- in all these variations, the 
queue the browser provides just makes the loading/ordering work.

The proposals being suggested actively do away with that assistance, in favor 
of making authors manage their own "queues" via chains of selectors, in markup.

Which leads to…

2. There is, intuitively, some threshold of complexity of markup beyond which 
most hand-authors will not go.

They may author:

<script src="http://some.url.1"; async id="s1">
<script src="http://some.url.2"; async needs="s1">

But, most probably would never author:

<script src="http://some.url.1"; async id="s1">
<script src="http://some.url.2"; async id="s2" needs="s1">
<script src="http://some.url.3"; async id="s3">
<script src="http://some.url.4"; async id="s4" needs="s2, s3">
<script src="http://some.url.5"; async id="s5" needs="s2">
<script src="http://some.url.6"; async needs="s3, s5">

No matter how good we are at inventing a markup syntax that handles all the 
script loading use-cases, only a simple subset of that will ever be 

The rest? YOU GUESSED IT!!! Will be handled by a "script loader". And by that, 
I don't just mean a script in the runtime, I mean some tool in the build 
process on the server that's generating markup that has to go through some 
manifest of dependencies and construct a tree and figure out all that 
interconnected markup and inject it.

As soon as we admit that such tools will exist, we're back to my (1) above, 
which is that "hand-authorable markup-only" is a false premise.

Markup solutions (for the simple cases), and script loaders (for the more 
complicated markup page-load AND for the on-demand script loading during page 
lifetime), must exist, if we're really going to handle everyone's script 
loading needs.

We can't just favor one and forget the other.

I dislike all the current markup-centric approaches because they do just that. 
And it's all summed up by the quote that I vehemently disagree with: "Surely 
our goal should be to make script loaders unnecessary."


Reply via email to