You're in
Iker Hurtado's pro blog
Developer | Entrepreneur | Investor
Software engineer (entrepreneur and investor at times). These days doing performant frontend and graphics on the web platform at Barcelona Supercomputing Center

Intro to Single Page Applications

8 Mar 2016   |   iker hurtado  
Share on Twitter Share on Google+ Share on Facebook
In this entry I collect some definitions, explanations and resources that I've found this time of research. I think they are a good starting point for the topic.

I start with a short and clear definition from this source:

The idea behind single page applications (SPA) is to create a smooth browsing experience like the one found in native desktop apps. All of the necessary code for the page is loaded only once and its content gets changed dynamically through JavaScript.

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:

The server’s diminished role is an important distinction in a SPA. The server has no UI logic. The server maintains no UI state. The server, however, does provide resources to the client. Those resources start out with the initial HTML for the web page (the shell) and may in response to client HTTP requests for data in the form of HTML fragments, JSON data, or on-demand JavaScript/CSS.


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.


The data can be anything the SPA client needs from the server. So perhaps this data term is overloaded and we should instead clarify this by saying that a SPA will request resources on-demand (or cache them if so desired) and those resources may be JSON data, HTML fragments, JavaScript or CSS.

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.