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

The Single Page Interface Manifesto

03.11.2010
| 22665 views |
  • submit to reddit

I have published The Single Page Interface Manifesto. The objective of this manifesto is to promote the progressive disappearance of the use of pages not only in web applications also in dynamic web sites.  

The Web based on pages as Tim Berners Lee invented have had an extraordinary success, however, the Web has evolved so that the initial idea of linking scientific documents with hyperlinks has been largely overcome by a new dynamic Web, most of web sites are "web applications" forcibly based on pages.  

The page based web programming tends to be a source of problems, despite efforts of frameworks to mitigate this pain, such as the use of Back/Forward buttons, unwanted caching, unwanted form auto-fill etc. Page based programming is strange, repetitive (plagued of includes to achieve some reusing) and inefficient (both in bandwidth and computing power rebuilding complete pages) compared with programming in a single main window like in desktop.

The approach of Single Page Interface (SPI) tries to surpass the page concept as the center element of web programming with the concept of state (fundamental or secondary) and with a programming model event based similar to desktop.

The manifesto shows how the Single Page Interface approach is technically possible even in public web sites. The SPI does not imply to give up Search Engine Optimized (SEO) web sites, bookmarking or page-based services such as ads or counters of visits, in these cases the manifesto shows how you can convert "fundamental states" of a SPI web site on simulated pages.  

The manifesto briefly reviews the evolution of web programming techniques and justifies this "new" way of programming could be named "Model 4".

Although the technical point of view and the sample web site are based on ItsNat (a Java based web framework), I think other frameworks could be able to help developers to produce SPI web sites without losing the advantages of traditional programming based on pages (SEO, bookmarks...).

Finally because is good "to eat your own dog food", the corporative web site of my company, Innowhere.com, has been ported to Single Page Interface, the sample web site of the manifesto. It is basically the same as the old version based on pages (same aesthetic and similar functionality), showing a real working example of the revolution of Single Page Interface.

 

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

Comments

Alessandro Santini replied on Thu, 2010/03/11 - 3:24am

Jose,

thanks for this thought provoking post. I am indeed a fan of AJAX applications (although with some caveats) but I have some points to ask:

  • Do all websites require an SPI? Personally, I do not think so - many web pages can absolutely be designed and developed as a bunch of separate pages, without introducing unnecessary Javascript libraries and tricks.
    I would rather narrow the scope of SPI to applications in their own right - in any case, if I were in you, I would better clarify the scope of applicability of your manifesto.
  • I personally do not buy a Login Form Validation as a proof of "real world scenario". In addition to this, I am one of those retro-looking guys still believing that container authentication is a good thing for a number of reasons (seamless integration with external CAS on top of these).
    Would you rather explain to us how a master/detail page can benefit from this? Or some more real-world, complex scenario?
  • An interesting addition to your manifesto would be the integration of SPI with REST and how they still preserve SEO-compatibility.
  • Unwanted caching is still a problem, even with AJAX. That is why toolkits like DOJO have specific features to force a browser cache invalidation when invoking a back-end service (by injecting a randomly-valued parameter, for instance).
  • Back button is still a problem - a huge problem. Many people still believe that they can revert what they have just done simply by pushing the back button. The difference is that, instead of having a possibly cached page, you possibly get the previous website you visited or - like in the case of ItsNat - you keep on staying in the page you are.

Just my .02$

 

Alessandro

jordi Hernandez replied on Thu, 2010/03/11 - 4:39am

Good luck getting any relevant content from your corporate site indexed by google.

Jose Maria Arranz replied on Thu, 2010/03/11 - 4:42am in response to: Alessandro Santini

Thanks for comments

@Alessandro: Do all websites require an SPI?

No, just 95% of public "web sites" :) 

All of these web sites are made with some kind of dynamic framework in server and/or client.

@Alessandro: I personally do not buy a Login Form Validation as a proof of "real world scenario"

Dou you mean the "login" example cited in the manifesto? It is just an example of how we can understand "fundamental" and "secondary" states, the second example, a page based example converted to SPI is better (for instance innowhere.com).

Innowhere.com is the typical boring site previously based on pages now converted to SPI. The old version (page based with JSP) was plagued of stupid includes to get some reusing. The page based approach is crazy because if you have 100 pages sharing the same header and footer, you must repeat 100 includes of your header and footer (JSP fragments), and because header and footer may slightly change with any page (for instance what menu option is selected) every page must in some way submit some data to header and footer code to change accordingly.

