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.
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.
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.
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.
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
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.