First Essential Difficulty: An Additional Logic Tier
Let's consider the code for a simple, read-only display that shows a customer and some orders.
Traditional Web App
On the web server:
var customer = retrieveCustomerFromDatabase(); addCustomerToHtml( customer ); var orders = retrieveOrdersFromDatabase( customer ); addOrdersToHtml( orders );
On the web server:
var customer = retrieveCustomerFromDatabase(); addCustomerToJson( customer ); var orders = retrieveOrdersFromDatabase( customer ); addOrdersToJson( orders );
And in the browser:
var customerAndOrders = retrieveCustomerAndOrdersFromWebService(); addCustomerToHtml( customerAndOrders.Customer ); addOrdersToHtml( customerAndOrders.Orders );
With the SPA architecture, you essentially have to deal with the customer and the orders twice. It's not that you have to do any of the mechanical tasks twice: you're still only retrieving the data once and building the HTML representation once. But you must now publicly present your customer and orders from both the web server tier and the browser tier. If you add a new type of data to your customer display, such as a list of shipping addresses, you need to add the addresses to the JSON and the HTML. If you need to restrict access to a field (e.g. social security number) such that only certain users can see it, you need the authorization check twice, once when writing the JSON and again when building the HTML. In a traditional web app, you can go straight from the data to the final HTML representation with a single block of code on the web server. Here's a diagram that sums up the difference:
In simple cases, you may not need to write any logic for the web server tier, opting instead to use something like OData or a "backend as a service" offering such as Windows Azure Mobile Services. But as soon as your customer editor makes first contact with users, and they start making requests, and you start embellishing the screens with various bits of information from other database tables or data sources, you'll need your own web services to bundle things up and avoid a very chatty conversation between web browser and server. There will be no silver-bullet solution to this issue since network latency isn't going away anytime soon.
Second Essential Difficulty: Data Synchronization
SPAs typically store a larger amount of data in the browser tier at any given time; this is how they enable users to move from task to task without delay. Data in the browser always has a risk of going stale due to external changes, and the more of it you have, the harder it is to determine during synchronization whether it is or isn't stale. And when it does go stale, the more data you have, the harder it is for you (or your users) to reconcile it. Back to the customer editor example: what happens if a user edits a customer, navigates, and begins editing a second customer before you detect that both records were modified a few seconds earlier by a background process that is cleaning up customer mailing addresses? You may be able to provide good behavior to handle this, but it's not easy, and it will involve logic specific to the situation. And issues like this are exacerbated if you decide to support offline editing. The more time you allow between data synchronizations, the more problems you'll have.
In a traditional web app, modifiable data in the browser tier is limited to a single set of HTML form field values and that's all you ever need to synchronize. Concurrency can never cost the user more than one set of field values. In our example, if the user edits a customer record and submits, the browser window blocks the user from moving to the next task until the modified record is reconciled. Is this a lower quality user experience? Yes. But it's also a much simpler concurrency model.
Think About It
Nobody can argue that SPAs provide a more continuous, fluid user experience. But if you're building an app that honestly is only going to serve 10 people, or 100---or 1000---do you really want to incur higher development and maintenance costs just for the sake of pushing the user-experience envelope?
Thanks to Sam Rueby and Greg Smalter for reading drafts of this.