When in Rubyland, do as the Rubians do. It’s no surprise that Microsoft got a good reception by talking up the idea of ARAX (Asynchronous Ruby and XML) at (of all places) last week’s RailsConf event in Portland, Oregon.

I hear a distinct echo, though, of a preemptively hype-puncturing blog post made by Microsoft’s own Dare Obasanjo more than two years ago: as he pointed out at that time, the "J" for "JavaScript" in the popular "Ajax" label (it’s not an acronym, and it’s not correct to render it in all caps) is not to be narrowly construed.

As Dare observed with both wisdom and wit, "The Ajax hype…has
little to do with the technology and more to do with the quality of
developers building apps at Google [Inc]. If Google builds their next
UI without the use of XML but only JavaScript and HTML, will we be
inundated with hype about the new JUDO approach (Javascript and
Unspecified DOM methods) because it uses proprietary DOM extensions not
in the W3C standard?"

Even more to the point, it was more than three years ago that software researcher Ian Hixie made his plea, "Could people please stop making up
new names for existing technologies? Just call things by their real
name! If the real name is too long (the name Ajax was apparently
coined because ‘HTTP+XML+HTML+XMLHttpRequest+JavaScript+CSS’ was too
long) then just mention the important bits. For example, instead of
REST, just ‘HTTP’; instead of DHTML just ‘HTML and script’, and
instead of Ajax, ‘XML and script’."

Proposing the use of Ruby rather than JavaScript, it seems to me, is like introducing a new dipping sauce for fast-food chicken: it doesn’t change what’s inside the coating of crumbs — and the problem with getting all excited about ARAX versus Ajax is that it accentuates a minor difference while overlooking a shared crucial flaw.

When Microsoft’s John Lam went to RailsConf to talk about his IronRuby project, he asserted that developers would gain by avoiding a mental shift between two different languages on either side of the client-server boundary. "At some point," he said, "you
might have to add some JavaScript code that adds some custom functionality on
the client" — but my question is, why are we still talking about client-side code at all?

The whole point of Apex Code, in particular, is that code doesn’t have to run in the variegated environments of different browsers on different fat-client stacks: the application’s logic runs in the cloud, with consistency guaranteed as an inherent property of having only one execution environment.

Also open to question is just how much mindshare a language like Ruby commands…but that’s another subject for another time.