The topic of server-side rendering (HTML should be ready for presentation before JS is run) has come up a few times in the past. Some notes that might be useful:
* Native custom elements go through an upgrade process where they get converted from standard HTML elements to their much better custom versions and with this, the topic of preventing FOUC comes up regularly. The Polymer docs discuss FOUC prevention<http://www.polymer-project.org/articles/styling-elements.html#preventing-fouc>in some detail and I'd definitely read through this. * To ensure the page renders as quickly as possible (but delay loading all your JS), you could take advantage of the :unresolved pseudo class Dan mentioned for styling custom elements. This allows it to display the bare skeleton of what the content would look like once it has completed upgrading. This can increase the perceived time the page takes to become usable however. * HTML imports block rendering, similar to stylesheets as they can contain stylesheets themselves. Both of them do this in order to prevent FOUC. They do not block parsing of the main page however. One of the benefits of using Imports to deliver your element definitions is that all of the processing can happen in parallel from the main page. * Some devs experimenting with Polymer have looked at avoiding the use of server-side templating completely. Using Polymer's templating and data-binding you could keep your HTML very simple and utilize a component tree with attributes and content which are bound to backend data. You could construct a server-side DOM composed of custom element tags and serialize this out as HTML with some helper classes for representing tags. All the logic for how this would be rendered into actual HTML and CSS living in Polymer elements. On Wednesday, 16 April 2014 17:54:31 UTC+1, [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/313e26fb-13dd-4c51-bcfa-5e30089312e7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
