W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2014

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

From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Thu, 18 Sep 2014 15:13:34 -0700
Message-ID: <CABZUbM1XGFfGzdrcCGYHNgeWg3YkrKG5gBPoZ9qmCjR6bb_Rcg@mail.gmail.com>
To: Kyle Simpson <getify@gmail.com>
Cc: whatwg@lists.whatwg.org
On 8/23/14, Kyle Simpson <getify@gmail.com> wrote:
>> Surely our goal should be to make script loaders unnecessary.
>
Complexity is best avoided, sure.

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

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

I'm not really interested in arguing the validity of that premise that
one way or the other.

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

Lets not make the advertisement against the `needs` attribute
proposal. And to be fair, that is really my 2009 "depends" Chain of
Responsibility proposal, renamed.

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

That accomplishes powerful things simply.

Should be useful with HTML imports:--

<link rel="import" href="footer.html" id="footer-import" async>
<script src="footer.js" needs="footer-import" async>

Load the footer html and js, don't block, but make sure that the HTML
is loaded before the script.


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

Popular and ever burgeoning libraries that use script loaders.

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

> 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."
>
>
What if the goal is to simplify dependency loading using
declarative-based chain-of-responsibility pattern for  common cases?

It realize you don't like it. But if you think about it, goals to make
things unnecessary aren't necessarily wrong, even if the thing to be
made unnecessary is still, in some cases, needed. Particularly if the
thing to be aimed toward obsolescence is in someways costly or
detrimental.
-- 
Garrett
@xkit
ChordCycles.com
garretts.github.io
Received on Thursday, 18 September 2014 22:13:58 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:23 UTC