A noble idea indeed. But what troubles me is that no one seems to be considering the network/bandwidth/processing implications of AJAX. With today's broadband networks, many developers consume bandwidth as carelessly as they consume hard drive space. It's an easy mindset to get into. I've got a 200GB drive on my system that I'll never come close to filling before the system itself is obsolete. But server bandwidth (processing capacity) is not growing as fast as network bandwidth. XmlHTTP requests are a terribly inefficient way to provide client server communications if you consider the attendant request processing and protocol header overhead. The AJAX proponents argue that they are making "smaller" requests instead of entire pages. But if you calculate comm efficiency by

(data / (data + overhead)) x 100%

you can easily see that reduced data size given a fixed cost in header and other overhead actually REDUCES network efficiency. What's to prevent an ambitious HTML page coder from making a server request round trip for every keystroke (i.e. a simple auto fill field - actually being suggested as an "ideal" candidate for AJAX treatment.) My concern here is that amidst all the hype, no one is taking a hard look at the underlying software engineering considerations. I'd admit that I cut my teeth in this field back when memory and processing were scarce and expensive. But it still irks me when I see thoughtless approaches which gobble these as if they were practically unlimited. AJAX is really nothing more than yet another workaround for the inherent limitations of the browser client-server standards. It presents a wonderful opportunity for careless coders to bring servers to their knees with multiplied http requests. Think of it this way - a conventional web app pretty much only allows users to fire requests at a server and over the network in "single shot" mode. But an AJAX app built without regard to network and request traffic can easily "gun down" a server as each user sprays it with requests in "full auto." I think more needs to be said in this cautionary vein. Most developers don't seem to consider network and request overhead issues appropriately. They just focus on the client and assume the server/network will be there for them. I think many will discover significant scaling problems with their "noble" AJAX applications.

I think there is some seriously flawed reasoning behind the Ajax approach. Writing event based code for the HTML widgets and perform some asynchronous tasks is nothing new. (Dynamically updated cascading menus using hidden applets to HTTP requests has been around for several years.) The Ajax tools just make it possible to do heavier async tasks and perhaps easier.

But I can tell you, even simple functionality like Form Input Validation in Java Script on a frontend quickly becomes tedious and unsupportable in reallife. Everytime backend rules change, more has to change on the frontend.

I cannot understand how you can deploy heavier and heavier functionality under the guise of a thin client not pay the price.

In otherwords, you are almost working like an ActiveX or an Applet but trying to look like HTML. Alternative is Swing or Active/X. All Ajax gives is avoiding downloading the JRE? Or you do not want to use the JRE? But Swing and Active/X are very well defined OO programming paradigms with excellent production management possibilities. can Java Script or any other script ever compete with an OO platform for production management and longterm total cost of ownership and value?

Isn't JRE an insurance against platform/browser vagaries?

Doesn't the user expect to download the JRE when he expects to use a rich client experience?

Ajax is against good programming common sense.

I think there is some seriously flawed reasoning behind the Ajax approach. Writing event based code for the HTML widgets and perform some asynchronous tasks is nothing new. (Dynamically updated cascading menus using hidden applets to HTTP requests has been around for several years.) The Ajax tools just make it possible to do heavier async tasks and perhaps easier.

But I can tell you, even simple functionality like Form Input Validation in Java Script on a frontend quickly becomes tedious and unsupportable in reallife. Everytime backend rules change, more has to change on the frontend.

I cannot understand how you can deploy heavier and heavier functionality under the guise of a thin client not pay the price.

In otherwords, you are almost working like an ActiveX or an Applet but trying to look like HTML. Alternative is Swing or Active/X. All Ajax gives is avoiding downloading the JRE? Or you do not want to use the JRE? But Swing and Active/X are very well defined OO programming paradigms with excellent production management possibilities. can Java Script or any other script ever compete with an OO platform for production management and longterm total cost of ownership and value?

Isn't JRE an insurance against platform/browser vagaries?

Doesn't the user expect to download the JRE when he expects to use a rich client experience?

Ajax is against good programming common sense.

ClearNova Exec Defends Open Source AJAX Development vs Java. 'A Cup of AJAX? Nay, Just Regular Java Please,' wrote Yakov Fain in his recent article for JDJ blog entry. 'The idea is noble: instead of rendering an entire HTML page on each little change on the page, it's much better to send an asynchronous request that will get the data for you and refresh only the relevant portion of the screen. (But) every author writing on AJAX is giving the same (the only?) examples.' Now ClearNova's Steve Benfield, an AJAX proponent, has responded.

'A Cup of AJAX? Nay, Just Regular Java Please,' wrote Yakov Fain in his recent article for JDJ blog entry. 'The idea is noble: instead of rendering an entire HTML page on each little change on the page, it's much better to send an asynchronous request that will get the data for you and refresh only the relevant portion of the screen. (But) every author writing on AJAX is giving the same (the only?) examples.' Now ClearNova's Steve Benfield, an AJAX proponent, has responded.

ClearNova Exec Defends Open Source AJAX Development vs Java. 'A Cup of AJAX? Nay, Just Regular Java Please,' wrote Yakov Fain in his recent article for JDJ blog entry. 'The idea is noble: instead of rendering an entire HTML page on each little change on the page, it's much better to send an asynchronous request that will get the data for you and refresh only the relevant portion of the screen. (But) every author writing on AJAX is giving the same (the only?) examples.' Now ClearNova's Steve Benfield, an AJAX proponent, has responded.

'A Cup of AJAX? Nay, Just Regular Java Please,' wrote Yakov Fain in a recent article for SYS-CON Media's JDJ. 'The idea is noble: instead of rendering an entire HTML page on each little change on the page, it's much better to send an asynchronous request that will get the data for you and refresh only the relevant portion of the screen. (But) every author writing on AJAX is giving the same (the only?) examples.' Now ClearNova's Steve Benfield, an AJAX proponent, has responded.