Home

News: The Single Page Interface Manifesto

  1. The Single Page Interface Manifesto (23 messages)

    The objective of The Single Page Interface 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. Do you think SPI is the future of Web?

    Threaded Messages (23)

  2. Terrible[ Go to top ]

    Single page java websites are not something "new". AJAX is not something "new", and I could not discover anything innovative in the pages this article links to. It sounds to me as an attempt to get more traffic to an otherwise ugly and non-informative website. Sorry.
  3. Re: Terrible[ Go to top ]

    I checked and double checked. No, its not April Fools day. Did this get posted early by mistake? Surely ... ??
  4. Re: Terrible[ Go to top ]

    I checked and double checked. No, its not April Fools day. Did this get posted early by mistake? Surely ... ??
    Again, have you really read SOMETHING?
  5. Re: Terrible[ Go to top ]

    Having read your "manifesto" I can honestly say I find it a quite trivial treatment of the challenges of web development in 2010 (whether "web sites" or "web applications" - you seem confused on these; it's all HTTP, all the way down, folks). What you deliver can at best be described as best practices, nothing exciting or new - and in some cases not even best practices. For example, you describe bookmarks as being desirable, and then say don't use Back/Forward - holy crap, man, B/F *is* bookmarking in most ways (re-use of a previously saved URL) and is one of the more significant features of browsers as a web client. I applaud the effort to quickly summarize the state of what many of us are working on nowadays. Just don't pass it off as a "manifesto" or, worse, something new you came up with.
  6. Re: Terrible[ Go to top ]

    whether "web sites" or "web applications" - you seem confused on these; it's all HTTP, all the way down, folks
    Then why don't I see "web sites" based on, for instance, GWT? GWT is nice and powerful and GWT based applications are SPI based (GWT strongly promotes SPI) then why not "web sites". One hint: SEO.
    For example, you describe bookmarks as being desirable, and then say don't use Back/Forward - holy crap, man, B/F *is* bookmarking in most ways (re-use of a previously saved URL).
    Back/Forward is just quick navigation and can be fully replaced with menus and, with some effort, with some kind of "Back Button" in your web site/application. Back/Forward is the most important cause of "defensive programming", ask to your bank why they are using frames in 2010 yet in their online account management web app.
    I applaud the effort to quickly summarize the state of what many of us are working on nowadays. Just don't pass it off as a "manifesto" or, worse, something new you came up with.
    Again I'm waiting for a list of SPI web sites with SEO, bookmarks, visit counters, ads, accessibility and page simulation in general. No one? it sounds me like something "new"...
  7. Back/Forward[ Go to top ]

    Having read your "manifesto" I can honestly say I find it a quite trivial treatment of the challenges of web development in 2010 (whether "web sites" or "web applications" - you seem confused on these; it's all HTTP, all the way down, folks). What you deliver can at best be described as best practices, nothing exciting or new - and in some cases not even best practices. For example, you describe bookmarks as being desirable, and then say don't use Back/Forward - holy crap, man, B/F *is* bookmarking in most ways (re-use of a previously saved URL) and is one of the more significant features of browsers as a web client.
    The feature should work with HTML5 window.history.pushState
  8. Re: Terrible[ Go to top ]

    Yes, i read your manifesto. Sorry for the glib post, but in all seriousness i was worried that your article was a joke and i would look silly giving a serious answer.

    But now i know its not a joke I can give a more detailed answer..

    I've worked on plenty of websites that try to use a "single-page-every-link-is-a-POST" pattern. It always ends up the same; poor useability and expensive, time consuming maintenance.

    As the first poster said, this isnt a new idea. Back when the web was new most people used cgi-bin scripts for dynamic functionality, and this very often resulted in single page websites. One of the first e-commerce sites i used had a single url like http://www.ht.com.au/cart.exe,which served every single page. That was in 1997.

    Over the last few years i've been building websites and web applications according to the principles of REST. The result is much simpler development and users love it.

    Single page apps usually come about when programmers get obsessed with the programming. You're end up fighting against the whole of the web: 
    - you fight with the users and what they know and expect
    - you fight with HTTP, which has resource centric semantics
    - browsers which are optimised for conventional practises
    - proxies, which use HTTP closely

    Take my advice: HTTP is good, back buttons are good, caching is good. Embrace them, and then everthing becomes easy... 
  9. Re: Terrible[ Go to top ]

    I've worked on plenty of websites that try to use a "single-page-every-link-is-a-POST" pattern. It always ends up the same; poor useability and expensive, time consuming maintenance.

    I don't fully understand your position you seem confusing SPI with component-driven frameworks *based on pages* like Wicket or JSF not using AJAX ("Model 3" as explained in Manifesto). In SPI there is no "single-page-every-link-is-a-POST" are you really talking about AJAX calls executed when some link is clicked?

    You must recognize these days almost all client client libraries (Dojo, Ext, YUI...) and many server centric frameworks like IceFaces, ZK, RichFaces, Echo are providing more and more SPI technologies. The innovation is taken place in SPI for "web applications".

    The next frontier is SPI for "web sites" providing page simulation when needed (SEO, bookmarks etc). 

    I just can talk about ItsNat, in ItsNat page simulation in SPI is automatic (some technical background about this). 

  10. Re: Terrible[ Go to top ]

    Are you really read the Manifesto? The manifesto talks about "web sites", "web sites", "web sites", "web sites" and clearly distinguishes them from "web applications". How many SPI web sites do you know? That is, SPI web sites with SEO, bookmarking, visit counters... I'm anxious waiting your list of links.
  11. All that is good theory. I sugest to practiwe using qooxdoo : http://www.qooxdoo.org This framework allow you do web application in "one page", in fact, without page at all, containg state, ... The same as we always did before web.
  12. In the Manifesto I talk about client and server centric frameworks like qooxdoo already doing SPI FOR WEB APPLICATIONS and it is fine and I like it. But, I'm talking about WEB SITES, that is www.qooxdoo.org as a SPI web site.
  13. In the Manifesto I talk about client and server centric frameworks like qooxdoo already doing SPI FOR WEB APPLICATIONS and it is fine and I like it.

    But, I'm talking about WEB SITES, that is www.qooxdoo.org as a SPI web site.
    I'd like to understand your point of view : what are the differences between what you called "web application" and "web sites" according to you ?
  14. I'd like to understand your point of view : what are the differences between what you called "web application" and "web sites" according to you ?
    In your case is very easy: * http://www.qooxdoo.org As a whole is a web site * http://demo.qooxdoo.org/current/showcase A web application (in this case a nice SPI app) In practice is not so easy, when you have requirements of SEO, bookmarking, visit counters, ads etc you are building a "web site".
  15. I agree with most of what you put into this manifest. BUT: what is "A cultural shift for end users. Goodbye to Back/Forward buttons"? That's nonsense. I develop SPI application, and the Back-Forward buttons work here even better than in traditional apps. Your manifest describes how to do it, so why do you say it's impossible to accomplish? Back and Forward buttons are native to the web. You can't just throw them out of the window. 
  16. I agree with most of what you put into this manifest. BUT: what is "A cultural shift for end users. Goodbye to Back/Forward buttons"? That's nonsense. I develop SPI application, and the Back-Forward buttons work here even better than in traditional apps. Your manifest describes how to do it, so why do you say it's impossible to accomplish? Back and Forward buttons are native to the web. You can't just throw them out of the window. 

    No, in innowhere.com in some way Back/Forward buttons "are disabled" because when you click Back/Forward only the reference part of the URL changes with no reload.

    The good news is some support is possible with tricks like a JavaScript timer checking when window.location is changed with no reload and reloading with a simple window.location.reload(true). 

    This trick is not used in innowhere.com (and I could) because the objective is to get rid as much as possible of page navigation and this trick provides some page navigation in SPI web sites and because innowhere.com is the "official" web site of the SPI Manifesto :) 

    Anyway I must recognize this page navigation with Back/Forward is "tolerable" in SPI because end users (including me) are compulsively using Back/Forward buttons, is not an ideal and pure SPI world, but it is an acceptable compromise. 
  17. I've heard another trick exists to track Back/Forward clicks based on an <iframe> but I haven't googled/studied it yet. 

    Anyway Back/Forward buttons are not really needed if your web site has a good menu system for "state navigation" including simulated Back buttons, I've seen this "Back" button in some desktop application. 
  18. Too many tricks[ Go to top ]

    Your "manifesto" requires too many tricks: this is a strong smell that you are going against too many standards. You should read some RFCs, clarify your ideas, and then write one so it can properly evaluated.
    If you are suggesting a new standard, the usual path is that one: write an RFC and build consensus around it.
  19. in a single bang[ Go to top ]

    so I've started reading "the manifesto" in neutral disposition, waiting for the critical mass of pros and/or cons to form in my mind
    there were some pros, a bit more cons, but then - bammm! - a single sentence hit me like a hammer

    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.

    opening several windows in the same session is not the bad practice, it's essential to the web, along with bookmarking
    it's one of the reasons I prefer web UI to custom-crafted GUI, where I'm completely dependent on the developer to provide me with the means to not only look at the underlying information in different views (or at the different parts of it) simultaneously, but also simultaneously interact with it, while the results are reflected in the shared working session
    use of broken toolkits (I look at you, JSF 1.0) and unclear mental models of some software designers are not an excuse to throw out the babies with the water
    so - no, I'm strongly oppposed to this, if only on this one point 
  20. Re: in a single bang[ Go to top ]

    opening several windows in the same session is not the bad practice, it's essential to the web, along with bookmarking

    Yes you are right, but most of session based applications are not ready for this kind of practice because sessions are used for page coordination. I just wanted to remark this is not a problem in SPI, two different SPI pages share nothing because you can ever recognize the page sending events with some kind of "page id" identifier (in ItsNat this kind of page identification is built-in). 
  21. ehhh...[ Go to top ]

    "Yes you are right, but most of session based applications are not ready for this kind of  practice because sessions are used for page coordination."

    let me check if I understand you correctly: there are some broken implementations that use sessions for page coordination => we should not fix them, but instead use the broken model everywhere

    that is definitely not my idea of modern web application design then

    in my really humble opinion, if you find it too difficult to keep page flow and user sessions orthogonal, then it's much better to eliminate sessions altogether and go RESTful
     

  22. ehhh...[ Go to top ]

    "let me check if I understand you correctly: there are some broken implementations that use sessions for page coordination => we should not fix them, but instead use the broken model everywhere
     
    ...then it's much better to eliminate sessions altogether and go RESTful 

     Fixing sessions in page based web sites is not my job.
     
     Are you saying SPI is a "broken model"? Really?
     
     Finally RESTful alongside with AJAX is a path for SPI the problem is it has serious problems with SEO, bookmarking...

  23. Appropriate company name[ Go to top ]

    Innowhere. As in where is the innovation?

    Not sure what this poorly worded treatise offers anyone who has worked in the web space over the past few years except a pretty blatant attempt to drum up sales.

    I sure hope these kinds of articles aren't a part of the new face of TSS.
  24. Appropriate company name[ Go to top ]

    Innowhere. As in where is the innovation?

    Not sure what this poorly worded treatise offers anyone who has worked in the web space over the past few years except a pretty blatant attempt to drum up sales.

    I sure hope these kinds of articles aren't a part of the new face of TSS.

    As said before several times, show me SPI web sites with SEO, bookmarking and page simulation in general. I'm waiting and waiting and waiting.

    Show me a technology able to do, for instance, this kind of things.

    I'm sorry but your comment is absolutely poor too, I would expect more interesting arguments.

    The SPI Manifesto is also in Spanish and discussed here of course in Spanish,  put your comments there, try to avoid poorly worded comments because some guys usually are too critic when they read poorly written comments (be sure I'm not going to critize your style of writing if Spanish is not your native language on the contrary you are welcomed).