a brief introduction regarding single page application and using in angularjs

1. S.P.A-SINGLE PAGE APPLICATION
It's also single-page interface (SPI), 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(same) 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.

2. S.P.A
The page does not reload at any point in the process, nor does control transfer
to another page, although modern web technologies (such as those included in
HTML5) can provide the perception and navigability of separate logical
pages in the application. Interaction with the single page application often
involves dynamic communication with the web server behind the scenes.
The term single-page application was coined by Steve Yen in 2005,

3. few distinct characteristics of the
professional Single Page Application:

CHUNKING

CONTROLLERS

TEMPLATING

ROUTING

REAL-TIME COMMUNICATION

LOCAL STORAGE

4. 
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, pjax, jQuery,
Upshot.js)

CONTROLLERS-JavaScript code that handles complex 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)

5. 
Routing – selection of views and navigation (without
page reloads) that preserves page state, elements and
data (History.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 (HTML5 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
(HTML5 Local storage).

6. Javascript frameworks(angularjs)

AngularJS is a fully client-side library. AngularJS's templating is
based on bidirectional data binding.

Data-binding is an automatic way of updating the view whenever
the model changes, as well as updating the model whenever the
view changes.

The html template is compiled in the browser. The compilation step
creates pure html, upon which the browser re-renders into the live
view. The step is repeated for subsequent page views.

In traditional server-side html programming, concepts such as
controller and model interact within a server process to produce
new html views.

In the AngularJS framework, the controller and model state are
maintained within the client browser. Therefore new pages are
generated without any interaction with a server.

7. 
Websockets:

WebSockets are a part of HTML5 spec and is used for single page apps

Browser plugins:

Asynchronous calls to the server may also be achieved using browser
plug-in technologies such as Silverlight, Flash, or Java applets.

Data transport (XML, JSON and AJAX):

Requests to the server typically result in either raw data (e.g. XML or
JSON), or new HTML being returned. In the case where HTML is
returned by the server, JavaScript on the client updates a partial area of
the DOM (Document Object Model). When raw data is returned, often a
client-side JavaScript XML / (XSL) process ( and in case of JSON a
template ) is used to translate the raw data into HTML, which is then used
to update a partial area of the DOM.

8. DOM

The Document Object Model (DOM) is a cross-platform and language-
independent convention for representing and interacting with objects in
HTML, XHTML and XML documents.

Objects in the DOM tree may be addressed and manipulated by using
methods on the objects.

The public interface of a DOM is specified in its application
programming interface (API).

The history of the Document Object Model is intertwined with the
history of the "browser wars" of the late 1990s between Netscape
Navigator and Microsoft Internet Explorer, as well as with that of
JavaScript and JScript, the first scripting languages to be widely
implemented in the layout engines of web browsers.

9. .
Hieararchy of objects in an example HTML DOM

10. DOM implementation

DOM supports navigation in any direction (e.g., parent and previous
sibling) and allows for arbitrary modifications, an implementation must
at least buffer the document that has been read so far (or some parsed
form of it).

Layout engineS:

Web browsers rely on layout engines to parse HTML into a DOM. Some
layout engines, such as Trident/MSHTML, are associated primarily or
exclusively with a particular browser, such as Internet Explorer.

Others, such as Blink, WebKit, and Gecko, JavaScript rendered in html
pages, collection of web pages shared by a number of browsers, such as
Google Chrome, Opera, Safari, and Firefox. The different layout
engines implement the DOM standards to varying degrees of
compliance.

11. Server Architecture
Thin server architecture-
A SPA moves logic from the server to the client.This results in the role of the web
server evolving into a pure data API or web service.
Thick stateful server architecture-
The server keeps the necessary state in memory of the client state of the page. In this way, when any request
hits the server (usually user actions), the server sends the appropriate HTML and/or JavaScript with the
concrete changes to bring the client to the new desired state (usually adding/deleting/updating a part of the
client DOM). At the same time, the state in server is updated. Most of the logic is executed on the server,
and HTML is usually also rendered on the server. In some ways, the server simulates a web browser,
receiving events and performing delta changes in server state which are automatically propagated to
client.
Thick stateless server architecture - the client page sends the necessary data of the current state to the
server, usually through AJAX requests. The server with this data is able to reconstruct in some way the
client state of the page part going to be modified and generate the necessary data or code, for instance as
JavaScript code, returned to the client to bring it to a new state, usually modifying the page DOM tree
according to the action which motivated the request.
This approach requires more data sent to server and may require more computational resources per request to
reconstruct partially or fully the client page state in server. At the same time, this approach is more easily
scalable because there is no per client page data kept in server and therefore AJAX requests can be
dispatched to different server nodes with no need of session data sharing or server affinity.

12. Challenges with the SPA model

Because the SPA is an evolution away from the stateless page-redraw
model that browsers were originally designed for, some new challenges
have emerged. Each of these problems has an effective solution with:
i. Client-side JavaScript libraries addressing various issues.
ii. Server side web frameworks that specialize in the SPA model.
iii. The evolution of browsers and the HTML5 specification aimed at the
SPA model.
A) SEARCH ENGINE OPTIMIZATION
B) BROWSER HISTORY
C) PAGE LIFE CYCLE

13. SEO

Because of the lack of JavaScript execution on crawlers of all popular
Web search engines, SEO (Search engine optimization) has historically
presented a problem for public facing websites wishing to adopt the SPA
model.

Google currently crawls URLs containing hash fragments starting with
#!,. This allows the use of hash fragments within the single URL of an
SPA.

Special behavior must be implemented by the SPA site to allow
extraction of relevant metadata by the search engine's crawler.

For search engines that do not support this URL hash scheme, the
hashed URLs of the SPA remain invisible.

14. Browser History

The model breaks the browser's design for page history navigation
using the Forward/Back buttons. This presents a usability impediment
when a user presses the back button, expecting the previous screen state
within the SPA, but instead the application's single page unloads and the
previous page in the browser's history is presented.

The traditional solution for SPA's has been to change the browser URL's
hash fragment identifier in accord with the current screen state. This can
be achieved with JavaScript, and causes URL history events to be built
up within the browser. As long as the SPA is capable of resurrecting the
same screen state from information contained within the URL hash, the
expected back button behavior is retained.

15. Page Lifecycle
An SPA is fully loaded in the initial page load and then page regions are replaced or updated
with new page fragments loaded from the server on demand.

To avoid excessive downloading of unused features, an SPA will often progressively download
more features as they become required, either small fragments of the page, or complete screen
modules.

In this way an analogy exists between "states" in an SPA and "pages" in a traditional web site.
Because "state navigation" in the same page is analogous to page navigation, in theory any page
based web site could be converted to single-page replacing in the same page only the changed
parts result of comparing consecutive pages in a non-SPA.

The SPA approach on the web is similar to the Single Document Interface (SDI) presentation
technique popular in native desktop applications.

Running locally:

Some SPAs may be executed from a local file using the file URI scheme. This gives users the
ability to download the SPA from a server and run the file from a local storage device, without
depending on server connectivity. If such an SPA wants to store and update data, it must use
browser-based Web Storage. These applications benefit from advances available with HTML5.