By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,627 Members | 1,781 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,627 IT Pros & Developers. It's quick & easy.

Ajax: A new accepted term?

P: n/a
In the past couple of weeks, I've heard a number of references to the term
"Ajax".

A fellow developer asked me if we should use ajax on a web app, and I asked
"what is that?"
"Oh, it's a brand new way of developing web pages which refresh in the
background using XmlHttpRequest!"
"Oh, you mean like what people have been doing for a long time???"

Well, apparently the person had read this:
http://www.adaptivepath.com/publicat...ves/000385.php

This was my first exposure to the term "Ajax" to describe what many of us
have done many times.

My question is, is the term "ajax" going to stick? Is it going to become a
defacto standard term now?

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?

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

So, who has the lead on this one?

--
Matt Kruse
http://www.JavascriptToolbox.com
Jul 23 '05 #1
Share this Question
Share on Google+
9 Replies


P: n/a
Matt Kruse wrote:
My question is, is the term "ajax" going to stick? Is it going to
become a defacto standard term now?


Any technology that relies on the availability of *script on the client-side
isn't reliable enough to become a standard.
JW

Jul 23 '05 #2

P: n/a
Matt Kruse wrote:
In the past couple of weeks, I've heard a number of references to the term
"Ajax". My question is, is the term "ajax" going to stick? Is it going to become a
defacto standard term now?


Its a Buzzword. The PHBs seem to like it. I wouldn't be surprised if it
stuck.
--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is
Jul 23 '05 #3

P: n/a
Janwillem Borleffs wrote:
Any technology that relies on the availability of *script on the
client-side isn't reliable enough to become a standard.


Like ECMA-262? Oh wait - that's already a standard!

Or DOM1 for ECMAScript? That's a W3C Recommendation.

There is nothing wrong with client side scripting. There is no reason for
there not to be standards in client side scripting. There's usually no good
excuse for not providing a graceful fall-back for scripting impaired user
agents.

--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is
Jul 23 '05 #4

P: n/a
Janwillem Borleffs wrote:
Any technology that relies on the availability of *script on the
client-side isn't reliable enough to become a standard.


*laugh* Okay, buddy. Whatever you say :)

--
Matt Kruse
http://www.JavascriptToolbox.com
Jul 23 '05 #5

P: n/a

"David Dorward" <do*****@yahoo.com> wrote in message
news:d2*******************@news.demon.co.uk...
Matt Kruse wrote:
In the past couple of weeks, I've heard a number of references to the term "Ajax".

My question is, is the term "ajax" going to stick? Is it going to become a defacto standard term now?


Its a Buzzword. The PHBs seem to like it. I wouldn't be surprised if it
stuck.

Let 'em all know it's a French word - that'll stop it cold.
Jul 23 '05 #6

P: n/a

"Janwillem Borleffs" <jw@jwscripts.com> wrote in message
news:42***********************@news.euronet.nl...
Matt Kruse wrote:
My question is, is the term "ajax" going to stick? Is it going to
become a defacto standard term now?

Any technology that relies on the availability of *script on the

client-side isn't reliable enough to become a standard.

What color is the sky in your world?

Jul 23 '05 #7

P: n/a
El Pollo Borracho wrote:
What color is the sky in your world?


Very dark since people are making websites which can only be viewed and
operated with client-side JavaScript enabled.

BTW, what I meant was that any technology that relies on a client-side
scripting language being enabled and doesn't offer a proper fallback should
not be a standard. I did not mean the scripting language itself!
JW

Jul 23 '05 #8

P: n/a
Janwillem Borleffs wrote:
BTW, what I meant was that any technology that relies on a client-side
scripting language being enabled and doesn't offer a proper fallback
should not be a standard.


Seriously, that is in itself a ridiculous statement.

Your point is valid if you just consider public websites that try to be
useable by the disabled and by all possible internet user. Relying on
javascript and XmlHttpRequest knocks you right out of the water if those are
your requirements.

However,

a) This methodology is most useful as a public site add-on, or in web
applications, which are most often used in an intranet environment

b) Not every web site is concerned about supporting every possible viewer

c) Something doesn't have to be useable by everyone to be a "standard". And
I wasn't even talking about the methodology anyway - that's already being
used and the pros and cons are already being discussed. I was talking about
the term.

Personally, I think "Ajax" will stick just because it's short, easy to say,
and has a "J" in like Java and Javascript and an "X" in it like XML. It
sounds like a web thingy, which will make the pointy-haired bosses and
marketing folks take notice.

I tried to register AjaxForum.com just to start a central place for the
whole topic to be discussed, but it was already taken just this last week.
So the name _must_ be catching on :)

--
Matt Kruse
http://www.JavascriptToolbox.com
Jul 23 '05 #9

P: n/a
Matt Kruse wrote:
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/publicat...ves/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.
Jul 23 '05 #10

This discussion thread is closed

Replies have been disabled for this discussion.