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.
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.
Indeed, but then the URL doesn't change, so the page can't be emailed, tweeted, etc. The hash-bang allows you to change the url, use AJAX to change the content, and retain browser history.
The history API in HTML5 allows you to accomplish the same thing without the hash-bang, but browser support is limited. I favour using the history API for progressive enhancement and defaulting to traditional page requests.
Yes of course he did, however every design decision has trade-offs. Using click handlers has some costs and some benefits. Using URL fragments has costs and benefits.
I'm not disputing that the author has proposed a way forward or that the author's suggestions about the costs of using fragments are mistaken, I am only disputing the argument that there is no reason to use url fragments besides "coolness."
It depends (of course).
First of all, markup wise page content can take only a small part of the whole page HTML. Navigation, widgets, etc. can be substantial.
Also, you'd want Expires, not Cache control. Otherwise you may end sending dozens of request
just to get 304 back.
Keeping that in mind, sending single AJAX request which delivers _only_ content seems quite beneficial compared to full refresh scenario.
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.