Re: [HTML Imports]: Sync, async, -ish?

On Mon, Nov 18, 2013 at 2:33 PM, Scott Miles <sjmiles@google.com> wrote:

> >> I love the idea of making HTML imports *not* block rendering as the
> default behavior
>
> So, for what it's worth, the Polymer team has the exact opposite desire. I
> of course acknowledge use cases where imports are being used to enhance
> existing pages, but the assertion that this is the primary use case is at
> least arguable.
>

I'll assert that the primary use case for JS interacting with HTML
components ought to be 'works well with JS modules'. Today, in the current
state of HTML Import and JS modules, this sounds too hard. But if you
believe in modularity for Web Components then you should believe in
modularity for JS (or look at the Node ecosystem) and gee they ought to
work great together.


>
>
> >>  It would be the web dev's responsibility to confirm that the import
> was done loading
>
> Our use cases almost always rely on imports to make our pages sane.
> Requiring extra code to manage import readiness is a headache.
>

I think your app would be overall even more sane if the dependencies were
expressed directly where they are needed. Rather than loading components
A,B,C,D then some JS that uses B,C,F, just load the JS and let it pull B,
C, F.  No more checking back to the list of <link> to compare to the JS
needs.


>
> Dimitri's proposal above tries to be inclusive to both world views, which
> I strongly support as both use-cases are valid.
>

Dimitri's proposal makes the async case much more difficult: you need both
the link tag with async attribute then again you need to express the
dependency with the clunky onload business. Expressing the dependency in JS
avoids both of these issues.

Just to point out: System.component()-ish need not be blocked by completing
ES module details and my arguments only apply for JS dependent upon Web
Components.


>
>
> Scott
>
> On Mon, Nov 18, 2013 at 2:25 PM, Steve Souders <souders@google.com> wrote:
>
>> I love the idea of making HTML imports *not* block rendering as the
>> default behavior. I believe this is what JJB is saying: make <link
>> rel=import> NOT block <script>.
>>
>> This is essential because most web pages are likely to have a SCRIPT tag
>> in the HEAD, thus the HTML import will block rendering of the entire page.
>> While this behavior is the same as stylesheets, it's likely to be
>> unexpected. Web devs know the stylesheet is needed for the entire page and
>> thus the blocking behavior is more intuitive. But HTML imports don't affect
>> the rest of the page - so the fact that an HTML import can block the entire
>> page the same way as stylesheets is likely to surprise folks. I don't have
>> data on this, but the reaction to my blog post reflects this surprise.
>>
>> Do we need to add a "sync" (aka "blockScriptFromExecuting") attribute? I
>> don't think so. It would be the web dev's responsibility to confirm that
>> the import was done loading before trying to insert it into the document
>> (using the "import ready flag"). Even better would be to train web devs to
>> use the LINK's onload handler for that.
>>
>> -Steve
>>
>>
>>
>>
>>
>> On Mon, Nov 18, 2013 at 10:16 PM, John J Barton <
>> johnjbarton@johnjbarton.com> wrote:
>>
>>> Maybe Steve's example[1] could be on JS rather than on components:
>>>
>>> System.component("import.php", function(component) {
>>>   var content = component.content
>>>
>>> document.getElementById('import-container').appendChild(content.cloneNode(true));
>>> });
>>>
>>> Here we mimic System.load(jsId, success, error).  Then make <link> not
>>> block <script>: it's on JS to express the dependency correctly.
>>>
>>> jjb
>>>
>>>
>>> On Mon, Nov 18, 2013 at 1:40 PM, Dimitri Glazkov <dglazkov@google.com>wrote:
>>>
>>>> 'Sup yo!
>>>>
>>>> There was a thought-provoking post by Steve Souders [1] this weekend
>>>> that involved HTML Imports (yay!) and document.write (boo!), which
>>>> triggered a Twitter conversation [2], which triggered some conversations
>>>> with Arv and Alex, which finally erupted in this email.
>>>>
>>>> Today, HTML Imports loading behavior is very simply defined: they act
>>>> like stylesheets. They load asynchronously, but block <script> from
>>>> executing. Some peeps seem to frown on that and demand moar async.
>>>>
>>>> I am going to claim that there are two distinct uses of <link
>>>> rel=import>:
>>>>
>>>> 1) The import is the most important part of the document. Typically,
>>>> this is when the import is the underlying framework that powers the app,
>>>> and the app simply won't function without it. In this case, any more async
>>>> will be all burden and no benefit.
>>>>
>>>> 2) The import is the least important of the document. This is the "+1
>>>> button" case. The import is useful, but sure as hell doesn't need to take
>>>> rendering engine's attention from presenting this document to the user. In
>>>> this case, async is sorely needed.
>>>>
>>>> We should address both of these cases, and we don't right now -- which
>>>> is a problem.
>>>>
>>>> Shoot-from-the-hip Strawman:
>>>>
>>>> * The default behavior stays currently specified
>>>> * The "async" attribute on <link> makes import load asynchronously
>>>> * Also, consider not blocking rendering when blocking <script>
>>>>
>>>> This strawman is intentionally full of ... straw. Please provide a
>>>> better strawman below:
>>>> __________________
>>>> __________________
>>>> __________________
>>>>
>>>> :DG<
>>>>
>>>> [1]:
>>>> http://www.stevesouders.com/blog/2013/11/16/async-ads-with-html-imports/
>>>> [2]: https://twitter.com/codepo8/status/401752453944590336
>>>>
>>>
>>>
>>
>