views:

276

answers:

8

Have you experimented with single page web application, i.e. where the browser only 'GETs' one page form the server, the rest being handled by client side javascript code (one good example of such an 'application page' is Gmail)?

What are some pro's and con's of going with this approach for simpler applications (such as blogs and CMSs)?

How do you go about designing such an application?


Edit: As mentioned in the response a difficuly is to handle the back button, the refresh button, bookmarking/copying url. The latter can be solved using location.hash, any clue about the remaining two issues?

+2  A: 

One pro is that you get the full presentation power of JavaScript as opposed to non-JavaScript web sites where the browser may flicker between pages and similar minor nuisances. You may notice lower bandwidth use as well as a result of only handling with the immediately important parts that need to be refreshed instead of getting a full web page back from the server.

The major con behind this is the accessibility concern. Users without JavaScript (or those who choose to disable it) can't use your web site unless you do some serious server-side coding to determine what to respond with depending on whether the request was made using AJAX or not. Depending on what (server-side) web framework you use, this can be either easy or extremely tedious.

It is not considered a good idea in general to have a web site which relies completely on the user having JavaScript.

Deniz Dogan
Is having Javascript disabled a major concern? Wouldn't an overwhelmingly majority of users have it enabled? Most popular websites these days require javascript (Gmail but also Facebook, Youtube). I would believe the less capable browser used these days would be IE 6.
jd
Google Mail does not require JavaScript AFAIK. If you try to access GMail with a browser such as Lynx, or with the NoScript plugin for Firefox, it will gracefully degrade to an HTML only experience.
Chris Shouts
A: 

Hi, I was creating exactly these kind of pages as webapps for the iPhone. My method was to really put everything in one huge index.html file and to hide or show certain content. This showing and hiding i.e. the navigation of the page, I control in a special javascript file where the necessary functions for handling the display of the parts in the page are.

Pro: Everything is loaded in the beginning and you don't need to request anything from the server anymore, e.g. "switching" content and performing actions is very fast.

Con: First, everything has to load... that can take its time, if you have a lot of content that has to be shown immediately.

Another issue is that in case when the connection goes down, the user will not really notice until he actually needs the server side. You can notice that in Gmail as well. (It sometimes can be a positive thing though).

Hope it helps! greets

Dimitri Wetzel
Why would you hardcode everything on the first page?!? Couldn't you lazy load your content via Ajax? This would decrease your initial loading time and you could load small chunks of content when it is actually needed.
moxn
In my case it was kind of good to have it all loaded at the beginning, but yeah, you are completely right, loading with ajax is the natural thing to do here.
Dimitri Wetzel
A: 

Usually, you will take a framework like GWT, Echo2 or similar.

The advantage of this approach is that the application feels much more like a desktop app. When the server is fast enough, users won't notice the many little data packets that go back and forth. Also, loading a page from scratch is an expensive operation. If you just modify parts of it, the browser can keep a lot of the existing model in memory and just change the parts that changed.

Another advantage of these frameworks is that you can develop your application in pure Java. This means you can debug it in your IDE just like any other Java app, you can write unit tests and run them automatically, etc.

Aaron Digulla
+3  A: 

One major con, and a major complaint of websites that have taken AJAX perhaps a bit too far, is that you lose the ability to bookmark pages that are "deep" into the content of the site. When a user bookmarks the page they will always get the "front" page of the site, regardless of what content they were looking at when they made the bookmark.

Matt
This has been addressed recently by using the `hash` part of a URL to allow bookmarking pages in JavaScript apps. Gmail is a great example of this. Every email can be bookmarked even though it was generated using JavaScript. ASP.NET (and other framworks, I'm sure) has already built this feature into its framework for AJAX apps.
Dan Herbert
The hash part of the URL? Is that the same thing as the query string? Wouldn't changing the URL of the parent page force a reload of that page? I'm very curious - have a link to an example?
Matt
Those using jQuery can harness the power of the history plugin to achieve this: http://www.mikage.to/jquery/jquery_history.html
J-P
@Matt, the hash can be changed without a page refresh. If you need an example just look at gMail or Facebook.
J-P
@J-P ahh, hash as in anything after the #. For some reason, that just didn't connect in my brain.
Matt
+3  A: 

I call these single page apps "long lived" apps.

For "simpler applications" as you put it it's terrible. Things that work OOTB for browsers all of a sudden need special care and attention:

  • the back button
  • the refresh button
  • bookmarking/copying url

Note I'm not saying you can't do these things with single-page apps, I'm saying you need to make the effort to build them into the app code. If you simply had different resources at different urls, these work with no additional developer effort.

Now, for complex apps like gmail, google maps, the benefits there are:

  • user-perceived responsiveness of the application can increase
  • the usability of the application may go up (eg scrollbars don't jump to the top on the new page when clicking on what the user thought was a small action)
  • no white screen flicker during the HTTP request->response

One concern with long-lived apps is memory leaks. Traditional sites that requests a new page for each user action have the added benefit that the browser discards the DOM and any unused objects to the degree that memory can be reclaimed. Newer browsers have different mechanisms for this, but lets take IE as an example. IE will require special care to clean up memory periodically during the lifetime of the long-lived app. This is made somewhat easier by libraries these days, but by no means is a triviality.

As with a lot of things, a hybrid approach is great. It allows you to leverage JavaScript for lazy-loading specific content while separating parts of the app by page/url.

Crescent Fresh
+1  A: 

The main reason to avoid it is that taken alone it's extremely search-unfriendly. That's fine for webapps like GMail that don't need to be publically searchable, but for your blogs and CMS-driven sites it would be a disaster.

You could of course create the simple HTML version and then progressive-enhance it, but making it work nicely in both versions at once could be a bunch of work.

bobince
A: 

I'll add that on slower machines, a con is that a large amount of JavaScript will bring the browser to a screeching halt. Since all the rendering is done client-side, if the user doesn't have a higher-end computer, it will ruin the experience. My work computer is a P4 3.0GHZ with 2 GB of ram and JavaScript heavy sites cause it to chug along slower than molasses, which really kills the user experience for me.

Hooray Im Helping
+2  A: 

Maybe you should check SproutCore (Apple Used it for MobileMe) or Cappuccino, these are Javascript frameworks to make exactly that, designing desktop-like interfaces that only fetch responses from the server via JSON or XML.

Using either for a blog won't be a good idea, but a well designed desktop-like blog admin area may be a joy to use.

Soska
exactly what I had in mind, thanks for the frameworks!
jd