|To keep things simple I'll describe the client interacting with "the server" here, but these days your application may interact with many servers or cloud services.|
Compare this to the traditional model where the client relies on the server for its content, a constant request-and-response interaction where the server generates content based on the client's URL requests and the client mostly just loads and renders the server's response (with of course some embedded js to provide a little interactivity).
One big difference between these two approaches is user experience — the client-driven approach can provide a smoother user experience similar to a desktop application while the constant page reloads of the server-driven approach disrupt the user experience (and provide poorer performance).
|In addition to Single Page Application (SPA) you'll also see the term Single Page Interface (SPI).|
It's important to note that there's no sharp boundary between server-driven web applications and client-driven web applications. Think of it as a continuum — on one end are applications highly reliant on the server and with minimal client interactivity, on the other end you have client-driven SPAs. However, along this continuum you can also have "part-time SPAs" which may have some full page reloads but these might be few and far between, with pages persisting for significant periods and providing a high level of client-side processing. Look at this bit from MSDN's project Silk Chapter 1 (see Resources section below for more on this MSDN project):
from MSDN's Project Silk: "Chapter 1: Introduction"
- minimal page loads (for SPAs, a single page load)
- emphasis on client-side execution with little or no reliance on server for generating views. Navigation and application state is also managed/maintained on the client
- data copied to the client where it can be manipulated (e.g., filters, sorts) and used to generate views without use of server processes (this isn't a hard and fast rule – when dealing with large datasets some server-side processing may be preferable). Data is also often cached and even prefetched.
- server requests are asynchronous, usually as Ajax calls with results handled by success/failure callbacks. As a result a js web app is generally non-blocking, i.e., the page does not "freeze up" while a server request is pending.
- rich UI with emphasis on user experience including fluid state changes (often with transition effects). Components are usually stateful and incorporate lifecycle events such as create, init, destroy.
While not required, SPAs also have some frequently found traits, such as employing an MV* lib/framework, loose coupling via an event bus (e.g. PubSub), use of the JSON data format.
As you might expect, all of this can be a heavy lift. Maintaining data on the client, keeping local data in sync with your backend master copy, dealing with more functional (and complicated) UI components, managing your app's state and navigation, and learning a constantly changing/expanding set of libs and tools has a cost. But if your goal is to create highly functional applications that run on many platforms these costs can be worth the benefits. These benefits are the focus of the next section.
- UI more like desktop applications, without the constant disruption of page reloads
- performance can be better because the application can respond without making a server request
- client can talk directly to cloud services (though cross-domain issues may require use of JSONP or CORS)
- reduced web server load
On the other hand, SPAs don't compare so well to server-based web applications in other respects:
- search engine indexing is harder. Crawlers won't "see" all of your content unless you do extra work to make things visible. If SEO is important to you then this can be a major drawback (tho HTML5 PushState helps with this)
- development of SPAs is generally more complex/costly than server-driven applications (though of course in the end you get more for your money, e.g. better UI/UX)
When comparing server-driven to client-driven web applications the nature of the application is key — if you're primarily surfacing static content like documents and images then server-driven is probably the best bang for the buck, but if your application is highly interactive, especially if it is letting the user explore data (what-if analysis, interactive graphs, etc.) then you should consider a SPA.
The comparison of SPAs to desktop and mobile apps is more complicated, but SPAs do have several advantages, many deriving from being browser-based:
- your execution context is always available, since browsers are everywhere
- there is the advantage of zero install — users will always have the latest version of your app, not a stale locally installed version that needs to be updated (so no need to support old versions, either)
- potential for cross-platform application (unlike native mobile apps, for example, which are platform-specific). This is especially true if you are just targeting HTML5/mobile. more on this below...
- bypass native app stores – no limit on content, no censorship
It's worth highlighting the cross-platform potential of SPAs, especially in the heterogeneous world of mobile. For example, to deliver an application's functionality via a native app on both iOS and Android you'll need 2 development teams and end up with 2 codebases. Obviously you want to avoid this if you can — bad enough to double your development work, but these costs compound when you add ongoing maintenance (applying bug fixes, keeping the versions in sync as you release new features, etc.). The SPA approach can maximize code reuse, with minimal target-specific code (variances are mainly related to the presentation layer, which needs to adjust to the display it's running on and maybe styled to the target's UI conventions). Still, there are limitations to what you can do, and once again many of these are related to being browser-based (e.g., you are constrained by the browser's security sandbox).
|Regarding cross-platform applications, there are other options like Titanium Appcelerator, PhoneGap and AIR. I cover these very briefly in part 2 of this primer.|
So, how do SPAs stack up against native desktop and mobile applications? There definitely are some drawbacks:
- a SPA's initial load will take longer than a native app since your code needs to load from a remote server (though caching can help); in general performance isn't going to be as fast as a native app's
- If the device has no network connection then your application won't load. And creating an offline web app is still hard
- a browser-based SPA will be playing in that browser security sandbox, with restricted access to file system and OS APIs
- related to above, browser-based apps don't have the same device access as a native app — for example you have geolocation and accelerometer but no camera access yet (though there are hybrid workarounds like PhoneGap)
- not fully native in look and feel. For appearance you can come close with clever CSS, but without using native widgets you won't have full native functionality (e.g., Android text input has built in spellcheck, your web control won't act exactly the same).
- one-touch access to a web app is hard on some mobile
Resources on JS web applications:
Some good books:
- Addy Osmani has several books, both hardcopy and online, see http://addyosmani.com/blog/ for a complete list.
- Mikito Takada's (a.k.a. Mixu) single page app online book: http://singlepageappbook.com
- Alex MacCaw's post "Asynchronous UIs - the future of web user interfaces"
- This Addy Osmani article has a section: "Why Might SPAs Can Be Better Than Multi-Page Applications?"
- Addy Osmani slide show with an overview of tech used in js web apps: Addy Osmani's slide deck for his talk "Tools for jQuery Application Architecture"
- Herding Code podcast: 155 – Ward Bell on Single Page Applications and Breeze
- Tessa Harmon's Slideshare overview of SPAs
- Zdnet's recent Future of web apps article
And since there's a lot of talk these days about whether you should be creating mobile native apps or web apps (or hybrids) here are some interesting links on this topic:
- The Financial Times take on web apps v. native apps and Smashing has a case study (from 2013) on the FT web app
- Google IO video 2011 : Reto Meier and Michael Mahemoff "HTML5 v. Android: Apps or Web for Mobile"
- Michael Mahmedoff throws in the towel (2013): "Going native: Why a veteran web developer finally turned to OS-native apps"
- Paul Irish sends up distress flares (2013): "The mobile web is dying and needs your help"
- Nice overview of Native Apps, Web Apps, and Hybrid Apps
- An interesting slide deck looking at HTML5 web apps versus native apps for mobile (gets more interesting about midway...)
- An in-depth analysis of performance web apps v. native apps: "Why mobile web apps are slow" (comments here are useful, too)
- A view from Wired: "Native Apps vs. Mobile Web: Breaking Down the Mobile Ecosystem"
Related dlgsoftware posts
Original version: October 2013
Copyright © Dan Gronell 2013. Licensed under the Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 unported license.
SPA Demo Application
Backbone Demo Application
- Addy Osmani's blog
- Derick Bailey's Backbone posts
- Murphey's JQuery Fundamentals (original)
- Crockford's JS videos
- MSDN Project Silk
- Primer on Flex/AIR Multiscreen Development
- Primer on Mobile App Development w/Flex 4.5
- Primer on Flex 3 Component Lifecycle
- Primer on Flexlib MDI
all require Flash Player!
AIR mobile dev
- AIR mobile dev Tips
- AIR and Android Back key
- AIR, StageWebView, displaying local content
- AIR for Android memory issue w/large images