I'm the father of ItsNat AJAX Java web framework, JNIEasy, LAMEOnJ, JEPLayer and JEPLDroid libraries (and very old stuff like XPDOM), supporter of the Single Page Interface (SPI) paradigm, writer of the SPI manifesto and currently Android native guy. Jose Maria has posted 28 posts at DZone. You can read more from them at their website. View Full User Profile

Tutorial: Single Page Interface Web Sites

  • submit to reddit

Several weeks ago  The Single Page Interface Manifesto was published, promoting a "new" world of web sites based on a single page simulating pages when needed.

Now it's time for a tutorial to build this kind of SPI web sites based on ItsNat framework.

The Single Page Interface (SPI) approach is not new, it has been used since the early days of DOM. AJAX has made SPI mainstream thanks to some web frameworks, server and client centric, today most of the innovation in web is taken place in the SPI centric way of development.

Beyond SPI web applications... SPI web sites SEO compatible

In spite of SPI is very popular on pure web applications, is almost fully unknown on web sites. Web sites are based on (many) pages because they have some strong requirements like compatibility with search engines (SEO), bookmarking, Back/Forward buttons and some services based on pages like visit counters.

The Single Page Interface Manifesto showed how we can provide these features on SPI applications. The trickiest problem is Search Engine Optimization (SEO compatibility), this requirement implies that our web site must be page based for web crawlers and at the same time SPI for normal (with JavaScript enabled) users.

ItsNat is a server-centric framework ready to create this kind of SPI web sites; ItsNat approach is very simple, the server keeps a DOM tree of the page in server and any change to the DOM tree in server with Java W3C DOM API is automatically replicated in client by ItsNat. Client events are transported to the server by AJAX and converter to Java W3C DOM Events when there is some event listener registered in server.
Templating is based on pure HTML files (view logic is coded with Java W3C DOM code), these templates can be pages and fragments. Fragment templates are pure HTML files which only the content in <body> is used (optionally <head> can be used), loaded when needed by developers and converted to DOM. User code in any time can insert new markup loaded from fragment templates with DOM API into the DOM tree of the single page. ItsNat automatically inserts this new code in client using innerHTML when possible. When innerHTML property is set any browser processes this markup with the built-in native parser, hence performance is ever better than parsing fully a web page on load time (including full change of the page with innerHTML) because parsing and building a complete DOM Document object is ever more time consuming than any fragment.

Avoding repetition in templates

Almost any web site repeats the same pattern, headers and footers are shared between all pages with small modifications and in the simplest case there is one zone or content area going to be changed in a page basis. In page based development this implies all templates repeat headers and footers usually with some ugly parameterized include directives.

In ItsNat and SPI, header and footer are designed once in the single page template of our web site and each page is now a page fragment only including the markup going to be included into the content area of the single page. Headers and footers can be changed accordingly using DOM APIs or with other small page fragments when needed.

How can our web site be page based and SPI at the same time?

So far we have seen how ItsNat works in SPI and how to convert web sites to SPI, no word about the promise of SEO, because any JavaScript code is ignored by web crawlers including any JavaScript code sent by ItsNat to automatically synchronize the client page.

The obvious solution is to develop two web sites, one for web crawlers (page based) and one (SPI) for normal users with JavaScript enabled. This is not needed with ItsNat.

ItsNat has a key feature named fast-load mode.

If fast load mode is disabled the initial page sent to the client as markup is the page template and DOM operations done in load time in server by developer code are sent as JavaScript. This mode is not SEO friendly because the page template, now the structural pattern of our web site, does not contain the content markup required, this content markup is inserted from page fragments depending on the initial state (previously the page), going to be initially loaded, that is calling DOM APIs hence sent as JavaScript code ignored by web crawlers.     

In fast-load mode (the default mode), the DOM tree is serialized as markup after developer code is executed, because developer code includes into the DOM tree the content markup of the initial state required, this markup is also sent to the client as markup therefore web crawlers “see” this markup.

In summary, the same code which changes the DOM tree in any time is the same code which builds the initial page.

The tutorial shows these ideas with a concrete example including source code.

The problem of bookmarking (dual links), Back/Forward buttons detection and simulation (URL change detection with timers) and visit counters (with iframes) are also covered problems.

Full Tutorial
Source code and binaries
Running online