In SPI (I just can talk about ItsNat), is the opposite, your 100 pages are now 100 page fragments with no relationship with header and footer, only containing the markup fragment. In fact there is no header and footer because the main page in defined ONCE and this main page is the place holder of page fragments with some Java code associated to main page to insert/remove page fragments. When the current "state" changes some new page fragment is loaded replacing the current page fragment, the state manager is resposible of this change.

This approach is not new, Dojo, Ext, GWT, IceFaces (and some other "Faces"), ZK and of course ItsNat, all of them AJAX intensive frameworks, are doing SPI programming for years for typical "web applications". The problem is "web sites", with requirements of SEO, bookmarks etc, fortunately these barriers are being demolished, ItsNat was designed from day one for this kind of disruptive change but other frameworks  can follow also this path.

@Alessandro: An interesting addition to your manifesto would be the integration of SPI with REST and how they still preserve SEO-compatibility.

I'm not sure how client centric technologies can be SPI+SEO friendly (without web duplication), this task is by far easier on server centric frameworks. Client frameworks fit well for "secondary state" management, in fact this is the current role in "web sites".

@Alessandro: Unwanted caching is still a problem, even with AJAX

 Nah, because AJAX request are hidden for the end user this is not a problem, and no problem if you use "post" instead of "get" in AJAX. This is not the case in page navigation because this random number would be in URL and saved as bookmark and then cached...

@Alessandro: Back button is still a problem - a huge problem

I agree, we need a cultural change, as said in manifesto many users are aware that using Back/Forward in some web sites (mainly ecommerce) may run into problems.

We could mitigate this problem with some control of Back button provided by browsers. Another way is using "beforeunload" event to inform end user you are going to leave the web site (and optionally cancel this action), this non-standard event introduced by MSIE is working included in most of browsers.

In Innowhere.com because I'm changing the URL reference part when user changes the current state in practice I'm "disabling" the Back button.

@Alessandro: Just my .02$

I'm going to have a coffee, right now, I need 1 EUR more :)

 

Jose Maria Arranz replied on Thu, 2010/03/11 - 4:52am in response to: jordi Hernandez

I don't understand, innowhere.com is fully processed by Google

Try to disable JavaScript in your browser, this how Google's crawler sees innowhere.com

 

Peter Huber replied on Thu, 2010/03/11 - 6:10am

I'm not quite sure, but probably you confuse "interface" with "GUI" or even more correct "human interaction GUI". And I guess you confuse specific problems with common problems. The web on the other hand is more not just web-apps that are meant to be used by human beings, and for instance why is there caching when caching is a problem? I guess caching solves some problems...may be you should talk to someone runing a content-delivery-network about bandwidth and stuff.

Wiki for instance is - a web app - but more like a "NoSQL"-Database (*being excited because I was able to drop the new hype word*) which could someday sport semantic links which could be evaluated by "semantic wiki query language" clients. In this case it's machines reading the web. I cannot see any advantage in a "single page interface" for that purpose. I guess even for "rest" (*yes, yes another hypeword*) it's not obvious why I would want a single page approach here...

 

Alessandro Santini replied on Thu, 2010/03/11 - 6:45am in response to: Jose Maria Arranz

Hey Jose,

"@Alessandro: Do all websites require an SPI?

No, just 95% of public "web sites" :) "

No, I definitely do not agree with this. That is a good sales pitch, but not the reality. Many websites can still be implemented with some simple PHP/JSP + HTML and a sprinkle of Javascript to embellish the whole thing.

"Innowhere.com is the typical boring site previously based on pages now converted to SPI. The old version (page based with JSP) was plagued of stupid includes to get some reusing. The page based approach is crazy because if you have 100 pages sharing the same header and footer, you must repeat 100 includes of your header and footer (JSP fragments), ..."

I guess I failed to get your point here. I clearly remember of nice frameworks like Tiles + Struts that were already offering page compositions many years ago. A more recent example is Facelets, which provides a nice templating engine. AJAX did not introduce anything new here.

 "Nah, because AJAX request are hidden for the end user this is not a problem, and no problem if you use "post" instead of "get" in AJAX"

