> 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