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

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

> >> I'll assert that the primary use case for JS interacting with HTML
> components ought to be 'works well with JS modules'.
>
> You can happily define modules in your imports, those two systems are
> friends as far as I can tell. I've said this before, I've yet to hear the
> counter argument.
>

Yes indeed. Dimitri was asking for a better solution, but I agree that both
are feasible and compatible.


>
> >> But if you believe in modularity for Web Components then you should
> believe in modularity for JS
>
> Polymer team relies on Custom Elements for JS modularity. But again, this
> is not mutually exclusive with JS modules, so I don't see the problem.
>

Steve's example concerns synchrony between <script> and <link
rel='import'>. It would be helpful if you can outline how your modularity
solution works for this case.


>
>
> >> 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 busines
>
> I believe you are making assumptions about the nature of link and async.
> There are ways of avoiding this problem,
>

Yes I am assuming Steve's example, so again your version would be
interesting to see.


> but it begs the question, which is: if we allow "Expressing the dependency
> in JS" then why doesn't 'async' (or 'sync') get us both what we want?
>

I'm not arguing against any other solution that also works. I'm only
suggesting a solution that always synchronizes just those blocks of JS that
need order-of-execution and thus never needs 'sync' or 'async' and which
leads us to unify the module story for the Web.

jjb


>
> Scott
>
> On Mon, Nov 18, 2013 at 2:58 PM, John J Barton <
> johnjbarton@johnjbarton.com> wrote:
>
>>
>>
>>
>> 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
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>