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

> I don't see this solution scaling at all.
>
> Imports are a tree. If you have any import that includes any other import,
> now the information about what tags to "wait" for has to be duplicated
> along every node in that tree.
>
> If a library author chooses to make any sort of "all-in-one" import to
> reduce network requests, they will have an absurdly huge list.
>
> For example:
>
> Brick
>
> <link rel="import" href="brick.html" elements="x-tag-appbar x-tag-calendar
> x-tag-core x-tag-deck x-tag-flipbox x-tag-layout x-tag-slidebox
> x-tag-slider x-tag-tabbar x-tag-toggle x-tag-tooltip">
>
> or
>
> Polymer
>
> <link rel="import" href="components/polymer-elements.html"
> elements="polymer-ajax polymer-anchor-point polymer-animation
> polymer-collapse polymer-cookie polymer-dev polymer-elements
> polymer-expressions polymer-file polymer-flex-layout polymer-google-jsapi
> polymer-grid-layout polymer-jsonp polymer-key-helper polymer-layout
> polymer-list polymer-localstorage polymer-media-query polymer-meta
> polymer-mock-data polymer-overlay polymer-page polymer-scrub
> polymer-sectioned-list polymer-selection polymer-selector
> polymer-shared-lib polymer-signals polymer-stock polymer-ui-accordion
> polymer-ui-animated-pages polymer-ui-arrow polymer-ui-breadcrumbs
> polymer-ui-card polymer-ui-clock polymer-ui-collapsible polymer-ui-elements
> polymer-ui-field polymer-ui-icon polymer-ui-icon-button
> polymer-ui-line-chart polymer-ui-menu polymer-ui-menu-button
> polymer-ui-menu-item polymer-ui-nav-arrow polymer-ui-overlay
> polymer-ui-pages polymer-ui-ratings polymer-ui-scaffold polymer-ui-sidebar
> polymer-ui-sidebar-header polymer-ui-sidebar-menu polymer-ui-splitter
> polymer-ui-stock polymer-ui-submenu-item polymer-ui-tabs
> polymer-ui-theme-aware polymer-ui-toggle-button polymer-ui-toolbar
> polymer-ui-weather polymer-view-source-link">
>
>
That's tad hyperbolic Other Daniel (I kid, I kid), you could just as soon
use an "all" value to block until all custom elements were ready. The
blocking-tag-name-list may be a poor idea, I have no illusions otherwise -
I don't even like it! --> To be honest, I believe all these one-off
deviations from developer expectations are the wrong answer. I'd much
rather stick with a sync loading import that offered an 'async' attribute
to force async loading, regardless of whether a script tag came after it or
not.

How about we review the use-cases again to get our bearings:

   1. Loading a bundle custom elements for the page
   2. Loading just custom elements required for the first view and load the
   rest async
   3. Loading template elements for use in the page's lifecycle
   4. Loading a random HTML file for random uses

#1 is probably going to be the most common use-case. Regardless of what you
elect to do with load juggling, developers are going to do whatever they
need to to ensure they aren't FUC'd. Hell, if you shake that beehive
enough, they'll just start using a <script> to sync load
document.register() declarations. This is not optimal, the best
practice/solution should be to sync load only the assets/declarations that
are vital to the first render.

#2 Yay, developers split their imports between two link tags, one
containing the tags required for first render, and another with everything
else they don't need until later. If we offered devs an easy way to choose
between sync/async imports, it would afford them good ergonomics and good
perf (for most use-cases in this sphere). How feasible is this? How often
will devs take our advice and do it? Not sure, I guess it would depend on
how hard we push import best practices.

#3 This will be a super common use-case - devs will do this even when they
aren't using Custom Elements. The issue here is much like the one present
in case #1 - how likely are devs to split their template imports into two
tags, one for first render and one for the rest?

#4 I really have no idea how often devs using imports will use it to load
random HTML files, but I'd venture this use-case generally will not depend
on synchronous import loading.

Those (imo) are the primary use-cases we're dealing with. Can we focus on
making things transparent and not burdening the most common case among them?

As for JJB's assertion that "most apps will turn this problem over to the
design team rather than cause users to leave while the browser spins
waiting for the page to render." - I couldn't disagree more, this is a
fantasy (no offense intended). Just survey many of the most popular apps on
any platform - they spin you until the assets and code are ready to show
the first screen.

- Daniel