Matt said:
In the past couple of weeks, I've heard
a number of references to the term "Ajax".
Asynchronous JAvascript and Xml -> AJAX
A fellow developer asked me if we should use ajax on
a web app, and I asked "what is that?"
I had a similar experience last month when my manager wandered up to me
and asked if the web application that I am working on at present was
"Ajax conforming". I didn't know what he was talking about, and a little
questioning revealed that he did not know either. I.E., as David
suggested, it is a buzzword, and we (client-side programmers) would be
well advised to have some sort of response ready for when it is used.
"Oh, it's a brand new way of developing web pages which
refresh in the background using XmlHttpRequest!"
This would be 'brand new' in the sense that XmlHttpRequest is 'brand
new', as asynchronous background loading (with Iframes, etc.) has been
going on form some years now.
"Oh, you mean like what people have been doing for a
long time???"
Precisely
Well, apparently the person had read this:
http://www.adaptivepath.com/publications/essays/archives/000385.php
This was my first exposure to the term "Ajax" to describe
what many of us have done many times.
Background loading yes, but was it Ajax?
My question is, is the term "ajax" going to stick?
Probably, but my impression is that it doesn't mean enough at present
(is not sufficiently clearly defined) to be certain of what it will mean
if it does stick.
Is it going to
become a defacto standard term now?
Sometimes the use of English, and terminology, is debated in this group
beyond what is useful, but I don't see any use in a 'standard term'
without a clear idea of what that term is intended to mean.
Asynchronous, javascript and xml, in combination are not enough to mean
anything in particular and the proposal to have an "ajax engine" as an
additional layer in a web application doesn't say much either.
Returning to my manager's question; our web application is not "ajax
conforming" (IMO) but it is very close, and moving in that direction.
Not because of any interest in the buzzword but because that direction
has been perceived as offering improved performance. Our application
uses WSDL/SOAP (so xml), xmlHttpRequests and it is asynchronous
(mostly). It also has layers; a low level layer doing all
xmlHttpRequsts, a WSDL layer to understand the SOAP operations, a SOAP
layer to use those operations, and a GUI <-> SOAP layer (which may
itself be perceived as made up of multiple layers, and certainly is a
collaboration of many objects) to do something with the background
loaded information.
Potentially I could pick on some aspect(s) of that structure and label
it an "ajax engine" (maybe with a little re-organisation so it could be
seen as objectively distinct), but I see no value in doing so as a
response to a buzzword. I would want to have a much better idea of what
an "ajax engine" was supposed to be and how it was supposed to work, and
then only attach the label if it was really appropriate.
Also, is there any development effort going on to standardize
on best practices for using these tools? Any guides for what
works best and what does not?
That is really the crux of the issue. A GUI that operates though
asynchronous background requests may be responsive but there is a
certain chaos that comes with asynchronous and deserves a
well-considered (and probably formalised) strategy in its handling. For
example, a user types something into a field that represents a database
key and when they tab out of that field a background request sends the
key and, if it is found in the database, returns with values to be
filled in on half a dozen other fields. But when the key is not found
the response to the returned error is to blank the key field and force
the focus back into it. The successful response would reasonable at any
point shortly after the user left the field, the unsuccessful response
would potentially find the user mid way through typing into another
field (being asynchronous) and leave them typing the second half of
whatever it was into the key field. That would be a _bad_ GUI.
It is in the creation of formal strategies for the handling of
asynchronous interactions between a GUI and an "ajax engine" that ajax
might become something sufficiently tangible to be objectively
implemented.
I am also inclined to take issue with the 'x' in ajax standing for XML.
We use SOAP (and so XML) because the existing server-side system has a
built in web services facility and so no additional server-side
programming effort is needed. But XML carries an overhead that it needs
in order to be sufficiently general, but our web application is not
general and could happily accept the transferred data in any number of
formats (say JSON, or a custom format). If we had to write the
server-side code anyway my choice would be to provide the responses to
the client in the most compact (therefor fastest) form that was
practical, and design out the overheads of XML and SOAP at both ends.
The XML part of ajax seems the least significant, with the asynchronous
client-side activity being the aspect needing the most thought and
effort, so maybe Asynchronous JAvascript eXchange could be a better
explanation of the label.
There doesn't seem to be a lot of info available out there
yet. I already know how to build things using the tools, but
if someone has already started putting a layer on top of them
to make a useful suite of functions and methodologies, that
would make it much easier and faster to implement this approach
into new apps (especially for junior web developers who don't
have much exposure to this approach).
<snip>
Knowing you, you are thinking in terms of the functions as pre-built
libraries (for your 'junior web developers'), while I am more interested
in the methodologies. I have not seen either and it is entirely possible
that neither are at all developed yet (even among those that would
assert that they are already using ajax). Any pre-build library (that
was worth the effort) would need to be written based on the
methodologies, which in tern probably need to be validated through the
effort of trying them out in web applications (or pulling them from the
experience of developing asynchronous requesting web applications). It
might just be too soon to tell whether ajax is going to be a tangible
and viable design strategy for a particular type of client-server
application or a buzzword applied to anything vaguely xmlHttpRequest
related.
Richard.