I think we mean two different things here. The browser also caches XMLHttpRequests and in some cases this should be prevented. Perhaps you are referring about the page contents.

"I'm going to have a coffee, right now, I need 1 EUR more :)"

Consider it offered by myself. Perhaps we shall meet one day, I'll buy you one :)

 

Jose Maria Arranz replied on Thu, 2010/03/11 - 8:37am in response to: Peter Huber

@P. Huber:The web on the other hand is more not just web-apps that are meant to be used by human beings

 Yes course, this is because I care for search engine crawlers, visit counters and page simulation in general.

 @P. Huber: and for instance why is there caching when caching is a problem? I guess caching solves some problems...may be you should talk to someone runing a content-delivery-network about bandwidth and stuff.

 Caching forces reloads in web sites running "content-delivery" web sites most of them based on some kind of databases.

@P. Huber: In this case it's machines reading the web. I cannot see any advantage in a "single page interface" for that purpose

 I don't, I just cover web sites focused for humans, that is, vast majority.

 

Jose Maria Arranz replied on Thu, 2010/03/11 - 8:57am

@Alessandro:Many websites can still be implemented with some simple PHP/JSP + HTML and a sprinkle of Javascript to embellish the whole thing.

 Yeah right, but you must recognize there are millions and millions of web sites driven by server data usually saved in databases, in this kind of web applications some kind of page coordination is absolutely necessary and this kind of page management is a pain. Fully rebuilding a web page with hundreds of items because some item has been added/removed/changed has worked out for many years but anybody must recognize is... crazy.

 In web sites most of the time you see pages and pages sharing tons of markup, rebuilding and resending this markup again and again when page navigation happens is crazy too.

@Alessandro: I clearly remember of nice frameworks like Tiles + Struts that were already offering page compositions many years ago

 Yeah, right, humans are fantastic inventing tools and solutions for any kind of problems, this has run fine when the web was inevitably based on pages. With AJAX, being mainstream and decent browsers we can get rid of page based development right now, in fact, many web frameworks are already doing SPI in "pure web applications".

 

Dave Newton replied on Fri, 2010/03/12 - 11:03am

Sounds like continuation-based sites with a nice-bookmarkable-URL entry point. Nothing new here.

Jose Maria Arranz replied on Fri, 2010/03/12 - 12:30pm in response to: Dave Newton

Can you show a link of this kind of web site? Is SPI?

 

 

Michele Mauro replied on Fri, 2010/03/12 - 1:41pm

I side with Alessandro. You have not substantiated your claim that "95% of the websites" need to work the way you propose. More than that, the example you bring about "Innowhere.com" is all about *your* technical difficulties with that specific server-side implementation; Sir Berners-Lee vision is much much more far-reaching than that. I have problems similar to yours in some old code I wrote when I was young and inexperienced, but the solution is upgrading that code to a more modern technological foundation, and not twist and rewire the web in the way I may like.

Nicolas Bousquet replied on Fri, 2010/03/12 - 2:59pm

I have investigated single page web app for quit while.I even thinked about tabs, windows and all in web apps.

But i discovered, it's not interresting. I kept signle page concept, as it is what i want to do, but you need to allow multiple pages whenever the user want. Make it easy for crawlers ands bookmarking by using rest.

 

Just take a look at a typical website like amazon : when i'am looking for book in amazon, i search for them by author, titles and alike and open them in new tabs to futher investigate them later. If you search for a book title or a best seller author in google, you may see a link to amazon web site because it is indexed.

All of this IS good and it what you want for your typical web site of web app. Yes even web app. Maybe it's a corportate application and all. It's still good that you can bookmark stuff or send the url to your friend or boss by mail for exemple.

So in reality, you have to keep the concepts of page and all that is better for end users, crawler etc.

But you can also support the whole thing with a single page design. So the user has the choice to stay on the same page and benefits from javascripts features (you just refresh what changed and make your website much more attrative). Or he can bookmark current state of what he his doing, send it to another people... And when he use the back function, you can of course go back to previous screen, window state... But without reloading the whole page.

 All of this is about :

- deal with a single page, so use don't miss anything from page to page, you can do better more interractive GUI.

- but still, you deal with bookmarks, back buttons, crawlers and all and allow your user to use multiple browser tab if he want to.

 

 

