> 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
cases MUCH WORSE.
Why?
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
document.head.appendChild(s2);
document.head.appendChild(s1);
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
ordering.
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
hand-authored.
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."
--Kyle
