The Slide explains all about single page applications. Beginers can start learning from this.

1. Single Page Applications (SPA)

2. Agenda
 What is Single Page Application
 Difference from traditional web application
 Why SPA?
 SPA Frameworks
 Challenges

3. Definition
• A single-page application (SPA), is a web application or web site that fits on a single web
page with the goal of providing a more fluid user experience akin to a desktop application.
• In a SPA, either all necessary code – HTML, JavaScript, and CSS – is retrieved with a single
page load or the appropriate resources are dynamically loaded and added to the page as
necessary, usually in response to user actions.
• The page does not reload at any point in the process, nor does control transfer to another
page.
• Interaction with the single page application often involves dynamic communication with
the web server behind the scenes.

4. Characteristics
 Chunking – the web page is constructed by loading chunks of HTML fragments and JSON data instead of receiving full
HTML from a web server on every request. (Backbone.js, jQuery, Upshot.js)
 Controllers – mess of JavaScript code that handles tangled DOM and data manipulations, application logic and AJAX calls
is replaced by controllers that separate views and models using MVC or MVVM patterns.
(Backbone.js, Knockout.js, JavascriptMVC)
 Templating – coding of UI and DOM manipulations are replaced by declarative binding of data to HTML templates.
(Knockout.js, Mustache, jQuery Templates, Underscore.js)
 Routing – selection of views and navigation (without page reloads) that preserves page state, elements and data
(Histrory.js, Crossroads.js, Backbone.js, pjax, HTML5 History API)
 Real-time communication – two-way communication of a client application and web server replaces one-way requests
from a browser (HTML 5 Web Sockets, Socket.io, SignalR)
 Local storage – capabilities of storing data on a browser for performance and offline access replace cookies and intensive
data loads from web server (HTML 5 Local storage).

5. Difference from traditional web application
 Traditional web page
 Request sent to server
 HTML Response from server
 Browser unloads previously loaded DOM
 Browser creates DOM for the response
 Browser renders DOM
 SPA
 Does not reload the page
 Load Resources (Html, CSS, JavaScript) on
initial page load or as required generally in
response to user action

6. Why to use SPA
 Performance is certainly better with client-side rendering if you do it right, but
this is not the most compelling reason to build a SPA. (Network speeds are
improving, after all.) With SPA we don't need to use extra queries to the
server to download pages.
 No page flickering since no page reload
 Faster UI, more interactive
 Less data transfer between clients and servers
 Caching is lot easier as static data is explicitly separated
 Faster Development

7. When to use SPA
 Native/Desktop like application experience is desired.
 Highly responsive site is desired. Real time communication
 Supports tons of rich UI components in multiple states on same page very efficiently.

8. Top Challenges in SPA
 Analytics
 Analytics code that run on every page load fails to work in case of SPA, as there is no page reload
 Browser constraints
 Back button behavior is not easy to maintain, manual coding efforts needs to be made to maintain the
browser state
 Bookmark handling, (every time we open the previously saved bookmark, the expected view needs to
be rendered)
 Security Concerns
 Single Page Apps are a little extra vulnerable to both Cross-Site Scripting (XSS) attacks and Cross-Site
Request Forgery (CSRF) attacks. We have to be little extra cautious while building SPA, to defuse such
attacks though server side apps are also vulnerable.