Jose Maria Arranz replied on Fri, 2010/03/12 - 5:16pm in response to: Nicolas Bousquet

@Nicolas Bousquet: Just take a look at a typical website like amazon : when i'am looking for book in amazon, i search for them by author, titles and alike and open them in new tabs to futher investigate them later. If you search for a book title or a best seller author in google, you may see a link to amazon web site because it is indexed.

 The same for SPI with bookmarking and SEO, what is the problem?

 Google sees my SPI sites based on pages, and users have bookmarks and can open several tabs with several different initial states.

@Nicolas Bousquet:All of this is about :- deal with a single page, so use don't miss anything from page to page, you can do better more interractive GUI.- but still, you deal with bookmarks, back buttons, crawlers and all and allow your user to use multiple browser tab if he want to.

 Yes, this is the kind of SPI web sites I want to promote, in ItsNat is amazingly easy because page simulation is automatic, some technical background about this (by the way that web application is SPI based with bookmarking and SEO for years). Other frameworks (mainly server centric) could offer similar features.

 

 

Gernot Kogler replied on Sat, 2010/03/13 - 2:41am

I come from along way developing complex business applications on the java and .net platforms. We used to implement the client as a rich client (swing / winforms). This is exactly the model you describe in your manifesto. And we had a lot of problems managing complexity, namely the state of the client. When I discovered Rails it gave me a completely new view to application architecture. Now we build our applications the RESTful Rails way. Its incredible how much easier it gets when you look at your application as a bunch of loosely coupled recources that are linked together by a navigation concept. No client state reduces complexity dramatically without loosing anything. And the users love it, too. We do not optimize early. If we see performance bottlenecks, we apply caching later on. And - thanks to Rails - we have full control over the browser caching. We have absolutely no problems with the forward / back buttons of the browser. And URIs are a feature, not something you should fight. IMHO, REST is far superior to a single page concept for complex web apps. But you have to embrace it and do it the right way.

Jose Maria Arranz replied on Sat, 2010/03/13 - 4:44am in response to: Gernot Kogler

@Gernot Kogler: I come from along way developing complex business applications on the java and .net platforms. We used to implement the client as a rich client (swing / winforms).

 Is your experience but in my opinion innovation is taken place in SPI, review all modern frameworks (client and server centric) including JSF variants what are they doing these days, take a look on demos, most of them (all?) are SPI.

In fact, REST alongside AJAX can help SPI for JavaScript intensive applications, and JavaScript intensive applications tend to be...SPI.

@Gernot Kogler:REST is far superior to a single page concept for complex web apps. 

You seem almost the only guy I've met with Swing background (desktop experience in general) saying this, most of, previously desktop developers, rant against of web development, fortunately they are happier these days with more and more SPI centric tools.

 

Nicolas Bousquet replied on Sat, 2010/03/13 - 10:57am in response to: Jose Maria Arranz

From my experience,Desktop app are far better for the ergonomics, responsiveness, performance. They can be much more interractive and deal with complex data than web site / web app.

On a side note, a desktop app is easier and faster to make. A typical web app will provide sub par user experience and cost 2 to 3 type more money for the same result.

 I made SWING app (control center for a spacial system) and web app for IT. It was faster to build a complex control center GUY than a basic CRUD web app.

Today, making a web app is what everyone do without even thinking about the interrest it really has. Okay, it's easier to deploy, but you have many incompatibilies too (IE 6 anyone ?) and only the most powerfull computer can run web 2.0 webapp with acceptable performance.

Just think at the ergonimic of an IPad, Iphone, or simply your computer and the OS. All is responsible, immediately available. 

 Major application like MS office suite and all, despite a web browser version exist are better offline on your computer.

And imagine Eclipse or IDEA in a web browser ?

In my experience, web app are beautifull, nice to see, sell well, but productivity of typical user is inferior to the 20 year old black and green text 5250 terminal like GUI. Web page are so long to load, there is so many bloat, step and all... Just because HTML/CSS has not been made for this in the first place.

Using a single page, and support rest and all can give you a boost in the sence that after it's has loaded, you application is not as responsive as a desktop app, nor has the processing power, but at least, it can do what a desktop app could do on a 386 SX 25Mhz with Windows 3.1... And it's already a huge gain compared to classic multiple page design.

