views:

328

answers:

7

I'm planning on making my web app quite AJAX heavy.

Before I do, I'm wondering what people think of such sites. Are there any significant reasons not to do this?

BTW, no need to mention SEO reasons. Also, I think the benefits make up for the fact that people without javascript will have a limited experience (though I'm open to being convinced otherwise).

+6  A: 

AJAX is a tool for a job. If your application is best served by the tool, use it.

Edit -- just make sure the tradeoffs are well understood. Also, nothing in using AJAX prevents you from having a non-ajax backup ready for if you need it...

hvgotcodes
+3  A: 

It depends on how you use AJAX. Pages where you have to wait while the page is rendered AND THEN wait another 10secs while the scripts execute and load the actual content, make people angry. Pages, which load fast and do a good job with AJAX, are fine of course.

Search engine optimization is one thing, but ability to find things in your site is another. You will have to think of a way for Google to index your content. Hence, you will still have to have a "plain text" version, where links behave as links.

naivists
+1 for the remark about slow page loading; my mobile phone company has such a horrible site: it's slow anyway, but the main page of my account is built with 4 AJAX requests.
Marcel Korpel
+12  A: 

It depends on how you plan to use it, IMO.

1) If the site will absolutely fail without it, you are excluding users with scripting disabled. I think it is fair in many scenarios to limit but not remove functionality for no-script users (for example, Google doesn't autocomplete searches if you have scripting disabled; it can't...but the basic search still works).

2) The right techniques need to be used in the right place. For example, an ASP.Net UpdatePanel will perform horribly if you dump thousands of elements into it.

3) I am becoming a bigger and bigger fan of content that is loaded in small blocks on the page that does not require a full refresh NOR does it require the whole page to be executed again. This lends itself to a SOA nicely, but is even more subject to the limits of #1.

4) EDIT: Don't create UI elements that (due to AJAX) behave unexpectedly. For example, I once built a dropdown list that only populated when it was toggled. Because of latency and DOM creation time, it wasn't responsive. Furthermore, the size would often change based on what elements were dynamically added. You could propose ways around these problems, but that was still an incorrect use of the technology.

Tim
+1 Thanks, good insights.
Kyle
+1  A: 

Deep linking can be an issue with Ajax heavy sites. There are ways around it (i.e. using the url-hash technique) but those are not always fail safe.

Neil N
Yes, I plan on using url hashes for deep linking.
Kyle
+4  A: 

Obviously, there are many popular sites that rely on AJAX, so it certainly need not be avoided if used well. However, there are things to consider:

  • Will users need to be able to deep-link (i.e. save bookmarks to "pages" that have been created dynamically)? Will they need to use the back button to navigate? (Both of these things can be done using AJAX but they need to be explicitly considered, as naive implementations of AJAX can make them work poorly or not at all.)
  • Will the use of AJAX have a negative impact for disabled users (e.g. those using a screen reader)?
JacobM
+1 for the deep link comment. I've seen incorrect implementations which mangle navigation (e.g. changing the expected behavior of the back button).
Tim
Regarding screen readers etc, most if not all of that can be mitigated via ARIA, allowing good accessibility for even pure javascript apps
unomi
+1  A: 

You can make your site AJAX based and still not miss on the SEO if you plan in advance. Here is the link by Google on how to make your AJAX content crawlable.

http://code.google.com/web/ajaxcrawling/docs/getting-started.html

Rajat
+1  A: 
Greg Hewgill
I believe it won't get any better, if you reload the whole page :-)
naivists
@naivists: avoiding round trips to the server before providing UI feedback is one way to avoid this problem.
Greg Hewgill
That's why one should render the whole page without AJAX first, and then on some user interaction, do stuff with AJAX. It's a bad idea to have AJAX callbacks on the page load, it's useless and degrades performances
Mike Gleason jr Couturier
@Mike - I don't think that's always the case. Let's say you have a page with one very slow running component. Caching/optimization aside, IMO it is much better to load the chrome of the page, other content, and a clear "XYZ is loading" message in place of the loading content than to render the whole thing synchronously and have the page appear to hang for several seconds. I have implemented this pattern in several production applications and it is what both the users and the business stakeholders prefer.
Tim