*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. For more options, visit https://groups.google.com/d/optout.
