Single-page apps (or SPAs as they’re sometimes called) serve all of the code for an entire multi-UI app from a single
- Configure the server to point all paths on a domain back to the root
index.htmlfile. For example,
todolist.com/listsshould both point to the same file.
- Suppress the default behavior when someone clicks a link that points to another page in the app.
history.pushState()—to update the URL without triggering a page reload.
- Match the URL against a map of routes, and serve the right content based on it.
- If your URL has variable information in it (like a todolist ID, for example), parse that data out of the URL.
- Detect when someone clicks the browser’s back button/forward button, and update the URL and UI.
- Update the
titleelement on the page.
(Shoutout to Ashley Bischoff for those last two!)
This becomes more code to maintain, more complexity to manage, and more things to break. It makes the whole app more fragile and bug-prone than it has to be.
I’m going to share some alternatives that I prefer.
Like – it seems – Chris Ferdinandi, I’ve got nothing against Single Page Applications in their place.
Whenever I see a new front-end framework sing the praises of its routing engine I wonder how we got to this point. After all: the Web’s had a routing engine since 1990, and most efforts to reinvent it invariably make it worse: less-accessible, less-archivable, less-sharable, less-discoverable, less-reliable, or several of these.