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

I believe the primary issue here is 'synchronous with respect to
rendering'. Seems like you ignored this issue. See Brian's post.

Scott


On Mon, Nov 18, 2013 at 5:47 PM, John J Barton
<johnjbarton@johnjbarton.com>wrote:

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