Using a Single Page Application Across Multiple Platforms

We’ve all been there, started reading an article or browsing a webpage on a desktop and all of the sudden we are on the move, so you switch to your mobile device while on the train and then switch to your iPad at the coffee shop. Consumers are viewing content on mobile devices now, more than ever. As such, organizations have realized the need for a seamless transition between desktop, browser, mobile browser and native mobile apps. Accordingly, IT executives are looking for ways to streamline the development of applications for web, mobile web, and native mobile users to realize cost savings and improve customer experience. Recently the adoption of Single Page Applications (SPA) by large enterprises has taken off, but tech giants such as Google (News - Alert) and Twitter have previously used SPA as it typically yields a website that feels more like an “app” than a traditional web page, something that users have come to expect.

SPAs feel more like a Windows desktop or native mobile application than a web page. Popular SPAs include Gmail, Google Maps and Twitter (News - Alert). SPAs often provide a better user experience by avoiding the long pauses associated with classic web application page refresh. A well-designed SPA responds better over low bandwidth connections (after the initial page load) than traditional web pages.

Furthermore, organizations can reap substantial benefits by sharing their business logic across multiple channels, including both web and native mobile. SPA’s inherent separation of UI and application logic opens the door to sharing common application logic and testing assets, allowing an organization to develop a web application that quickly addresses both web and mobile web users.

Adopting SPA

Moving to the SPA architecture does require some changes in process, tooling and skills. Some development factors to consider when evaluating the impact of SPAs on your organization:

• JavaScript errors can have a much bigger impact on users than standard HTML style sheet bugs so it is important to invest time and tooling in browser compatibility testing to include all supported browser types as well as variations in browser versions.
• Be prepared to test for, debug and possibly design periodic full-page refreshes to reset the browser as to avoid possible memory leaks.
• Develop client-side debugging skills for event-driven code that requires a different mindset than traditional multi-page applications.
• Understand resource bundling, minification and browser caching to reduce initial page load times.
• SPA’s JavaScript code relies on the ability of each user’s web browser to render the JavaScript consistently and correctly. Therefore, the maturity of JavaScript libraries are key, allowing developers to isolate their code from cross-browser variations while leveraging tried-and-true code. 
• Wizard type applications and variations of master-detail data sets, particularly where the user only needs a small subset of the data at any time are often good candidates for an SPA.

Both the risk and cost associated with SPA adoption have subsided to the point where SPAs are a viable option for mainstream IT development. Additionally, with the increase of screens per user, it is time for enterprises to seriously evaluate the benefits of SPA architecture’s characteristics for the best user experience.  

NVISIA on Single Page Applications (Mark Panthofer) from NVISIA