Published at DZone with permission of its author, Jose Maria Arranz.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Jonathan Fullam replied on Fri, 2010/04/02 - 7:24am

I took a look at the ItsNat framework and it does seem interesting. I do applaud the effort at innovation. However, the "manifesto" seems to be a result of describing the framework and not a true, honest attempt to create a new concept (or trying to coin a concept that already exists in various forms). Maybe the manifesto should just be a features page for ItsNat. Otherwise, the "manifesto" is biased towards ItsNat.

For example, it seems that the framework has many similarities to something like GWT which if a very powerful "single page" Java based web framework. However, GWT does not easily handle SEO out of the box and ItsNat may. So this is included in the manifesto.

Both frameworks handle bookmarking in a similar fashion (using the # in the URL). However, GWT provides the ability to control the back and forward buttons very easily. ItsNat apparently does not, and therefore the manifesto explicitly disclaims the use of the back and forward button rather than embracing a feature that every browser has. Furthermore, the manifesto claims that since many dynamic sites can't use the buttons, people should just be used to this drawback.

In conclusion, I like the framework but strongly dislike the use of the "Simple Page Interface Manifesto" phrase. It's misleading and clearly biased toward the framework for which it resulted from.

Jose Maria Arranz replied on Fri, 2010/04/02 - 4:50pm in response to: Jonathan Fullam

Jonathan you are right, The SPI Manifesto is biased for ItsNat because I don’t know another similar tool offering SEO compatible SPI, the Manifesto is focused to promote *SPI web sites*, for SPI web applications there is no need of a Manifesto, most of modern frameworks, client and centric, are focused on SPI way of web development. You must recognize SPI web sites are something almost… new/inedit and in this area ItsNat seems the only kid on the block.

In the Manifesto I try to be honest, ItsNat references are in the end, some techniques described are not only for ItsNat and you can read some phrases like this:

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. Some requirements of these SPI web sites to be able of replacing traditional page based web sites, such as page simulation of fundamental states on loading time, are just possible with server centric web frameworks because HTML rendering must be done in server on load time. HTML rendering on load time and the same dynamically loaded and inserted with JavaScript are the key characteristics of a web framework ready to build SPI web sites. Client centric frameworks could have a major role for the realization of so-called secondary states

Regarding to Back/Forward buttons, support and simulation of Back/Forward buttons are not pure SPI and so they were not included in the Manifesto because any manifesto tries to be “pure”. Back/Forward support are included in this tutorial because sometimes “pure” is not synonymous of “good”, sometimes impure things (like Back/Forward support in SPI) make the World better :)

Anyway thanks for your comment

Jakob Jenkov replied on Sun, 2010/04/04 - 4:06pm

Isn't this what Wicket does too?


I know I aimed at building this into Butterfly Web UI, and I was inspired by Wicket, except I wanted to simply things.

Jose Maria Arranz replied on Mon, 2010/04/05 - 1:46am in response to: Jakob Jenkov

Wicket rocks for web sites based on pages following a desktop-like approach of coding, of course Wicket includes some AJAX therefore SPI could be possible but I don't think this AJAX use is SEO compatible (the cornerstone of this tutorial), the same for many (all?) other web frameworks with AJAX support.

Most of the time where you use AJAX you are compeled to forget SEO... with exception of ItsNat :)

In your case, Butterfly Web UI is page based, you don't have problems with SEO, SEO problems arise when you introduce AJAX.


Nicolas Bousquet replied on Wed, 2010/04/07 - 2:20pm

From my understanding, the key point for a web site is REST.

Of course REST is just what we use for years in all web site with a buss word and 2 ou 3 best pratices. But i just want to say, that each page major page of your web site shall be reshable by an URL.

With this, you can ensure search engine can find and crawl your web site, your ensure good usage of back/forward button, you allow your users to bookmark, send the URL by mail etc.

Implementing this features using a real single page with no full page reload for javascript enabled users, and some advenced GUI features (Keyboard shortcut, field validation as you type, content assist, popups..., instant update of the view...) seems to be a good approach for a web 2.0 website or even webapp.

 If i'am right, GWT or Zk can do this now.

Jose Maria Arranz replied on Thu, 2010/04/08 - 3:00pm in response to: Nicolas Bousquet

GWT and ZK and others are good SPI-centric tools but all of them sacrifice SEO.

SPI with SEO is the key of this tutorial.


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.