Comments on: Ajaxified Body; When to refresh the page

By: riteshchopra

riteshchopra — Tue, 21 Oct 2008 12:14:45 +0000

While coding an AJAX based application developers tends to neglect that fact that there may be times when web server can be offline or down. Here is a nice article which deals with it http://www.hurricanesoftwares.com/ajax-should-not-mandate-http/ We should not mandate AJAX.

By: FrankThuerigen

FrankThuerigen — Wed, 08 Oct 2008 16:53:22 +0000

@dataplumber: that is also an interesting approach… i´d like to see that can you provide a link?
Whether one or the other approaches will be the future only the future can tell I think.
Other than that – if you parse a JSON data structure to create DOM elements from it, it is almost the same as creating these in code as other GUI libs do, which comes at an added speed penalty.
It is interesting that the whole theme complex ( innerHTML vs. createElement ) still sparks that much discussion. I think there are good reasons for both approaches – depending on the project requirements.
Roll on, gentlemen!

By: DataPlumber

DataPlumber — Wed, 08 Oct 2008 13:03:13 +0000

Doesn’t take the concept NEARLY far enough IMNSHO.

It still loads HTML which can only be processed by setting some existing element’s innerHTML property. This limits scripting ability, and means the new HTML won’t be part of any existing Javascript-managed structures.

What is REALLY the future is loading the next “Page”‘s JSON description. A fully configured literal which completely describes the page and all the widgets. This is instantiated and added into the javascript layout.

Of course this is dependent on the javascript library you use. I use a one-page app which loads components as JSON configs. No HTML is used at all. The hit of loading a large javascript library and the UI building code is taken only once. From then on only metadata (component configuration) and data are transferred between browser and server.

In fact its better than that. You can click “navigation links”, and the component will ba ajax-loaded into the page’s “content area” as a pure config.

But if you RIGHT CLICK and open in new tab or open in new window, a whole new page is generated with the requested component embedded. Best of both worlds.

By: genericallyloud

genericallyloud — Tue, 07 Oct 2008 12:27:43 +0000

If all this does is load html fragments over xhr, I have my doubts that its worth it. To each their own, though, I suppose. The major jump in benefits comes when you have a lot of javascript (even something cached needs to be re-parsed and executed) or want to maintain client state in the browser. While not something that is really necessary for web pages, complex web apps can require a lot of client state. It takes a little work to reach the point where the server side maintains no state at all, but when you get there its a huge shift. The server becomes a place that can be focused purely on data and business logic. Using REST services, the data can be directly retrieved and used in the browser. It is incredibly scaleable and fast too.

Web pages may use some of this technology eventually when all browsers work in ajax history and bookmarking, but I predict that within the next couple of years single page applications will become very commonplace.

By: Frank Thuerigen

Frank Thuerigen — Tue, 07 Oct 2008 11:55:47 +0000

@ragjunk this can be handled by storing the pages current stage in a session, but won´t help for bookmarks obviously.

By: ragjunk

ragjunk — Mon, 06 Oct 2008 23:04:39 +0000

Yes, it is a chicken-and-egg problem. It is not so much on the back button support to navigate the pages in the “current application”, but what happens if the user accidentally goes to a page from different domain in the history and then comes back. Consider the following example:
1. User goes to http://demo.raibledesigns.com/ajaxifiedbody/ and selects, “Users” tab.
2. Clicks on the Back button. This will show the previous page wherever the user was.
3. Clicks on the Forward button. The default page (Home) is displayed, instead of “Users.” In other words, the context is lost.

If the site requires authentication, I would assume that information is lost too, forcing the user to relogin, which results in unpleasant user experience. So, again, it is not so much about supporting old habits, but making sure that the Ajax application maintains proper context, so the user experience is not compromised.

By: FrankThuerigen

FrankThuerigen — Mon, 06 Oct 2008 22:27:58 +0000

works on safari for win here at least…

By: michalfrackowiak

michalfrackowiak — Mon, 06 Oct 2008 21:42:44 +0000

Looks like it is broken on Safari…
It also looks like the UI sucks a bit. Please at least change cursor to “wait” when content of the box is being refreshed. It would help a lot.

By: FrankThuerigen

FrankThuerigen — Mon, 06 Oct 2008 21:27:38 +0000

@Morgan: how do you mean that? I didn´t get the point…

By: MorganRoderick

MorganRoderick — Mon, 06 Oct 2008 20:52:50 +0000

Not much room for errors … progressive enhancement anyone?

By: FrankThuerigen

FrankThuerigen — Mon, 06 Oct 2008 20:17:36 +0000

