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.

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,

few distinct characteristics of the professional Single Page Application:

CHUNKING CONTROLLERS TEMPLATING ROUTING REAL-TIME COMMUNICATION LOCAL STORAGE

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)

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).

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.

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.

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.

.

Hieararchy of objects in an example HTML DOM

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.

Server ArchitectureThin 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.

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

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.

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.

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.