Re: [whatwg] Preloading and deferred loading of scripts and other resources

> 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

Received on Saturday, 23 August 2014 14:29:47 UTC