Only very innovative products worked differently, and experimented with new approaches.
The technology is always the same, but the philosophy and some key components of how the application works are different.
Examples of Single Page Applications
Some notable examples:
- Google Maps
- Google Drive
Pros and cons of SPAs
An SPA feels much faster to the user, because instead of waiting for the client-server communication to happen, and wait for the browser to re-render the page, you can now have instant feedback. This is the responsibility of the application maker, but you can have transitions and spinners and any kind of UX improvement that is certainly better than the traditional workflow.
In addition to making the experience faster to the user, the server will consume less resources because you can focus on providing an efficient API instead of building the layouts server-side.
This makes it ideal if you also build a mobile app on top of the API, as you can completely reuse your existing server-side code.
Single Page Applications are easy to transform into Progressive Web Apps, which in turn enables you to provide local caching and to support offline experiences for your services (or simply a better error message if your users need to be online).
SPAs are best used when there is no need for SEO (search engine optimization). For example for apps that work behind a login.
Search engines, while improving every day, still have trouble indexing sites built with an SPA approach rather than the traditional server-rendered pages. This is the case for blogs. If you are going to rely on search engines, don’t even bother with creating a single page application without having a server rendered part as well.
SPAs are great when working in teams. Backend developers can just focus on the API, and frontend developers can focus on creating the best user experience, making use of the API built in the backend.
Overriding the navigation
Since you get rid of the default browser navigation, URLs must be managed manually.
This part of an application is called the router. Some frameworks already take care of them for you (like Ember), others require libraries that will do this job (like React Router).
What’s the problem? In the beginning, this was an afterthought for developers building Single Page Applications. This caused the common “broken back button” issue: when navigating inside the application the URL didn’t change (since the browser default navigation was hijacked) and hitting the back button, a common operation that users do to go to the previous screen, might move to a website you visited a long time ago.
This problem can now be solved using the History API offered by browsers, but most of the time you’ll use a library that internally uses that API, like React Router.