I have been working on especially this type of application coding for some time, so I think I should say something about it in general:

IMHO one should always check assumptions… e.g. if someone says “we must support the back button because the user is used to it” – the first questions should be “why is the user used to it?” and “what can we do to make the user forget the back button?” …

It may not apply to all cases – but thinking about it always helps.

By: FrankThuerigen

FrankThuerigen — Mon, 06 Oct 2008 19:59:57 +0000

@icoloma:
not true, depends on technology… see http://www.two-birds.de use firebug to examine net traffic…

By: icoloma

icoloma — Mon, 06 Oct 2008 19:11:11 +0000

With this technique the browser will not process scripts/css files, which results in faster page visualization.
That being said, maintenance cost grows big time.

By: Frank Thuerigen

Frank Thuerigen — Mon, 06 Oct 2008 18:51:20 +0000

@JaxPhper:
whether it is worth or not heavily depends on the need for agile response. Websites with an old-style loading sequence will not replace proprietary intranet DB interfaces, while fullAJAX webapps definitely have that potential – simply because they are that “little tick” faster. Knowing that, AJAX applications will cut software cost to a fraction of what it was before. Furthermore AJAX allows for a much more structured approach when implementing a complex application ( see SOA ). I didn´t even mention that this way you will automatically become client side system independent in regard of DB handling. All these are good reasons to spend an extra buck … btw coded in the right way an AJAX app is not that much more expensive than a standard webapp.
@ragjunk:
I agree on -history and -bookmark problems. But I have objections to all of these arguments:

(1) the history, from the beginning in the first browsers, is a page oriented functionality. I agree in that users are used to it. But a back button may not make sense in a full ajax app that simultaneously shows more than one form(s) and articles(s) – all of these dynamically generated during user workflow. What would a back button be good for here, granted you have more than one workflow open? A back button can only apply to ONE OF THEM – which one would it be? The simple solution to it is providing “back buttons” directly in the “viewport” that displays a single workflow/process.

(2) bookmarks: same rule applies, since there is probably not a distinct single bookmark possible to describe the page state. Solution is pointing to a print / bookmarkable version of the content, again at the viewport the information is displayed in, and onClick open a popup – uuuuups I said the bad word – window. The user will get used to it.

Overall it is a chicken-egg problem. People tend to believe “we must support the back button”. Not true. New technologies call for new solutions. The goal is to make the user forget about the browser back button by presenting him an application back button where needed.

By: MattQuinlan

MattQuinlan — Mon, 06 Oct 2008 18:38:54 +0000

This is a valuable pattern in web design, but it’s most appropriate when the content outside of the red square has transient state that is related to the content inside the square. For example, if there were a JavaScript hierarchy (tree) outside the square that the users traverses (maybe many levels deep) and when the user selects an element in the tree the red square is loaded with associated content… this would be an excellent use of this technique. The worst use of this technique is to use it for framing (headers, footers, sidebars) which essentially makes it HTML frames!

The short of it is… good in web apps… bad in websites. :)

Cheers!
-Quin’

By: mraible

mraible — Mon, 06 Oct 2008 18:07:32 +0000

Is it worth spending hours of coding to get rid of a refresh flash? Maybe not, but if the majority of a page's content is in the header/footer/menu, then it might make sense. Especially if you're trying to satisfy Rule #1 of best practices for making web pages fast. Yes, browser caching should help, but it often doesn't solve the inline script blocking issue.

By: ragjunk

ragjunk — Mon, 06 Oct 2008 17:14:28 +0000

Handling the browser’s back button has been the biggest challenge when the entire page is not refreshed. The bookmarking is other. Even though it makes a lot of sense, technically, to refresh just the content area, the users are tuned to the browser’s back and forward buttons for navigation. While there are ways to handle the browser’s back button in Javascript (Dojo has one of the decent implementations) the user experience is simply not the same. One of the approaches we experimented is to build the pages from templates, where each component such as the header, footer, sidebar etc., is an HTML page in its own right, which has cache control enabled. So when the top level page refreshes, the components are served from the cache with only the main content loaded from the backend. So, the page loads fairly quickly though not as smooth as using XHR to load the content. But, the user experience is not hampered, not their ability to navigate back and forth, bookmark the pages and so on.

By: JaxPhper

JaxPhper — Mon, 06 Oct 2008 17:04:11 +0000

I think the question should shift to time and cost as well. I mean time is money in this industry. Is it worth spending hours of coding to get rid of a refresh flash. I personally don’t think so. I would rather spend that time increasing the user experience in more dramatic ways.