I start with a short and clear definition from this source:
I continue with a deeper explanation form one of my reference resources: 1. Modern web applications: an overview - singlepageappbook.com
Why do we want to write single page apps? The main reason is that they allow us to offer a more-native-app-like experience to the user.
This is hard to do with other approaches. Supporting rich interactions with multiple components on a page means that those components have many more intermediate states ... Server-side rendering is hard to implement for all the intermediate states - small view states do not map well to URLs.
Single page apps are distinguished by their ability to redraw any part of the UI without requiring a server roundtrip to retrieve HTML. This is achieved by separating the data from the presentation of data by having a model layer that handles data and a view layer that reads from the models.
In addition, I extract some paragraphs of the didactic article SPA and the Single Page Myth - johnpapa.net:
SPA also supports more than 1 view on the screen at the same time. In the live demo the top navigation and the sidebar are also views. In a dashboard, we can load multiple views, too. So the term views really means an HTML fragment that offers a distinct set of functionality to the application. It often means the view follows the Single Responsibility Principle where the view can operate on its own in a variety of contexts....
I’ve tossed around the term “shell” without properly introducing it, so let me correct that now. The shell is the layout and structure of your app. The visual parts that rarely change. The shell is generally loaded on the initial page load from the server and serves as the placeholder for all of your views....
Finally, from an architectural point of view, I write down some extracts of the intro chapter of the book SPA Design and Architecture:
Moving the process for creating and managing views into the UI decouples it from the server. From an architectural standpoint, this gives the SPA an interesting advantage. Unless you’re doing partial rendering on the server, the server is no longer required to be involved in how the data is presented. ... This leaves both server and client as decoupled as possible. The benefit here is that each can be maintained and updated separately.
The overall SPA design is nearly the same as the traditional design. The key changes are as follows: no full browser refreshes, the presentation logic resides in the client, and server transactions can be data-only, depending on your preference for data rendering.