Gernot Kogler replied on Sun, 2010/03/14 - 2:41am in response to: Nicolas Bousquet

@Jose Maria Arranz: You seem almost the only guy I've met with Swing background (desktop experience in general) saying this, most of, previously desktop developers, rant against of web development, fortunately they are happier these days with more and more SPI centric tools.

Maybe because they try to build a desktop app in the browser? As I said, you have to embrace the web technology and the browser; use the power of these tools, don't fight them. Use AJAX carefully to smooth the user experience, but don't overuse it. Otherwise you're running into problems with the back buttons and other stuff.

@Nicolas Bousquet From my experience,Desktop app are far better for the ergonomics, responsiveness, performance. They can be much more interractive and deal with complex data than web site / web app. On a side note, a desktop app is easier and faster to make. A typical web app will provide sub par user experience and cost 2 to 3 type more money for the same result.

We wrote our flagship product, the leading real estate management app in switzerland, based on .NET / Winforms. It took us 40 man years to complete (we knew that it would take that long). Now we're in the middle of a complete rewrite on Ruby on Rails (after all, we started the original app in 2000 based on .Net beta 1) and we estimate no more that 10 man years for it.

The performance - as far as we can see - is better than the original app and the user interface is more advanced. But I've seen a lot of web apps that truly perfom bad. Often these apps are built with a set of so called web controls that generate horrible and huge html documents. We take care of the generated html (wich is quite easy with rails) and we use the complete toolset like page caching, fragment caching, etags etc.
The response time for a complex resource visualisation is typically about 200ms in production configuration. I would call that responsive.

IMHO, the concept of a paged application matches a typical business app very well. If I look at our real estate management app, in the end it's all about documents: Bills, contracts, requests for payment...
So we expose these "documents" as resources. The user can create them, save them, search them (supported by a full text serach engine) and view them in different representations (html, pdf, xml...). And if you think about it, all the other data (immovables, renters...) can be presented as documents as well. Of course, these documents are structured data, not simple text. When a user creates or changes a document, he does it through a web form with validations and all that stuff. The web forms just look pretty much like the final document.

