7 ms·

I accept the brittleness of a content-oriented site switching to a javascript-driven SPI implementation, however I'm confused by the assertion that the stronges

I accept the brittleness of a content-oriented site switching to a javascript-driven SPI implementation, however I'm confused by the assertion that the strongest reason to switch is because it's cool. I can't speak for Gawker, but some sites may switch because they want the browser to do more of the rendering work, such as rendering templates. Others may want to avoid the overhead with a full page refresh as users navigate the site. The author clearly dislikes what's going on, and the post would be stronger if he simply stated the disadvantages and let others speak to the benefits rather than putting up a strawman and claiming that people implement this sort of site because it's cool.

bluesmoon 16y ago
some sites may switch because they want the browser to do more of the rendering work, such as rendering templates. Others may want to avoid the overhead with a full page refresh as users navigate the site Both of these can be achieved using progressive enhancement. There is no technical reason to include it in the page itself.
- daleharvey 16y ago
  there are technical problems with progressive enhancement, the latency between page load and progressive enhancement being applied being a fairly obvious one, the other is the providing full html fallbacks combined with progressive enhancement can be very complicated and time consuming, its very easy to see time when time to live wins out over semantic correctness hopefully html5 pushstate will alleviate a lot of the complications with providing full fallbacks
  - bluesmoon 16y ago
    the latency between page load and progressive enhancement being applied shows up primarily if you load your JavaScript at the bottom of the page. Now I know that this is what Yahoo!'s performance rules suggest, I was on the team that made those recommendations. They made sense between 2006-2009, but browsers have improved significantly since then and that rule isn't necessarily true any more. You can load scripts in the head of your document without any of the blocking issues we saw in the past. You can even do multiple scripts in parallel to reduce download latency. See my <a href="http://calendar.perfplanet.com/2010/thoughts-on-performance/>thoughts http://calendar.perfplanet.com/2010/thoughts-on-performance/... on performance</a> on the 2010 performance advent calendar.
    - iron_ball 16y ago
      Interesting, thanks. Does "browsers have improved significantly since [2006]" mean that we still need bottom scripts for IE?
      - bluesmoon 16y ago
        IE6 is turning into a C grade browser this quarter (http://yuiblog.com/blog/2010/11/03/gbs-update-2010q4/ http://yuiblog.com/blog/2010/11/03/gbs-update-2010q4/) so you can probably just not serve JavaScript to it (server side detection). IE7 still doesn't do parallel script downloads, so you might need to do bottom loading for it, but it's best to first find out what your users use before optimizing for it. You can get really complicated and change your page structure based on useragent and user's network characteristics, but that requires far more development effort.
        eli 16y ago
        Gawker redirects IE6 to their (crappy) mobile site, for what it's worth.
    - strager 16y ago
      Nice remark; thanks! Full (unbroken) link: http://calendar.perfplanet.com/2010/thoughts-on-performance/ http://calendar.perfplanet.com/2010/thoughts-on-performance/
  - kls 16y ago
    As well the elephant in the room that gets missed is that many rail about the technical correctness without taking into account the target market. Personally I build web applications that replace desktop applications. Progressive enhancement would kill the simplicity of our programming model and literally triple the work effort because we would be in the hybrid world of half server side and half client side. As it sits, we use a full client side UI library and push all UI concerns into the UI, they communicate with the server via REST to get data and the client is responsible for rendering that data. We research our numbers extensively and the cost analysis of changing our development model to support clients that cannot support full JavaScript clients supports the conclusion "at least for us" that a progressive enhancement development model is not cost effective. The money recouped with the shortened development cycle of Ajax clients outweighs the amount we would receive chasing some fraction of < 2% of potential clients, If we get to the point that we need to chase that 2% for growth we are a) doing great and b) would be better served segmenting that traffic to a completely independent server framework based UI that it built for those clients. It is my belief that mixing the two development models gives you the worst of both worlds when it comes to features and maintainability.
