Single-page applications (SPAs) are finally starting to get some recognition, according to Dru Henke, executive director at NVISIA, who predicted in the next few years that all applications developed will be single-page apps.

SPAs have been around since the early 2000s, but due to the lack of expertise and tools, they haven’t really had much popularity.

“They really kind of started in their emphasis about 10 years ago, but were difficult to write at that point in time,” said Henke. “Very few people had the expertise and saw it as too big of a challenge to take on in the mainstream enterprise setting.”

Today, with the variety of tools and IDEs that have been developed and expanded, as well as a growing level of JavaScript expertise, creating SPAs is becoming easier for developers, Henke explained. JetBrains offers IntelliJ IDEA. Google offers AngularJS and Google Web Toolkit. Ember offers Ember.js. And there are many more.

“The tools have matured and the frameworks are now more sophisticated, so developers don’t have to write so much plumbing from scratch,” Henke said.

Single-page apps, unlike traditional applications, are apps where instead of a page refreshing every time a user clicks on a link, only small bits of the application refresh. From a user perspective it seems that they are staying on the same page the whole time. Common examples of SPAs are Google’s Gmail or Microsoft’s Outlook Web Access interfaces.

“Users never really leave the page,” said Andrew Connell, a developer who specializes in Microsoft SharePoint and content-management systems. “Rather, by leveraging JavaScript, CSS and HTML fragments, parts of the page are changed depending on the actions performed by the user. It gives the user more of an ‘application’ feel rather than a Web page feel, without having to install anything.”

Single-page applications are different from loosely coupled architecture, but the two fit effortlessly together, according to Henke. Loosely coupled architecture separates the business layer from the presentation layer using JSON and/or XML, while SPAs uses JSON and/or XML in addition to HTML, JavaScript and CSS to separate layers.

(Related: More about loose coupling)

“SPAs fit in perfectly with loosely coupled architecture, in part because SPAs generally exchange information with a service layer via JSON and/or XML,” he said. “Both of these data formats are very interoperable and ‘neutral’ with respect to server-side technologies and, generally, loosely coupled service layers can already speak in at least one of these formats.”

SPA benefits
One of the biggest benefits of SPAs is reach, according to Connell.

“Where you would traditionally build a desktop or mobile client application, building an SPA allows developers to focus on one implementation that everyone can access, provided they are online and connected,” he said.

According to Henke, SPAs in general are more sophisticated than traditional apps.

“The challenge you get into when writing multipage apps is trying to maintain the state of what a user is doing,” said Henke. “That state management becomes a limiting factor on how sophisticated your application can be.”

In the enterprise, user experience is becoming more important than ever. When call centers and other large-scale internal-facing apps went from being rich clients running locally to being Web-based, users gave up a lot of usability, according to Henke. With the impact of mobile, users have gotten used to sophisticated apps and expect that same kind of experience on their browser, and that is where SPAs come in play, he believed.

“I feel any enterprise that doesn’t choose to go to single-page apps will find themselves on an island if they don’t adopt,” he said.

Henke went on to explain that the level of efficiency by developing a single-page application is a lot greater than just a page-based app where a user needs to load and reload pages after every action.

Important SPA tips
Making SPAs search-engine friendly is one of the most challenging things when it comes to SPAs, according to Connell.

“In the cases of an anonymous SPA, developers will need to ensure that not only they have a good deep-linking strategy implemented, but also a good way to expose this to the search-engine crawler,” he said.

Developers also need to consider the online/offline status of an application. With SPAs, users can load the app and go offline, according to Connell.

“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,” he said. “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.”

Henke believed that if developers are looking to build a more complex and stylish application, the answer is almost always SPAs.

“If you are trying to present something that is slick-looking with a high degree of polish from a user experience level, then you are almost always going to be pushed to a single-page app because you don’t have the screen refresh happening every time you do something in a browser,” he said.

Lastly, when deciding whether or not to build an SPA, developers need to consider whom they are trying to target.

“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+,” said Connell. “Older browsers don’t have some of the ECMAScript v5 property support that some of the popular SPA presentation frameworks use.”

Connell said that before developers get too far into the development process, they should do their research first.