Welcome!

Java Authors: Liz McMillan, Frank Huerta, Elizabeth White, Pat Romanski, Sandi Mappic

Related Topics: Java, SOA & WOA, Open Source

Java: Article

ClearNova Exec Defends Open Source AJAX Development vs Java

Steve Benfield Objects to Comment by Yakov Fain

SYS-CON special correspondent and well-known author and teacher Yakov Fain recently took the emerging (or re-emerging) AJAX development world to task.

Writing in his recent Java blog entry, Fain (pictured above) said,

"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 where this technology is being used: Google maps and e-mail. (BTW, I'm a little sick of these examples). Since I'm not going to be helping Google in improving their maps, I'd like to see some real-world examples implementing this technology."

ClearNova's Vice President of Strategy and Evangelism Steve Benfield, a leading proponent of AJAX development, took a bit of umbrage at these remarks, with a post of his own. Benfield (pictured below) protested:

"First, entry level developers can't do much to begin with. But they can use tools--as can intermediate and advanced developers. So what you'll see growing around AJAX are tools and frameworks--in droves.

"So, a better way to phrase the question is--can VB + PowerBuilder developers build their current apps without the tools they use--probably not. And even if they can, who wants to? It takes too long because hand-coding GUI is painful--something that is only for people that have too much time, bililng by the hour, or who have some very stringent functionality and/or performance goals.

"So, yes, I believe these programmers can build AJAX applications--with the right tools and frameworks.

"It is easy to say, just build it in Swing instead--but AJAX provides ubiquity across browsers with no special downloads--and it's backend independent. So you're free to choose a backend language and server whether its Java, PHP, .NET, Ruby, etc. Today, AJAX techniques can cover maybe 80% of the client/server GUI apps you might want to build. I predict more in the future.

"If you need to deliver apps to a mix audience--or you want to use a common set of programming techniques for your public and internal applications--then AJAX provides that. Any other downloadable medium does not although flash gets closer than anyone.

"Full disclosure: I represent a company that provides ThinkCAP JX, an open source, J2EE-based AJAX development environment and framework."

Sounds like the beginning of a good debate. What do you think?

More Stories By Open Source News

Enterprise Open Source News Desk trawls the fast-growing world of Professional Open Source for business-relevant items of news, opinion, and insight.

Comments (7) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
Don Babcock 12/16/05 01:15:22 PM EST

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.

SVen 12/15/05 12:51:08 PM EST

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.

SVen 12/15/05 12:48:58 PM EST

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.

SYS-CON Canada News Desk 12/14/05 05:37:00 PM EST

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.

JDJ News Desk 12/14/05 05:20:21 PM EST

'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.

JDJ News Desk 12/14/05 05:13:17 PM EST

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.

JDJ News Desk 12/14/05 04:14:52 PM EST

'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.