An important point to keep in mind is that <link rel="import"> will delay rendering until it has loaded, reducing FOUC. However, If you want to lazy load portions of the page, you can use the "async" attribute on the relevant imports, and you'll have to handle the pop-in by yourself. The ":unresolved" css pseudo class will apply to any potential Custom Element candidate that has not yet upgraded, so you can use that to at least make some elements have the correct size before they are lazy loaded.
On Wed, Apr 16, 2014 at 9:54 AM, <[email protected]> wrote: > *tl;dr: Should we stop using XHRs to load content, and start having the > server output content directly with custom elements, which then get > processed with JS/Dart?* > > I've written a fair number of web "things" which you might call somewhere > between web "pages" and web "apps". They're "pages" in that there's a clear > resource/document that's being displayed, but they have interactive > functionality that couldn't be implemented with a static HTML page. > > When developing these, I always run into a question which never had a very > satisfying answer: what do I do on the server side, and what do I do on the > client side? I've experimented with a few different paradigms: > > *The Web 1.5 Way* > Server spits out document represented as HTML. Interactive elements get > onclick="" (etc.) attributes which call globally-exported JS functions. > Pros: No framework. Page functions without JS (crawlers work, lynx works, > etc). No FOUC. Can use server-side templates. No set-up costs. > Cons: No modularity. JS and HTML all up in each others business. No > compilation possible. A mess to maintain. > > *Unobtrusive JS (The jQuery Way?)* > Server spits out document represented as HTML. After page load, JS > processes the document and shuffles nodes around and hooks up listeners. > Pros: No code in markup. Page possibly functions without JS. Can use > server-side templates. Potential for modulatiry. Potential for compilation. > Cons: JS code likely needs to know intimate details about the HTML's > structure (if it wants to add/remove elements, say), so JS is very brittle > in the face of HTML changes. Probably have to do programmatic UI building > (agonizing and prone to security errors). May have duplication between > server side templates and client side logic. FOUC. > > *The GWT/AngularJS/Dart WebUI Way* > No pages, only apps. Server serves the entire app on page load, loads > "document" via XHR. Avoids reloads. > Pros: Actual modularity. Server side has zero knowledge of UI details. > FOUC exchanged for spinners (slight improvement). Client-side templating > libraries improve security. Incremental loads substantially cheaper. Code > scales. > Cons: Increased initial load latency. High initial set-up costs. Either > URL bar becomes meaningless or a mess like "/app#!/?". Back button hard to > unbreak. No JS? Go to hell. Web crawler? Go to hell. Lots of these issues > have workarounds, but the whole experience feels very un-weblike (rather > than having a user click a link to go to another page, I intercept the > link's onclick, change location.href, push a new state into the browser > history (if I'm in a sufficiently advanced browser), manually fetch the > resources I need, and update the page with them. Even if it's the framework > doing most of that work, it's stuff the browser has been doing on its own > since the 1990's). > > All these options suck to varying degrees, but I'm wondering whether > Polymer (and web components in general) is working towards a potential new > model: > > *The (Potential?) Polymer Way* > Server outputs document as an HTML page with a few includes and a title in > the <head>, and a body with purely semantic tags (almost XML-like). Those > semantic custom elements get rejiggered by Polymer magic into an > attractive, interactive web page. > Pros: One page load per document, just like the old days. Server side > renders the "document" in a structured form (perhaps with a templating > library), but has no knowledge of the actual UI. Functionality pretty well > encapsulated in custom elements. Not unrenderable on browsers without JS > (substantially degraded, though... maybe you could fall back on CSS in that > case?). Legible to search engines. > Cons: FOUC. Incremental loads more expensive than the XHR way, but > hopefully caching of imports and the lack of <div class="foo"><div > class="bar"><span class="hi">Hi</span></div></div> cuts down on transfer > size. > > I haven't worked enough with Polymer to identify other cons yet, but I'm > really excited about the possibility of developing this way. > > Is this how others have been using Polymer? Any thoughts? > > Follow Polymer on Google+: plus.google.com/107187849809354688692 > --- > You received this message because you are subscribed to the Google Groups > "Polymer" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/polymer-dev/11ca4b3c-678a-431b-9e94-da7d5bc579e4%40googlegroups.com<https://groups.google.com/d/msgid/polymer-dev/11ca4b3c-678a-431b-9e94-da7d5bc579e4%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > Follow Polymer on Google+: plus.google.com/107187849809354688692 --- You received this message because you are subscribed to the Google Groups "Polymer" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/CAAUAVAg3mBDaLsFGJjDguA5TfwznZuJ_0-Hc%2Bkuxj_%2BSm7ZRRA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
