Jamis Buck wrote:
> 
> Innapropriate or not, it's certainly easier to talk about "Ajax" than
> "that technique that uses XMLHttpRequest to send asynchronous requests
> to the server via Javascript without having to reload the page."
> That's the point, I think--not that something new has been discovered,
> but that a label has been given to that thing to make it easier to
> discuss. I'd even go so far as to posit that the reason Ajax has taken
> so long to really start gaining attention is because there's not been
> an easy way to talk about it.
> 
> Think about design patterns. Most people agree that these are good
> things. However, most of these patterns are not new--it's just that
> they've recently been given names to facilitate discussion about them.
> 
> When you give something a name, you can define and then hide an entire
> host of assumptions behind it. That's where the value comes from.

That's also were the problems come in, too.  In the case of design 
patterns, many people have the habit of using the short-hand name as a 
stand-in for real understanding.   Different people may have different 
takes on the Foo pattern, but they don't realize they are talking past 
each other because they both assume the other people  use the term the 
same way as they do.

"Ajax" carries an important assumption: XML.  But, despite the name, 
XMLHttpRequest can send any text you like.  It is often more appropriate 
to use, say JSON, or unformatted text.  While some might argue that the 
term is meant to encompass more than just the use of XML, the very name 
tends to to encourage people to make what could be suboptimal choices, 
choices that that would be better served by thinking about each of the 
technologies involved.

It's like LAMP; a cute moniker for a type of Web development that 
favors, by its name, some less-than-the-best tools.  Makes it easy to 
sum up a general idea, but doesn't always serve the best interests of 
developers.

Given that XMLHttpRequest can send any text, I've wondered if there 
would be any advantage to sending YAML.

It lends itself to the acronym AJYL, which is reasonably clever, but I'm 
not sure there are any advantages over using JSON.  JSON is nice because 
client code is sent serialized JavaScript objects; the deserialization 
by the client is trivial.  It would be be harder with YAML, but the YAML 
data types (I think) are more robust than what is offered in JSON.  The 
server code would have a better time handling YAML than JSON.  It would 
be AJYLR.

Anyway, hanging a name on something is useful to be sure, but 
abstractions by definition mean loss of detail, and the details here may 
be critical.

James