5 ms·
It seems like the author is confusing progressive enhancement with progressive rendering. Either way, to say that the Dale piece "conclusively" shows progressi
by gavinpc 13y ago
It seems like the author is confusing progressive enhancement with progressive rendering.
Either way, to say that the Dale piece "conclusively" shows progressive enhancement to be "a futile act" is, in the OP's word, "misrepresenting."
"Exceptional" or not, the key is to recognize when you're dealing with one of those cases -- sites which, like Wikipedia, could be great on Web 1.0 browsers. In those cases, your focus is likely to be more on the content and its structure. In the "progressive enhancement est mort" view, you'll have to spend more time on engineering.
- jaffathecake 13y agoProgressive rendering is enabled by progressive enhancement. I'm not convinced progressive enhancement is more effort unless you make it more effort. I covered these arguments and more in my previous post http://jakearchibald.com/2013/progressive-enhancement-still-important/ http://jakearchibald.com/2013/progressive-enhancement-still-...
- dasil003 13y ago> Progressive rendering is enabled by progressive enhancement. Sometimes, but only by coincidence. The baseline of supporting JS off is that you have the render the entire page contents server-side. If the progressive enhancement is addition of content that is only supported by JS then you are correct. However the ideal progressive rendering is to send a generic static HTML shell with no personalized content that can be delivered instantaneously from a web server without any back-end chatter, then load in the dynamic content from the client side. Facebook is probably the most advanced implementation of this technique, and it yields a dramatic increase in perceived performance due to the fact that page starts visually appearing faster which psychologically extends the user's patience.
- jaffathecake 13y agoThat doesn't sound like a definition of progressive rendering I've heard before http://www.codinghorror.com/blog/2005/11/the-lost-art-of-progressive-html-rendering.html http://www.codinghorror.com/blog/2005/11/the-lost-art-of-pro...
- dasil003 13y agoRead and learn young grasshopper: https://www.facebook.com/note.php?note_id=389414033919 https://www.facebook.com/note.php?note_id=389414033919
- kalms 13y agoOkay, I got to admit: That was awesome. Well thought out.
- jaffathecake 13y agoGood article, but that's not the definition of progressive rendering
- dasil003 13y agoWhat's the precise definition? The browser rendering partial HTML as it is streamed down? That is just built-in browser technology to achieve the same goal. There's no meaningful distinction in terms of the end result.
- jaffathecake 13y agoActually, I misread your earlier post. Yes, what Facebook does is progressive rendering, but I disagree that it's the ideal since it's still blocked by JS. The ideal is serving HTML from the server which can get content on the screen before JS downloads. "That is just built-in browser technology to achieve the same goal" - exactly. Tweetdeck does progressive rendering, but it avoids the simplest way of doing it and instead reinvents the technique with JavaScript. You can see what this does to performance.
- dasil003 13y agoThe point is that the perceived performance of Facebook is impossible to achieve with server-side rendering. Whether they should optimize for that 99.99% or the other 0.01% on philosophical grounds is a point you are free to debate. However the facts are the facts.