[LINK] AJAX May Be Considered Harmful

[Roger Clarke]

>brd at iimetro.com.au wrote:
>>  AJAX May Be Considered Harmful
>>  Slashdot
>>  http://it.slashdot.org/it/07/01/06/216245.shtml
>
At 19:37 +1100 8/1/07, Rick Welykochy wrote:
>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.

Bugger copyright, this deserves wide distribution and widely 
distributed archival.  (Quite apart from the information content, 
even after years of practice I seldom manage to write with such 
clarity!).

>------------------------------------------------------------------------
>
>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.
>_______________________________________________
>Link mailing list
>Link at mailman.anu.edu.au
>http://mailman.anu.edu.au/mailman/listinfo/link

-- 
Roger Clarke                  http://www.anu.edu.au/people/Roger.Clarke/

Xamax Consultancy Pty Ltd      78 Sidaway St, Chapman ACT 2611 AUSTRALIA
                    Tel: +61 2 6288 1472, and 6288 6916
mailto:Roger.Clarke at xamax.com.au                http://www.xamax.com.au/

Visiting Professor in Info Science & Eng  Australian National University
Visiting Professor in the eCommerce Program      University of Hong Kong
Visiting Professor in the Cyberspace Law & Policy Centre      Uni of NSW