Interesting article. Although I think the fat client/ fat server approach gives the best experience, I do not think it is most appropriate in most cases.
I recently implemented the pushState api on my own website, Ajaxing in all the content, yet retaining all the logic on the server. It was easier than I expected, but still slow, and tricky to work with. Key problems are loading in page specific resources (because the page head is not re-loaded, so link elements are out), and navigating away from the website and then returning from the back button (often the browser is unsure what to do). Remembering to do things like re-fire Analytics events can be tricky.
That said, I do think using this model is far more suitable for web app type systems (as opposed to more traditional websites), where you know from the start how each page is structured and what scripts/ styles are needed.
Bradley Taylor
Interesting article. Although I think the fat client/ fat server approach gives the best experience, I do not think it is most appropriate in most cases.
I recently implemented the pushState api on my own website, Ajaxing in all the content, yet retaining all the logic on the server. It was easier than I expected, but still slow, and tricky to work with. Key problems are loading in page specific resources (because the page head is not re-loaded, so link elements are out), and navigating away from the website and then returning from the back button (often the browser is unsure what to do). Remembering to do things like re-fire Analytics events can be tricky.
That said, I do think using this model is far more suitable for web app type systems (as opposed to more traditional websites), where you know from the start how each page is structured and what scripts/ styles are needed.