[LINK] AJAX May Be Considered Harmful

grove at zeta.org.au grove at zeta.org.au
Mon Jan 8 23:55:50 AEDT 2007

On Mon, 8 Jan 2007, Adrian Chadd wrote:

> On Mon, Jan 08, 2007, Rick Welykochy wrote:
>> 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.
> I don't buy it. It has to be written -badly- for it to have that kind of
> performance hit.
> There's many reasons to think twice before deploying lots of AJAX'ed apps
> but they have more to do with the people writing/verifying it than the
> technology involved.
> (Damnit Browser Vendors: where's my F$CKING sandbox that you touted as
> a wonderful thing in the mid 90s?)

One of the big issues is that a lot of programmers are not testing their
designs over a WAN or Internet.  Thus we see the fabled "it works 
great on my workstation" scenarios where hapless web monkey has a perfectly 
working suite of Ajax apps, but fails to identify what happens when 
you're pushing lots of data down the pipe, when you're hopping across
networks, being routed by a Content Switch, proxied, fragmented and 

In the middle of all this, you have situations where the servers themselves
are really not tuned properly for content of the appropriate type.   When
your appserver is pushing loads of Ajax enabled java servlets and 
the queries get stuck in lots of CLOSE_WAIT connections, which can 
be caused by a poorly written app, that either has a Java thread that
has lost it's parent, or a session closed too quick by a user, 
or a poorly formed SQL query that creates a seeming hang of the client,
which is then closed by the user and so on.

No one seems to test for these things much.  Rob, my partner, who is 
a web developer has recently started looking at Ajax as a solution 
to his problems, but has decided it is not properly ready yet.

He is in a position where the decree from above is that PHP is the language
to be used for web dev, hell in fact they are trying to force him to 
use a HTML editor instead of vi and so on.   So he is constrained by
being a Perl hacker, forced to work in the constraints of the 
Poorly Hosted Pages product and the related technologies.

We have found numerous problems with PHP, from the implementations
of the Oracle OCI plug, to the way it interacts with the user 
sessions and so on.   We have looked at workarounds and he has written
code that is as secure as is possible.   What he likes about PHP 
is the Object Oriented aspects of it - he's written beautiful, elegant
code that works great and even I can understand it.  But the handling 
of variables and the passing of values to parameters in functions 
is a bit painful, unlike the simple elegance of CGI.pm which can do 
anything you want, safely and simply.

So of course the time for development stretches out because to 
taint check your PHP code takes a lot longer than it does in Perl,
because when you taint perl, it whinges and carries on, whereas PHP 
will quite happily accept practically anything you throw at it.

This is where the problems with Ajax breaks down and what it is supposed
to accomplish - a form of Validation of user input prior to it hitting 
the database or whatever your tier is.   Ajax can do the Validation
stuff just fine, but it's no good if it can be readily usurped, because
then you have to rely on PHP to accept the guff it's been offered.

It's very tempting to use Ajax, because it does have some merit,
but there seems to be a fork in RAD development these days where 
the end product "just works" but really it's become a rush job, 
where only the most basic thought is put into what the data is really
doing on the network....


Rachel Polanskis                 Kingswood, Greater Western Sydney, Australia
grove at zeta.org.au                http://www.zeta.org.au/~grove/grove.html
 	"They who would give up an essential liberty for temporary security,
 	deserve neither liberty or security" - Benjamin Franklin, 1759

More information about the Link mailing list