tags:

views:

59

answers:

2

I know this seems like a really subjective question, but from what I'm reading, I'm generally confused. We are developing a web-based application that has tabbed windows, etc-very much a "desktop-like" application graphically. About half the page never or rarely changes, and the other half is content that could be handled dynamically within a main window.

So from the ajax proponents, this seems like a perfect example of something that would benefit from ajax. The only thing stopping me (other than lack of ability :-D) is that I'm concerned we would degrade the speed of the app (which isn't really all that great anyway...)

Can anyone either shed some light on this subject or point me to more reading material on performance differences when changing lots of data at once via ajax?

+5  A: 

About the differences that can often be seen :

  • If you load more data via AJax requests, and less via "full-page" requests, it means :
    • less data will go through the network (only content of pages, not menus, sidebars, ...)
    • less thins to generate on the PHP/SQL side (same : no menu, ...)
  • But more Ajax requests can also mean more requests, depending on how your application is developped
    • Which can mean more load on the server...


You also might want to think about :

  • Indexation by search engines,
  • Accessibility,
  • Graceful degration,
  • and all the possible stuff like that...

Which, in the end, can mean you'll maybe spend lots of additionnal time developping the "more Ajax" version ; and time is money -- and a few days of developper-time can cost more than renting/buying a second server.


In the end, I would say what really matter is not "performance" : you'll probably have greater gains spending a couple of days optimizing what you already have (profiling on the backend side, minifying/compressing JS/CSS, merging JS/CSS files to have less HTTP requests, ...) than by transforming everything to "full-Ajax".

And, of course, what really matters is user-experience !

Pascal MARTIN
Speaking for my case, most of the "big" requests will be the equivalent of page loads. The problem is I'm painting myself into a corner. I just created a nice help-menu box that would require the user to switch pages now to follow the step...therefore reloading the helpbox unless the whole thing was ajax. :-D
Joel
In this case, what matters is user-experience : loading a full-page to read some help-block might not be great for users, while only loading the next portion of the help box could be more user-friendly.
Pascal MARTIN
I'm just going to make that not say 'realler'' as I don't believe 'realer' is a word.
Chacha102
@Chacha102 : ouch :-D Yes, of course ^^ I have no idea where that came from *(too early in the morning, maybe ?)* ^^ Thanks for the edit !
Pascal MARTIN
lol. 11:51 PM here...just getting started ;-D
Joel
Remember Tropic Thunder where we learned "you never go full-retard"? Ajax/Web 2.0 is the same thing, you never go full-Ajax.
Robert Fraser
A: 

As someone who just finished developing a similiar application i can say that using ajax to create a "desktop - like" application.... well... looks cool....

But there are certain points that you should be considering before you start...

  1. Dealing with forms when you a load a page with ajax will require the additional knowledge of a javascript framework like Jquery.... Because loading a page portion of a page with ajax does not affect the DOM tree of the page and hence the newly added elements will not be identified by javascript functions.... That's where you will be needing the livequery plugin for jquery.

  2. If you are looking do develop a site optimized for search engine indexing.... ajax - refreshed content may not be a good idea. I developed only the backend part. i.e the administrator module like a desktop application. The frontend where the user actually interact was your normal, day-to-day, website...!!

SpikETidE
and also.. i've never noticed any substantial slowdown of the application when developed fully with ajax...!!
SpikETidE