Creating Single Page Applications, usually abbreviated to SPA, is getting more and more popular these days. There are some popular applications like GMail or Outlook.com done this way and using frameworks like AngularJS or routing libraries like Director and Sammy it appears quite easy to do.

The basic approach with a SPA style application is the end user downloads most, if not all, the markup, CSS and JavaScript right at the start of the application. After that all navigation is done locally in the browser by dynamically updating the DOM on the fly. Any data needed is downloaded or uploaded on the fly, typically as JSON, so the user always seed up to date data. Typically this data is combined with templates in the browser to form part of the DOM. This can be done using a variety of techniques like data binding with AngularJS or KnockoutJS, some templating engine like Handlebars or creating DOM elements on the fly using jQuery.

So should you build all your JavaScript/HTML5 applications as a SPA or not?

SPA Advantages

There are some significant advantages to building a SPA style application. Quite lot of the time in switching between different pages in our application is actually the result of server rendering and network transport. If we can reduce the amount of work our server has to do and transport less to the browser we gain quite a bit of performance when the user is running our application. This results in a lot better response for the user.

Additionally because we don’t navigate from page to page it’s a lot easier to keep state on the client, after all we can just keep state in JavaScript objects.

SPA Disadvantages

As usual there is no free lunch and there is a price to be paid.

One of them main drawbacks is that you can only load one version of each library. Does one part of the application need a newer version of jQuery? Then the whole application needs to upgrade because only a single version of jQuery can be loaded at the same time. You might think that is no problem because you want to be on the latest version anyway. That certainly makes sense but upgrading a library means that the complete application needs to be re-tested. And with jQuery I am quite confided that the breaking changes will be documented but not all libraries are that well behaved.

The same is probably true for your own shared code. And with a compiled language the compiler will at least warn you about most breaking API changes but with JavaScript there is no such safety net. Only at runtime will you know and in quite a few cases even that will not be as clear.

There are other concerns like authentication/authorization you might have solved already with server side code. Using Forms Authentication is simple enough at the server but no good at all on the client.

All of this means that a SPA is much harder to manage. There are far more possible side effects between different parts of the application.

A better approach

There are some clear advantages to using the SPA pattern for your application but as always there is a cost. However we can greatly decrease the cost by adhering to a simple principal:

Great things are done

by a series of small things brought together.

Vincent Van Gogh

We can easily apply this principal to our development as well. Why combine two unrelated modules into one and create a coupling between them if there is no actual need?

Think about a typical sales application. Does the customer management screen really have a lot to do with the lead management. And are either of them really tied in with the inventory management?

Not really I would argue. Sure they are all needed and there will be some code and CSS shared between them. Would the application be any less usable if you use a traditional browser navigation between customer and inventory management? I would say that in 99% of the cases that would be perfectly fine. And decoupling these two modules would mean that building the application suddenly gets a lot simpler.

The end result is what I call Single Page Modules.

Basically each module is developed as a separate page. The user browses to that module in the traditional manner. Once inside that module/page the single page mechanism applies and all interaction is done in the browser with dynamic DOM updates and loading JSON data as is typically the case with a SPA style application.

If you take a look at my sample site you can see the concept. Both the Movies and Admin parts are single page modules. Inside you can use single page navigation and only data is loaded after the first page. Between the two you are using traditional full page refresh navigation though so there is no coupling. I can make changes to one part without being worried of having unintended side effects.

Thanks Maurice. I’m on the same point of view. I’m learning Angular, Laravel, Bootstrap, NodeJS, … and other libraries for a personal project. For several years I was programming “old school” style without frameworks, and last years using server side frameworks like Synphony or CodeIgniter.

So when I discovered a few weeks ago Angular I though (ey guy !!! this is awesome – like Action Script was some day -), but … ecapsulate all functionalities and modules of my application in “One Single Page” ? Yes there is ngRoute … but … why thinking in a big complex SPA ?

I think that like enginiers, we have to use the best thing of each “worlds” and joins for a better solution (sinergy) . I’m of the point of view that “divide and you will conquer”.

All docs and tutorials that I sow in Intenert explains that Angular is for a SPAs … but

What is an application ?

The response is that an application is what you want it to be. So for me, my “project” is built with several SPAs doing well and simples jobs, stiched or driven by a clasical “server side generated navigation”.

The server side resolves easily and fine situations like “authentication”, not exposure private sections for not allowed users, context templating, etc …