>> 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 <bkard...@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? > > >