Philosophy on page loads
349 views
Skip to first unread message
hjfr...@google.com
Apr 16, 2014, 12:54:31 PM4/16/14
to polym...@googlegroups.com
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?
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.
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?
Daniel Freedman
Apr 16, 2014, 2:20:00 PM4/16/14
to hjfr...@google.com, polymer-dev
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.
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 polymer-dev...@googlegroups.com.
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.
Addy Osmani
Apr 17, 2014, 8:47:10 AM4/17/14
to polym...@googlegroups.com, hjfr...@google.com
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 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.
Hunter Freyer
Apr 17, 2014, 11:16:18 AM4/17/14
to ad...@google.com, polym...@googlegroups.com
On Thu Apr 17 2014 at 8:47:11 AM, Addy Osmani <ad...@google.com> wrote:
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 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.
Re: FOUC, I've come to terms with the fact that the client side is the proper place to do all your presentation stuff, and that in that case FOUC is going to be an unavoidable concern, though a manageable one. I'm glad you guys are thinking a lot about it.
* 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.
This sounds like exactly what I want. I'm very psyched about this brave new world!
Reply all
Reply to author
Forward
0 new messages