To SPA or not to SPA

Index:

1. Getting started with AngularJS
2. Creating an AngularJS Controller
3. The AngularJS $scope is not the MVC Model
4. Using repeating elements in AngularJS
5. Filtering the data in an AngularJS ngRepeat element
6. Using the AngularJS FormController to control form submission
7. Creating an AngularJS Directive
8. Using the DOM in an AngularJS application
9. To SPA or not to SPA

 

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.

 

Enjoy!