A single-page application, also known as single-page interface, 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, although modern web technologies 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, though the concept was
discussed at least as early as 2003 and Stuart Morris wrote the Self-Contained website at
http:slashdotslash.com with the same goals and functions in 2002.
Modern browsers that can parse HTML5 allow developers to shift the UI and application
logic from web servers to the client. Mature open-source libraries support building of
SPA without digging too deep into JavaScript trenches and fighting with technology problems.
There are few distinct characteristics of the professional Single Page Application:
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.
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. Templating – coding of UI and DOM manipulations
are replaced by declarative binding of data to HTML templates.
Routing – selection of views and navigation that preserves page state, elements and data
Real-time communication – two-way communication of a client application and web server replaces
one-way requests from a browser Local storage – capabilities of storing
data on a browser for performance and offline access replace cookies and intensive data
loads from web server.
Technical approaches There are various techniques available that
enable the browser to retain a single page even when the application requires server
communication. JavaScript Frameworks
Web browser JavaScript frameworks, such as AngularJS, YUI App Framework and React have
adopted SPA principles. 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.
The YUI App Framework is a rollup of the App, Model, Model List, Router, and View components,
combined to form a simple MVC-style framework for writing single-page JavaScript applications.You
can use these components separately or together to create anything from simple non-interactive
views to rich applications with URL-based routing, data binding, and full client-server
synchronization. AJAX
The most prominent technique currently being used is Ajax. Predominantly using the XMLHttpRequest
object from JavaScript, other AJAX approaches include using IFRAME or script HTML elements.
Popular libraries like jQuery, that normalize AJAX behavior across browsers from different
manufacturers, have further popularized the AJAX technique.
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
Requests to the server typically result in either raw data, 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. When raw data is returned, often a client-side JavaScript XML
/ process is used to translate the raw data into HTML, which is then used to update a
partial area of the DOM. 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.
This architectural shift has, in some circles, been coined "Thin Server Architecture" to
highlight that complexity has been moved from the server to the client, with the argument
that this ultimately reduces overall complexity of the system.
Thick statefull 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, the server
sends the appropriate HTML and/or JavaScript with the concrete changes to bring the client
to the new desired state. 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.
This approach needs more server memory and server processing, but the advantage is a
simplified development model because a) the application is usually fully coded in the
server, and b) data and UI state in the server are shared in the same memory space with no
need for custom client/server communication bridges.
Thick stateless server architecture Is a variant of the statefull server approach.
In this case, the client page sends data representing its current state to the server, usually through
AJAX requests. Using this data the server is able to reconstruct the client state of
the part of the page which needs to be modified and can generate the necessary data or code,
for instance as JSON or JavaScript, which is returned to the client to bring it to a
new state, usually modifying the page DOM tree according to the client action which
motivated the request. This approach requires that more data be sent
to the server and may require more computational resources per request to reconstruct partially
or fully the client page state in the server. At the same time, this approach is more easily
scalable because there is no per client page data kept in the server and therefore AJAX
requests can be dispatched to different server nodes with no need for session data sharing
or server affinity. 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. 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: Client-side JavaScript libraries addressing
various issues. Server side web frameworks that specialize
in the SPA model. The evolution of browsers and the HTML5 specification
aimed at the SPA model. Search engine optimization
Because of the lack of JavaScript execution on crawlers of all popular Web search engines,
SEO 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.
Alternatively, applications may render the first page load on the server and subsequent
page updates on the client. This is traditionally difficult, because the rendering code might
need to be written in a different language or framework on the server and in the client.
Using logic-less templates, cross-compiling from one language to another, or using the
same language on the server and the client may help to increase the amount of code that
can be shared. Because SEO compatibility is not trivial in
SPAs, it's worth noting that SPAs are commonly not used in a context where search engine
indexing is either a requirement, or desirable. Use cases include applications that surface
private data hidden behind an authentication system. In the cases where these applications
are consumer products, often a classic "page redraw" model is used for the applications
landing page and marketing site, which provides enough meta data for the application to appear
as a hit in a search engine query. Blogs, support forums, and other traditional page
redraw artifacts often sit around the SPA that can seed search engines with relevant
terms. Another approach used by server centric web
frameworks like the Java based ItsNat is to render any hypertext in server using the same
language and templating technology. In this approach the server knows with precision the
DOM state in client, any big or small page update required is performed generating in
server, and transported by AJAX, the exact JavaScript code to bring the client page to
the new state executing DOM methods. Developers can decide which page states must be crawlable
by web spiders for SEO and be able to generate the required state in load time generating
plain HTML instead of JavaScript. In case of ItsNat framework this is automatic because
ItsNat keeps the client DOM tree in server as a Java W3C DOM tree, rendering of this
DOM tree in server generates plain HTML in load time and JavaScript DOM actions for AJAX
requests. This duality is very important for SEO because developers can build with the
same Java code and pure HTML based templating the desired DOM state in server, on page load
time conventional HTML is generated by ItsNat making this DOM state SEO compatible. As of
version 1.3 ItsNat provides a new stateless mode, client DOM is not kept in server because
in stateless mode client DOM state is partially or fully reconstructed in server when processing
any AJAX request based on required data sent by client informing of the current DOM state;
the stateless mode may be also SEO compatible because SEO compatibility happens in load
time of the initial page not affected by stateful or stateless modes.
Client/Server code partitioning One way to increase the amount of code that
can be shared between servers and clients is to use a logic-less template language like
Mustache or Handlebars. Such templates can be rendered from different host languages,
such as Ruby on the server and JavaScript in the client. However, merely sharing templates
typically requires duplication of business logic used to choose the correct templates
and populate them with data. Rendering from templates may have negative performance effects
when only updating a small portion of the page—such as the value of a text input within
a large template. Replacing an entire template might also disturb a user's selection or cursor
position, where updating only the changed value might not. To avoid these problems,
applications can use UI data bindings or granular DOM manipulation to only update the appropriate
parts of the page instead of re-rendering entire templates.
Browser history With an SPA being, by definition, "a single
page", 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.
To further address this issue, the HTML5 specification has introduced pushState and replaceState
providing programmatic access to the actual URL and browser history.
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 presentation technique popular in native desktop applications.
References ^ a b Flanagan, David, "JavaScript - The Definitive
Guide", 5th ed., O'Reilly, Sebastopol, CA, 2006, p.497
^ "Inner-Browsing: Extending Web Browsing the Navigation Paradigm". Retrieved 2011-02-03.
^ "Slashdotslash.com: A self contained website using DHTML". Retrieved 2012-07-06.
^ http:yuilibrary.comdocs ^ "Thin Server Architecture Working Group".
Retrieved 2011-12-11. ^ "The Single Page Interface Manifesto". Retrieved
2010-11-12. ^ "Derby". Retrieved 2011-12-11.
^ "Sails.js". Retrieved 2013-02-20. ^ "nCombo". Retrieved 2013-01-31.
^ "Tutorial: Single Page Interface Web Site With ItsNat". Retrieved 2011-01-13.
^ HTML5 ^ Michael Mikowski. "How to optimize single
page sites for search engines". Retrieved 6 January 2014. "When Google and other search
engines index websites, they don’t execute JavaScript"
^ "What the user sees, what the crawler sees". Retrieved January 6, 2014. "the browser can
execute JavaScript and produce content on the fly - the crawler cannot"
^ "Making AJAX Applications Crawlable". Retrieved January 6, 2014. "Historically, AJAX applications
have been difficult for search engines to process because AJAX content is produced"
^ "Making AJAX Applications Crawlable". Retrieved 2011-01-13.
^ "ItsNat v1.3 release Notes". Retrieved 2013-06-09. External links
Migrating Multi-page Web Applications to Single-page Ajax Interfaces: http:arxiv.orgcs/0610094
The Single Page Interface Manifesto Google's AngularJS
Facebook's React