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

>> Scott, is that because of what I said above (why polymer has the exact
opposite desire)?

Yes. Plus some salt from the KISS principle.

>>  I feel like it is maybe valuable to think that we should worry about
how you express [dependencies] in JS

I guess I thought ES6 modules already went through all these issues. I'm
happy to let modules be The Way for handling JS dependencies. Imports can
provide an entree to modules *and* be a vehicle for my other stuff.

Scott

On Mon, Nov 18, 2013 at 3:56 PM, Brian Kardell <bkardell@gmail.com> wrote:

> Mixed response here...
>
> >> I love the idea of making HTML imports *not* block rendering as the
> default behavior
> In terms of custom elements, this creates as a standard, the dreaded FOUC
> problem about which a whole different group of people will be blogging and
> tweeting... Right?  I don't know that the current solution is entirely
> awesome, I'm just making sure we are discussing the same fact.  Also, links
> in the head and links in the body both "work" though the spec disallows the
> later it is defacto - the former blocks, the later doesn't.... I think.
>  This creates some interesting situations for people that use something
> like a CMS where they don't get to own the head upfront.
>
> > 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.
>
> Scott, is that because of what I said above (why polymer has the exact
> opposite desire)?
>
> >  if we allow "Expressing the dependency in JS" then why doesn't 'async'
> (or 'sync') get us both what we want?
>
> Just to kind of flip this on its head a bit - I feel like it is maybe
> valuable to think that we should worry about how you express it in JS
> *first* and worry about declarative sugar for one or more of those cases
> after.  I know it seems the boat has sailed on that just a little with
> imports, but nothing is really final else I think we wouldnt be having this
> conversation in the first place.  Is it plausible to excavate an
> explantation for the imports magic and define a JS API and then see how we
> tweak that to solve all the things?
>
>
>