I was recently interviewed by Christia Mulligan at SDTimes for an article that was published today: Are Single-Page Apps Becoming the Norm?
As with most interviews only some stuff makes it into the article, so I thought I’d post my entire response here for completeness sake…
For more information on working with Breeze and SharePoint, check out my upcoming Pluralsight course, coming soon Building SharePoint Apps as Single Page Apps with AngularJS .
It’s dangerous to say anyone can use SPAs because defining the universe as a market is a big stretch, but in reality that isn’t far off the mark. The vast majority of people have a GMAIL, Hotmail or Outlook.com email address and they are usually using the web clients to interact with their mailboxes. So let’s exclude those for a moment. A good rule of thumb is to consider when you would consider building a thick-client application rather than a web application for a solution. If your market or user base is going to be connected the majority of the time, a SPA web application might make more sense. It lets the developer & IT staff eliminate the need for an installation or rolling the application out as they only need to launch a website effectively where the users will navigate to.
Another benefit is that because only parts of the page are changing when certain actions occur, generally speaking the site will use less bandwidth than a traditional full-page refresh site. This yields a much better experience for users because they don’t have to wait as long for things to respond on the page… generally it should be a more responsive experience.
Developers can also build SPAs that operate in a low, inconsistent or no bandwidth environment. One way to build a SPA is to download all the assets the app needs at load time, keeping in mind many of these things can be cached in the user’s browser cache. The only thing the application needs to do when connected is talk to some services that might read or write to a database, start some process or perform some sort of calculation. The app could queue these operations up if it detected the app wasn’t connected, waiting for the connection to be re-established at a later time.
Another big advantage is that SPAs can be built with a responsive user interface. This means that the app experience is tailored to each user’s device, be it a desktop browser, tablet browser, phone or kiosk. This is ideal for startups or companies with a young application. Everyone wants a mobile footprint these days but it can be tough to launch your site and then a mobile app for each platform from day 1. A SPA approach could yield a better experience as it would enable developers to focus on a single implementation that could be accessed by any device and later, as demands warrant & resources allow, focus on native apps for each of the different platforms (tablets, phones, etc).
Like anything we do for customers, it really depends. Most of my work these days is around creating custom solutions for customers on SharePoint 2013. This could be on-premises deployments or deployments hosted in the cloud, specifically Office 365. The vast majority of these customizations has been around creating client-side solutions and for those, I almost always look to building a SPA. I find users really like the the experience and generally these customizations have a higher satisfaction and usage rate than the traditional page refreshes. So do I recommend them? Absolutely… I recommend looking at creating a SPA but like anything else, you have to make sure it fits the business case. The trick is not learning about some new technology or implementation, like creating SPAs, and treating that as a hammer where every challenge looks like a nail. It doesn’t work for everything… just be smart and evaluate your options.
I’ve mentioned quite a few of the things above, but some things developers should keep in mind when building SPAs include search search, online/offline, auth/anon, and the browser standard or requirements by the customer.
One of the most challenging things with SPAs is making them friendly to search engines. If the SPA is behind a login, as many, if not most, applications are, then this isn’t really an issue as you wouldn’t want a search engine showing data from a protected view. But in the cases of an anonymous SPA, developers will need to ensure that not only they have a good deep-linking strategy implemented (so someone could jump straight to a detail view without the app requiring they go through a specified path) but also a good way to expose this to the search engine crawler. Should this be done through a dynamic sitemap? It really depends on the application.
Another thing to consider is the online/offline status of the application. One benefit to building a SPA is that your users can load the app and then go offline or have intermittent connectivity while using the app. If you want to support this scenario, you need to make sure all network calls test for the connectivity state and inform the user when the state changes. In addition you also need to typically implement some sort of client-side caching to hold onto changes until connectivity is restored to the app.
Finally, another thing you should strongly consider is if your customer or the target audience has any minimum browser requirements, or, more importantly, if the organization has a set browser they work with. Some of the greatest improvements we’ve seen recently around the creation and development of SPAs depends on a more current browser such as a current version of Google Chrome, FireFox or Internet Explorer 10+. Older browsers don’t have some of the ECMAScript v5 property support that some of the popular SPA presentation frameworks use. So before you go too far down this path you want to ensure you’ve done your research in this area.