While having a short discussion about AJAX and the ReST on our company’s internal mailinglist Johann brought up some interesting questions about this AJAX hype: does it really work for „normal“ web apps and how are the fixed costs for a HTTP request changing when using AJAX technology?
First of all, XMLHttpRequest has a problem: in InternetExplorer, it doesn’t work without ActiveX. This makes it pretty useless when being used in companies like HypoVereinsbank or Siemens (both are customers we’re working for) where ActiveX has been disabled for security reasons.
Second, the fixed costs for a HTTP requests are changing: while AJAX technology is designed to load just the delta of the data, your application design has to be changed in order to keep the performance: don’t include whole framework stuff while you receive a XMLHttpRequest that is only trying to receive three rows out of the database. Within „normal“ web apps you’ll have HTTP requests that are called less often but take longer, it is the opposite within XMLHttpRequest based applications: you have a lot more HTTP requests that ideally should consume less amount of time being processed – the user doesn’t want to wait within AJAX applications.
The solution for the fixed costs changing problem could be a combination of different methods: trying not to include all your framework stuff, use kinds of function caching etc.
Within 2-tier applications (for example one of our customers, Sixt, is relying heavily on XUL based applications) there is a possibility with some tricks avoiding huge traffic within loading/submitting the deltas.
What’s your experience?
„Within „normal“ web apps you’ll have HTTP requests that are called less often but take longer, it is the opposite within XMLHttpRequest based applications: you have a lot more HTTP requests that ideally should consume less amount of time being processed – the user doesn’t want to wait within AJAX applications.“
Very good point. I guess one way to look at it is existing web applications were built because they were regarded as feasible from the perspective of the UI – so why „AJAX“ them if there’s no benefit for an app that’s already good enough? Can imagine extending an existing code base to cope with a different kind of HTTP request is a significant effort. Perhaps there’s room for minor improvements to specific functionality, as Christian did with LiveSearch http://blog.bitflux.ch/wiki/LiveSearch, and that seems to be how most people are employing AJAX right now.
But certain types of app have stayed on the desktop, e.g. those for inputing / managing complex data. Users will be prepared to meet the installation requirements for such apps, I guess. Perhaps these make better targets for AJAX as fresh projects?
Otherwise, this AJAX makes web development alot more complex and with that comes great risk / effort.
Anyway, good to see some serious questions being raised about AJAX – been trying to kick off some more rational discussion here: http://ajaxblog.com/archives/2005/05/27/ajax-whats-a-session
PHP5 helps here. With overloading and __autoload() you can more easily „lazy load“ code as needed.
You can emulate the loading in IE without ActiveX, see the conclusion here
http://cain.supersized.org/archives/2-Dynamic-loading-of-external-JavaScript-.js-files.html that should do it too for this case. Just wrap the stuff :-)
That detail that on IE XMLHTTPRequest is implemented with ActiveX and under certain configurations it may be disabled is a very important detail. Since I am not a Windows user I appreciate the tip Bjoern.
While investigating the matter, a Windows user warned me that ActiveX support is disabled by SP2 for security reasons, so this may affect much more users than just the companies you mentioned.
I have been researching on this subject more recently because I have been having more and more requests to implement highly interactive input plug-ins for this popular forms generation class ( http://www.phpclasses.org/formsgeneration ). The conclusion that I am reaching is that it may be more reliable to rely on the availability iframes than on XMLHTTPRequest.
I was always using XMLHttpRequest but just in some limited applications for example on live search, some dynamic forms … but making all the application working based on XMLHttpRequest scared me a lil.
In fact, we could limit server load, but the concept itself of XMLHttpRequest will overload the server. User can go to the maximum of request per second : MoseOver or MouseClick …
Maybe i’m thinking to write a PHP game based on AJAX but redesign current application isnt in current plans.
Btw somebody experienced AJAX to send binary data base64 encoded ?
I’ve used some XMLHttpRequest and assorted AJAX libraries but I find that they’re needlessly complicated. Here’s one I made that seems to work fine so far, and has an alternate method in case XMLHttpRequest isn’t available. It lets me set_html() in a div by passing in either HTML content or an url from which to retrieve content.
http://www.sirensclef.com/xmlhttp.js
You can try this cool framework. Zaxas.
http://zaxas.sf.net
Its really easy to use .. with any platform.
My experience? here:
http://www.bloxor.com
Web pages should stay as pages.
In AJAX, the X is for XUL.
Web apps? now we’re talking.
In my opinion, make web applications in ajax+php is a good experience, because, I think, normaly, the php web-based are applications with an structure recursively (blogs, news…)
My experience: http://www.matriceriaymoldes.es
Neuere Ãœberlegungen gehen davon aus, dass IFrames/Frames in Verbindung mit zeitnahen Web-Anwendungen zu besseren Ergebnissen führen. Nach zu lesen unter anderem im Blog von Björn Schotte, sowei bei Manuel Lemos von PHPClasses. Lightstreamer (siehe B…
Ajax+PHP is a verry clearance way of using and making software!
This is my experience:
http://www.novulo.com