The Single Page Interface Manifesto
Updated: Jul 15, 2011
Origins of web technology
When Tim Berners Lee invented web he was looking for a system to publish scientific documents remotely accessible, visually attractive, easy to code and easy to use for a non-technical person.
In a scientific document, external cites to other documents is indispensable, in order that the reader may optionally develop the theme in question.
For these reasons the World Wide Web was conceived as a page (document) based system with hyperlinks.
Initially the Web was a world of static pages and links but soon the generation of dynamic pages and in general the use of the Web as a support for designing web-based applications complicated everything.
The arrival of web applications
For many years there has been a strong effort to adapt the web paradigm of pages and links to application development. In a web application the Berners' view of static documents and simple links do not exist.
Different application development approaches have been happening:
Now millions of web sites and web applications use AJAX to provide a better experience to end users thanks to more responsive user interfaces partially avoiding the annoying page reloads.
What are the disadvantages of page based navigation and development?
Every web developer knows how problematic is page navigation in a web application, besides of bandwidth wasting and process time rebuilding entire pages more problems make web development painful like unwanted caching, back/forward buttons, desynchronized forms caused by the "form auto-fill" feature of some browsers and so on. It is not uncommon to see web applications that hide the menus and buttons of the browser or using frames or iframes (e.g. banks) to avoid the problem of Back/Forward buttons.
Page based development forces a style of coding weird, repetitive (plenty of includes) and inefficient (both bandwidth and computing power) not found in desktop development.
What is what prevents intensive use of AJAX?
In the field of web development we are used to distinguish two kind of web solutions: web applications and web sites.
In the first case AJAX is becoming more and more used because this kind of applications do not share some requisites imposed for web sites. In web sites intensive use of AJAX is a problem.
In public web sites end users are used to the page concept, bound to the pages some requisites and services are required in any web site like:
Because these requisites intensive AJAX is discouraged in web sites.
However the difference between a "web site" and a "web application" is becoming smaller because almost any web site is a sort of "web application"...
Should we give up AJAX-intensive applications?
There are technical solutions for all above listed requisites.
Development of web sites based on a single Web page (SPI), is it possible?
This is the time to start this transition, developers and end users all of us will gain. We have the technology and modern browsers are qualified to achieve this objective.
To succeed in this "new" way of web development we must to accomplish all of previous requisites of any web site.
Goodbye pages, welcome states
Differencing between both state types is very important, because fundamental states will become web pages when needed. Fundamental and secondary differentiation is web site dependent.
To better understand both types of states we can study a real example: login validation.
In a classic page based applications typical login is built by using two pages, one for user and password and one showing user options if login validation was correct; the login page will be reloaded showing some error messages alongside the login form when login entry is wrong.
In a SPI web, initial login and the user options page could be the fundamental states, and error messages alongside login could be secondary states.
Another example, a web site based on pages to be converted to SPI, in this case fundamental states will be the pages and secondary states will be page states with minor changes, not important enough for bookmarking or to be traversed by crawlers.
Single Page Interface and Bookmarking
Different pages have different URLs, following the SPI route how can we change a state and at the same time the URL without reloading to allow this new state can be bookmarked by end users?.
There is a trick, using the "reference" part of URLs ("hash fragment", shebang or hashbang), this is the last
part, if present, following the # character. This reference is used to scroll the page
to the concrete location specified by some <a name="ref"></a> mark.
This reference part if changed does not reloads the page, hence if the URL reference
is changed by using
When end user wants to come back again to the bookmarked page, the target state is specified in the reference part of the URL, the server will be requested, unfortunately the reference part is not sent to the server because reference part does nothing to do with remote location using HTTP, hence we will need a post-load process.
The server will return an initial page in which the target state is not
the specified, however the
Another option, better than hashbangs, arises with the advent of HTML 5, the HTML 5 History API.
Single Page Interface and Search Engine Optimization (SEO)
The easiest way to get our web site is processed by search engine crawlers is to offer two different navigation modes, SPI for end users, pages for web crawlers.
The next example shows a link with this idea:
<a href="URL page" onclick="return false">…</a>
navigation is disabled by "
In the field of a SPI application, URLs being used for page/state navigation must contain the target state, the same type of URLs used in SPI bookmarking that is using the reference part to indicate the target state, or the target is directly written as a normal parameter, the later is preferred because it avoids a server request, of course "pretty URLs" can also be used.
Currently Google already crawls "AJAX URLs", that is, URLs containing the target state
in the reference part following
At the same time the SPI web framework can add specific code to the onclick handler
SPI and Back/Forward buttons
Back/Forward buttons are a source of problems on conventional page based web sites and should be avoided as soon as possible. In spite of users are used to avoid Back and Forward buttons when submitting a form with user data (because it carries the risk of buying twice the same plane ticked or book), use of Back/Forward buttons is very widespread.
Apparently the SPI paradigm breaks the traditional way of navigation of a web site, because in theory Back/Forward buttons has no sense in SPI (no pages) and web browsers do not provide a good control of these buttons.
SPI and services based on page visits
Ads services and page visit counters are based on how many pages have been loaded. In both cases you can use hidden <iframe> elements containing an empty web page with the required scripts to execute this kind of services.
In the case of advertisement services such as Google AdSense, dynamic insertion of <iframe> implies loading new ads therefore every change state could imply a new reload of <iframe> with ads. Google AdSense seems to detect when the AdSense script is executed within a <iframe> and takes into account the contents of the container page. It may be desirable to add some kind of parameter that identifies the fundamental state that is loading the <iframe>.
SPI and pop-up windows
When a new page window is created the SPI model is broken. Fundamentalism is bad, there is no problem if the state of this new window has nothing to do with the state of the parent window, in this case pop-up windows are fine.
The problem arises when any action performed on the pop-up window (modal or not modal) has some influence on the parent window, coordination between pages is complicated. For instance there is no a web standard to create modal windows because the page concept has traditionally always been an independent element and therefore its life cycle is difficult to coordinate from another page.
Fortunately this problem has solution for some time in SPI, you can simulate modal or not modal windows inside the same web page, no new real page window is created. In the case of non-modal windows, any HTML element with absolute positioning can be a "non-modal window" and you can create modal windows by using absolute positioning, controlling z-index and opacity of elements "on top" of the page ("modal layers"). These solutions are valid in a SPI context.
With a little effort, even the state which shows a modal window may be a fundamental state and therefore navigable by search engine bots.
A cultural shift for web developers
Most of web developers (and web frameworks) think the Web as based on pages, page reduction to a single page implies a radical change of mind and how we make web sites and applications. This change is not so radical thanks to AJAX, AJAX is today mainstream and has reduced the number of pages of typical web sites, in summary it has brought us near of this "new" SPI development model.
In the new SPI web the <form> tag disappears and in general the need of sessions used as data managers following page sequences. Now the protagonist is the page client with some symmetry in server (the page in server). In fact, because we get rid of page coordination with sessions we are freed of a source of problems like the bad practice of some users who open several windows with the same page, this practice usually breaks the session and the application in general.
SPI programming is based on events the same as in desktop, because in desktop most of applications runs in the same frame window and when child windows exist these are fully managed by the main window and genuinely modal.
Following the paradigm evolution of web development, this "new" approach could be named Model 4.
A cultural shift for end users?
Not very much, with bookmarking and Back/Forward simulation end users are not going to differentiate a SPI web site and the same page based, furthermore the SPI site will be more responsive and the typical blinking and scrolling of page navigation is removed.
Technical viability today
This manifesto is not a statement of intentions but the expression of the desire to promote a "new" way of building websites that are already real. The above technical study has always had the Java web framework ItsNat as the technological base of SPI web site development. In spite of ItsNat was conceived from day one to this kind of applications/sites, previous techniques could be applied with other web frameworks or these frameworks could evolve to provide facilities for this kind of SPI web sites with page simulation requirements.
A real world example
The web Innowhere.com/jnieasy is made with ItsNat in server and a good example of SPI web site because it sums up all requirements of a SPI web site, explained in this document, to be a satisfactory substitute of a traditional site. In fact, the new SPI version replaces, with no significative aesthetic of functional change, the previous version based on pages.
The Manifesto in other languages
Ukranian thanks to Mario Pozner
Russian thanks to Andrey Geonya, it may slightly out of date because this manifesto is "alive"
Serbo-Croatian thanks to Jovana Milutinovich
Links pointing to the manifesto
Discussion at DZone
Discussion at TheServerSide.com
Discussion at YCombinator.com
Discussion at JavaHispano.org (in Spanish)
Author of manifesto: Jose Maria Arranz Santamaria