Browsers store history so that pages load quickly when the user clicks back. Daniel Puplus explains in Building Single Page Applications that:
“When a user presses the browser’s back button they expect the change to happen quickly and for the page to be in a similar state to how it was last time they saw it.
“In the traditional web model the browser will typically be able [to] use a cached version of the page and linked resources.
“In a naive implementation of a SPA hitting back will do the same thing as clicking a link, resulting in a server request, additional latency, and possibly visual data changes.”
If we want users to enjoy the same, fast experience, we need to mimic the native browser behaviour in JS.
First, the application will need to store pages in memory, local storage, client-side databases or cookies. Second, the application will need to determine when to retrieve these pages. As part of this it will need to differentiate between:
Browsers show a loading indicator when the page is loading. But, SPAs use AJAX to load pages, so we need to implement a custom one which is more work.
Also, the browser’s indicator displays progress. That is, a user can tell how long until the page loads. JS can only state that something is loading, not how long left there is. This leads to users clicking the link again which exacerbates problem 3.
Furthermore, the user’s browser provides a predictable and familiar loading indicator, no matter which website they visit. When we use JS to do this, we break the third of Henny Swan’s UX principles, design with familiarity in mind.
Ironically, SPAs are harder to both design and build. And yet, they typically produce slow, disagreeable and exclusive experiences.
Twitter, Lifehacker and Delicious have reverted to traditional architectures because of these issues which you can read in:
- Improving performance on Twitter;
- Breaking The Web With Hash Bangs; and
- Delicious changes.
We should let the browser manage the browsing experience, and spend our time solving real problems.