bad_user 16y ago
Others may want to avoid the overhead with a full page refresh as users navigate the site. Avoiding a full-page REFRESH only makes sense when the current page does NOT change (e.g. doing login). Speaking about overhead, to avoid bandwidth problems related to page-switching 90% of websites out there would be better off if they just added the Cache-Control on their static assets or GZip the content sent (yes, it's kind of ironic that so many developers ignore common-sense techniques already available in the HTTP protocol). Also, if the overhead is in the server-side processing done, then offload that processing making it async and cache the results. Why is that so hard? For me Twitter's new interface is slower and more cluttered than the old one, without providing the benefits of the iPhone client I'm using. It's a disaster IMHO, so speculating they only did it because it's cool is not unreasonable.
- raganwald 16y ago
  Good, healthy observations, thanks. Avoiding a full-page REFRESH only makes sense when the current page does NOT change (e.g. doing login User navigates from "A" to "B" Some or even most content on the page changes. Scenario 1: New page is fetched from the server. Scenario 2: Content is fetched from the server via AJAX and rendered with a template in the browser, then injected into the current DOM. I assert there are technical benefits to the second scenario. Whether they outweigh the disadvantages is not my argument. My argument is that there are technical benefits and that "because it's cool" is a straw man argument. if the overhead is in the server-side processing done, then offload that processing making it async and cache the results. Why is that so hard? Yes, and one such strategy is to offload it to the user's browser. Again, I am not arguing it is the best strategy, as I am not responsible for Gawker Media or your application.
  - mcantor 16y ago
    Didn't the article author assert that you can use click handlers on your links to achieve AJAX loading without a full page refresh?
    - raganwald 16y ago
sunchild 16y ago
The author also completely misses the business case: putting a single gateway through which Google can index makes sense for huge content generators. Sites like Twitter actually have some leverage with Google, as the Twitter firehose is more "real time" than Google's index. Using the #! allows Twitter tight control over Google's access to content. As for Gawker, I suspect they overestimate their leverage with Google, and have no similar business case.
- Isofarro 16y ago
  "The author also completely misses the business case: putting a single gateway through which Google can index makes sense for huge content generators." That's called a domain name. www.lifehacker.com is a single gateway to all of lifehacker's blog posts. Then you use the path part of the URL to specify which post or collection of posts you want. Twitter hasn't leveraged anything. The tweet URLs without the hash-bangs were more accessible to Google. You want tight-control as to which user-agents can see which set of tweets - that's what the Controller is for on the server.
- ceejayoz 16y ago
  sitemap.xml and robots.txt offer much, much more control over Google's crawling, and require essentially no dev work.
  - sunchild 16y ago
    And can be ignored...
    - ceejayoz 16y ago
      The hashbang technique could be easily worked around by a company with the resources of Google, and the PR ramifications of GoogleBot violating robots.txt would be pretty big.
ZoFreX 16y ago
The author does his point a disservice by being under-informed, imo. I agree that Gawker's redesign is horrible, and share his hate of needless javascript (why re-implement half the browser stack?), but his suggestions for improvement would actually be a reduction in functionality. He suggests using real URLs - instead of "/#!5753509/hello-world-this-is-the-new-lifehacker" we would have "/5753509/hello-world-this-is-the-new-lifehacker". Sounds great, but what happens when you click to a new article, which is loaded with AJAX? > Engineers will mutter something about preserving state within an Ajax application. And frankly, that’s a ridiculous reason for breaking URLs like that. Is it? Let's try things all possible ways (with the assumption that content is loaded via AJAX) and see what happens. Firstly, the current state: Address bar: "/#!5753509/hello-world-this-is-the-new-lifehacker", click on a link, now it's "/#!downloads/5753887". I can bookmark this, send the link to a friend, etc etc. Option two is to not track this at all, after all preserving state isn't that important, right? Address bar: "/#!5753509/hello-world-this-is-the-new-lifehacker", click a link, it doesn't change. I can't bookmark the new page, I can't send the link to a friend, my back button won't work properly. Third option is to use real URLs as he suggested... we need to track state (otherwise we hit the same problems in option 2) so let's try that: Address bar: "/5753509/hello-world-this-is-the-new-lifehacker", click a link, it now contains "/5753509/hello-world-this-is-the-new-lifehacker#!downloads/5753887". Oops. That's even less clean. Conclusion: If you must load content with AJAX, using URL fragments to track state is the most functional and cleanest-URL option available.
- Isofarro 16y ago
  "The author does his point a disservice by being under-informed, imo." I admit my Google searching turned up no useful results about hash-banging URLs for new websites, only Google's attempt to index sites that ignored progressive enhancement and hid all content behind Ajax calls. "Sounds great, but what happens when you click to a new article, which is loaded with AJAX?" If you want to load the content in via Ajax, you start with a valid and direct URL to a piece of content. You can then use JavaScript on the click handler to mangle the URL into a hash-bang, and then proceed as you wish. You get all the benefits of hash-bang without the downside of uncrawlable URLs. "now it's "/#!downloads/5753887". I can bookmark this, send the link to a friend, etc etc." * Bookmark it to a third party service - yes (assuming they don't truncate fragment identifiers!) * That service then retrieves the content of that article (for summarising, entity recognition, extracting microformatted data). no. The hash-bang URL is not a direct reference to the piece of content. The indirection shenanigans isn't part of HTTP/1.1 or RFC-2396. So it's not Restful for starters. "after all preserving state isn't that important, right" That can be done without making all links on the page non-traversable with a crawler. "Conclusion: If you must load content with AJAX, using URL fragments to track state is the most functional and cleanest-URL option available." a clean URL would not be an indirect reference that would need to be reformatted into a direct reference before being curled. State can be done without mangling URLs in this way.

bluesmoon 16y ago

some sites may switch because they want the browser to do more of the rendering work, such as rendering templates. Others may want to avoid the overhead with a full page refresh as users navigate the site Both of these can be achieved using progressive enhancement. There is no technical reason to include it in the page itself.

daleharvey 16y ago
there are technical problems with progressive enhancement, the latency between page load and progressive enhancement being applied being a fairly obvious one, the other is the providing full html fallbacks combined with progressive enhancement can be very complicated and time consuming, its very easy to see time when time to live wins out over semantic correctness hopefully html5 pushstate will alleviate a lot of the complications with providing full fallbacks
- bluesmoon 16y ago
  the latency between page load and progressive enhancement being applied shows up primarily if you load your JavaScript at the bottom of the page. Now I know that this is what Yahoo!'s performance rules suggest, I was on the team that made those recommendations. They made sense between 2006-2009, but browsers have improved significantly since then and that rule isn't necessarily true any more. You can load scripts in the head of your document without any of the blocking issues we saw in the past. You can even do multiple scripts in parallel to reduce download latency. See my <a href="http://calendar.perfplanet.com/2010/thoughts-on-performance/>thoughts http://calendar.perfplanet.com/2010/thoughts-on-performance/... on performance</a> on the 2010 performance advent calendar.
  - iron_ball 16y ago
    Interesting, thanks. Does "browsers have improved significantly since [2006]" mean that we still need bottom scripts for IE?
    - bluesmoon 16y ago
      IE6 is turning into a C grade browser this quarter (http://yuiblog.com/blog/2010/11/03/gbs-update-2010q4/ http://yuiblog.com/blog/2010/11/03/gbs-update-2010q4/) so you can probably just not serve JavaScript to it (server side detection). IE7 still doesn't do parallel script downloads, so you might need to do bottom loading for it, but it's best to first find out what your users use before optimizing for it. You can get really complicated and change your page structure based on useragent and user's network characteristics, but that requires far more development effort.
      - eli 16y ago
        Gawker redirects IE6 to their (crappy) mobile site, for what it's worth.
  - strager 16y ago
    Nice remark; thanks! Full (unbroken) link: http://calendar.perfplanet.com/2010/thoughts-on-performance/ http://calendar.perfplanet.com/2010/thoughts-on-performance/
- kls 16y ago
  As well the elephant in the room that gets missed is that many rail about the technical correctness without taking into account the target market. Personally I build web applications that replace desktop applications. Progressive enhancement would kill the simplicity of our programming model and literally triple the work effort because we would be in the hybrid world of half server side and half client side. As it sits, we use a full client side UI library and push all UI concerns into the UI, they communicate with the server via REST to get data and the client is responsible for rendering that data. We research our numbers extensively and the cost analysis of changing our development model to support clients that cannot support full JavaScript clients supports the conclusion "at least for us" that a progressive enhancement development model is not cost effective. The money recouped with the shortened development cycle of Ajax clients outweighs the amount we would receive chasing some fraction of < 2% of potential clients, If we get to the point that we need to chase that 2% for growth we are a) doing great and b) would be better served segmenting that traffic to a completely independent server framework based UI that it built for those clients. It is my belief that mixing the two development models gives you the worst of both worlds when it comes to features and maintainability.

bad_user 16y ago

Others may want to avoid the overhead with a full page refresh as users navigate the site. Avoiding a full-page REFRESH only makes sense when the current page does NOT change (e.g. doing login). Speaking about overhead, to avoid bandwidth problems related to page-switching 90% of websites out there would be better off if they just added the Cache-Control on their static assets or GZip the content sent (yes, it's kind of ironic that so many developers ignore common-sense techniques already available in the HTTP protocol). Also, if the overhead is in the server-side processing done, then offload that processing making it async and cache the results. Why is that so hard? For me Twitter's new interface is slower and more cluttered than the old one, without providing the benefits of the iPhone client I'm using. It's a disaster IMHO, so speculating they only did it because it's cool is not unreasonable.

raganwald 16y ago
Good, healthy observations, thanks. Avoiding a full-page REFRESH only makes sense when the current page does NOT change (e.g. doing login User navigates from "A" to "B" Some or even most content on the page changes. Scenario 1: New page is fetched from the server. Scenario 2: Content is fetched from the server via AJAX and rendered with a template in the browser, then injected into the current DOM. I assert there are technical benefits to the second scenario. Whether they outweigh the disadvantages is not my argument. My argument is that there are technical benefits and that "because it's cool" is a straw man argument. if the overhead is in the server-side processing done, then offload that processing making it async and cache the results. Why is that so hard? Yes, and one such strategy is to offload it to the user's browser. Again, I am not arguing it is the best strategy, as I am not responsible for Gawker Media or your application.
- mcantor 16y ago
  Didn't the article author assert that you can use click handlers on your links to achieve AJAX loading without a full page refresh?
  - raganwald 16y ago

sunchild 16y ago

The author also completely misses the business case: putting a single gateway through which Google can index makes sense for huge content generators. Sites like Twitter actually have some leverage with Google, as the Twitter firehose is more "real time" than Google's index. Using the #! allows Twitter tight control over Google's access to content. As for Gawker, I suspect they overestimate their leverage with Google, and have no similar business case.

Isofarro 16y ago
"The author also completely misses the business case: putting a single gateway through which Google can index makes sense for huge content generators." That's called a domain name. www.lifehacker.com is a single gateway to all of lifehacker's blog posts. Then you use the path part of the URL to specify which post or collection of posts you want. Twitter hasn't leveraged anything. The tweet URLs without the hash-bangs were more accessible to Google. You want tight-control as to which user-agents can see which set of tweets - that's what the Controller is for on the server.
ceejayoz 16y ago
sitemap.xml and robots.txt offer much, much more control over Google's crawling, and require essentially no dev work.
- sunchild 16y ago
  And can be ignored...
  - ceejayoz 16y ago
    The hashbang technique could be easily worked around by a company with the resources of Google, and the PR ramifications of GoogleBot violating robots.txt would be pretty big.

ZoFreX 16y ago

The author does his point a disservice by being under-informed, imo. I agree that Gawker's redesign is horrible, and share his hate of needless javascript (why re-implement half the browser stack?), but his suggestions for improvement would actually be a reduction in functionality. He suggests using real URLs - instead of "/#!5753509/hello-world-this-is-the-new-lifehacker" we would have "/5753509/hello-world-this-is-the-new-lifehacker". Sounds great, but what happens when you click to a new article, which is loaded with AJAX? > Engineers will mutter something about preserving state within an Ajax application. And frankly, that’s a ridiculous reason for breaking URLs like that. Is it? Let's try things all possible ways (with the assumption that content is loaded via AJAX) and see what happens. Firstly, the current state: Address bar: "/#!5753509/hello-world-this-is-the-new-lifehacker", click on a link, now it's "/#!downloads/5753887". I can bookmark this, send the link to a friend, etc etc. Option two is to not track this at all, after all preserving state isn't that important, right? Address bar: "/#!5753509/hello-world-this-is-the-new-lifehacker", click a link, it doesn't change. I can't bookmark the new page, I can't send the link to a friend, my back button won't work properly. Third option is to use real URLs as he suggested... we need to track state (otherwise we hit the same problems in option 2) so let's try that: Address bar: "/5753509/hello-world-this-is-the-new-lifehacker", click a link, it now contains "/5753509/hello-world-this-is-the-new-lifehacker#!downloads/5753887". Oops. That's even less clean. Conclusion: If you must load content with AJAX, using URL fragments to track state is the most functional and cleanest-URL option available.

Isofarro 16y ago
"The author does his point a disservice by being under-informed, imo." I admit my Google searching turned up no useful results about hash-banging URLs for new websites, only Google's attempt to index sites that ignored progressive enhancement and hid all content behind Ajax calls. "Sounds great, but what happens when you click to a new article, which is loaded with AJAX?" If you want to load the content in via Ajax, you start with a valid and direct URL to a piece of content. You can then use JavaScript on the click handler to mangle the URL into a hash-bang, and then proceed as you wish. You get all the benefits of hash-bang without the downside of uncrawlable URLs. "now it's "/#!downloads/5753887". I can bookmark this, send the link to a friend, etc etc." * Bookmark it to a third party service - yes (assuming they don't truncate fragment identifiers!) * That service then retrieves the content of that article (for summarising, entity recognition, extracting microformatted data). no. The hash-bang URL is not a direct reference to the piece of content. The indirection shenanigans isn't part of HTTP/1.1 or RFC-2396. So it's not Restful for starters. "after all preserving state isn't that important, right" That can be done without making all links on the page non-traversable with a crawler. "Conclusion: If you must load content with AJAX, using URL fragments to track state is the most functional and cleanest-URL option available." a clean URL would not be an indirect reference that would need to be reformatted into a direct reference before being curled. State can be done without mangling URLs in this way.