[LINK] AJAX May Be Considered Harmful

[Rick Welykochy]

brd at iimetro.com.au wrote:

> AJAX May Be Considered Harmful
> Slashdot
> http://it.slashdot.org/it/07/01/06/216245.shtml

An interesting bit of real-world experience with Javascript and AJAX
was submitted anonymously to the above thread, which I will recklessly
quote here in its entirety. From the sounds of it, AJAX is not to be
considered a viable applications building platform.

cheers
rickw

------------------------------------------------------------------------

AJAX applications just aren't solid or stable, for the most part. We tried to integrate a number of them into our 
network here, and frankly each attempt went terribly. I'd like to think it was just one application vendor or AJAX 
toolkit that was problematic, but that wasn't the case.

We found a number of common problems with every AJAX application we tried. Just for the record, the applications 
included three CMS systems, a Web-based email system, two groupware systems, and three Web forums.

The first major problem with one of resource usage, on both the client-side and the server-side. Client-side, many AJAX 
applications consume far too much CPU time. From our investigation, it was due to the use of poor JavaScript algorithms 
that'd consume 100% of the CPU in some cases, for minutes on end. The applications "worked", in that they'd provide the 
correct result. It'd just take them far too long to get it done.

On the server-side, they'd again result in excessive CPU and RAM consumption. For one of the Webmail systems, we could 
only handle a fifth (yes, 20%) of what our old Perl-based system could. And that was on a quad-core Opteron system with 
8 GB of RAM! The Perl-based system was on a couple of 200 MHz Pentium systems, each with 128 MB of RAM. Even after 
assistance from the AJAX-based Webmail system's vendor, we were only able to handle roughly 90% of the number of 
transactions of our older system.

The second major problem is that of usability. Many of the AJAX apps we tried didn't play well with browser tabs, for 
instance. Some even fucked around with text input areas, resulting in copy-and-pasting no longer working. One 
application even prevented the text within a text field from being highlighted! We thought these problems may be 
browser-specific incompatibilities, be we ran into this same problem with Firefox, Safari, Opera, and even IE6! After 
talking with the vendor, they admitted these were known problems, and no solutions were presently available.

The third major problem is a lack of quality. Many AJAX applications are poorly coded and poorly designed. I think the 
main reason for that is because it's such an unstructured technology. Even competent software developers run into 
problems that cannot be solved easily, and thus must resort to hackish techniques to overcome these inherent problems.

The fourth major problem was that the users hated the systems. Of the few systems we managed to roll out successfully, 
the users absolutely hated them. Their complaints were a combination of the above three factors. The AJAX applications 
would not do what the user wanted. The AJAX applications did not conform to common practices (eg. copy-and-paste, 
textbox text selection, etc.). The AJAX applications ran far too slowly, even on fast client machines. The AJAX 
applications just plain didn't work!

All of our AJAX trials were abysmal failures. That's why we're sticking with the existing Perl- and Java-based systems 
that we currently use. They perform far better on much fewer resources, actually do what the users want, avoid violating 
the most common of conventions, and they do what they're supposed to. I'm sorry to say it, but AJAX might just be the 
worst technology I have ever had to deal with.