After all, our users like the new app and find it very intuitive and responsive. And thanks to REST/Rails we get very powerful features for free

  • Our app has a complete API (so another app could create an invoice or get a immovable data sheet as a pdf)
  • Each resource has an URI and is therefore adressable; you can save the URI as a bookmark, work with different resources side by side in as much tabs as you like. And you can email a link to a resource to someone else. And if that user is permitted to watch of manage that resource, he's immediatley "there" with a click on that link.
  • We have pretty URSs so the URL is actually a simple command line if the user wants to use it like that.

    Jose Maria Arranz replied on Sun, 2010/03/14 - 5:57am in response to: Gernot Kogler

    Gernot Kogler: As I said, you have to embrace the web technology and the browser; use the power of these tools, don't fight them.

     I'm not new in web, my first web project was developed in 1997 using ObjectStore and the (primitive) web templating system of ObjectStore, yeah logic in C++ without sessions, when I read about how nice is  "stateless" I cannot avoid how much pain is working without some kind of state in server. 

     Today there is nothing radically different in page based development since those days. SPI in my opinion is the most disruptive paradigm change of web, now this is the time and SPI is ALSO WEB TECHNOLOGY and it can be embraced too.

    The technological background of SPI has its roots in DOM when Netscape Navigator 4 and MSIE v4 were released and SPI is here even before AJAX since an old Netscape's Dev Edge article talked about how to load on demand new JavaScript code using a hidden <iframe>, I've found this article (2003) I think a previous article existed and Pushlets (maybe the legitimate inventor of Comet) is offering this kind of techniques before 2000.

    As you can see SPI is not new, search engines (SEO) and bookmarking are the reasons in my opinion of why SPI has not taken off in web sites (SPI is already being used on many many web applications), this is changing with new techniques for web site development.

     

    Nicolas Bousquet replied on Sun, 2010/03/14 - 11:59am

    @Gernot Kogler


    It's funny to say that it's cost less and perform better on a browser with HTML/CSS. But from what you are saying i would have clues why :
    - your new app version embrace simplicity :
    - a page per document
    - simple GUI no much JS/AJAX


    So your application is easier to use for your customers and far faster to build for you as developers.
    And that was in my opinion a wise idea. Simplicity is always better.
    Maybe I am totally wrong but i would say that your old desktop app was simply more complex, thus the difference in the budget and performance. Maybe then it seem that it's still the same people that have done the two app. Of course, a full rewrite is always faster because you already now the business, you have been able to understand what was not so useful and all.

    Hey i'd say that for the home presentation part and all, an open source GED or CMS would be enough : searching of documents, tag metadata...
    Maybe also modern framework for searching document and all save you a huge time…
    By the way, is there any advanced or complex UI in your application ?
    Is it easy for example to visualize multiple document  at the same time ? Does the user can use keyboard shortcut to find instantly what he want or switch between views ? Is it possible to pick up a bunch of documents and compare them (home price, size…) ?


    A desktop app ready help if you need some fast responsive interaction. If your user agree to just use the mouse and click from page to page, it's perfectly fine. Where i work, the web app version is so intuitive, but slower to use (not in performance) than the terminal version.
    With the web app, if your are a new user, you gain time. But with the old terminal app, if you know what you want to do and how to do it, you save time. Because when filling up a 200 items order, each step is more "interactive", "responsive" and get done faster. And what our clients want, is less people for the job, not more. Our application is used by people staying in front of the computer the whole day, with one purpose : get the job done and as fast as possible.

    On the other side, the web app has more eyes candy, so the client buy it in the first place, we can't sell terminal app anymore ...

     

    Beside that, do you like gmail ? or google doc ? (Exemple of SPI application...)

    Gernot Kogler replied on Mon, 2010/03/15 - 5:02am in response to: Nicolas Bousquet

    @Nicolas Bousquet
    Maybe I am totally wrong but i would say that your old desktop app was simply more complex, thus the difference in the budget and performance.

    Absolutely correct. But the new app is even easier to use than the old one. There are not more steps for the user to complete a specific task. They can work without the mouse if they want to.

    So why is the old app more complex? From my point of view, it's the state. We had state in the UI Controls (Textboxes, Grids...). We had state in the client side data model. We had state in the server side domain model. And we had state in the database. We used best practices (mediator pattern, observers, you name the pattern...) but it still ended up in quite a complex overall design.
    Now we are completely stateless. This makes everything so much easier. And concerning usability and ease of use, we didn't loose anything.

    By the way, is there any advanced or complex UI in your application ?

    What's the definition of a complex UI? My goal was to give the user a UI where he can complete his tasks with a minimum of interaction. Based of the context we present data and action elements that are relevant for the user. So a HMTL page can contain quite some of data and controls (resource links).

    We have some rather complex forms, too, e.g. multiple nested composites. All this logic is handled by JS, of course. So yes, I think we have a complex UI. But we have very simple controllers because rails handles the boring, repeating tasks like instantiating the domain model, apply changes to the model, decorating controls with error information etc. for us.

    Is it easy for example to visualize multiple document at the same time ?

    Yes. All our controllers support the standard REST actions. One of these actions is index, so any resource can present itself as a collection of elements. So the user could, for example, view two contracts side by side.

    Does the user can use keyboard shortcut to find instantly what he want or switch between views ?

    Yes. We have complete keyboard support in our UI.

    Is it possible to pick up a bunch of documents and compare them (home price, size…) ?

    There's no use case for this in our app, but we could implement that easily. This would probably implemented as a new resource.

    Jose Maria Arranz replied on Wed, 2010/03/17 - 4:34am in response to: Jose Maria Arranz

    Another (better) link to the Netscape's Dev Edge article using <iframe> for on demand JavaScript, published on 16 May 2003.

    Quote:

    Recently, however, modern browsers and enriched web standards have begun to make new navigational and presentational models possible. One such model is Inner-Browsing, which is our name for a model in which all navigation occurs within a single page, as in a typical application interface. The single-page context and abstraction of data from the presentation can give your web applications new continuity, precision and control. This model is also interesting because is optimized to access contextual data instead reloading full web pages. 

     

    Carla Brian replied on Mon, 2012/04/16 - 10:04am

    Every web developer knows how problematic is page navigation in a web application, besides of bandwidth wasting and process time rebuilding entire pages. - BrandStar Entertainment

    Jose Maria Arranz replied on Thu, 2013/03/21 - 3:12am

    Comment viewing options

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