Ajaxing the Rails

Rails 0.11.0 is out on the street and I'm especially proud of the Ajax support we've been able to include. Instead of trying to soften the blow of doing client-side Javascript libraries as many others are doing, we've gone ahead and more or less removed the need for hand-written client-side javascript entirely.

This is done by off-loading the creation of DOM elements to the server side, which returns complete constructs that are then injected live through innerHTML. While this method is slightly more verbose than just peddling data across the wire, it's immensely easier to develop.

And especially the ease of development is critical to the success of Ajax. I used the old style of hand-crafting the DOM on the client-side with Ta-da List and was quite disillusioned at the mess of browser differences and the sheer effort it took. Basically, each sliver of Ajax was a project in itself.

With Backpack, though, I've been all over the new Ajax style that Rails affords. And what a difference it makes! It's basically no harder to make something Ajaxed than it is not to, which means that the decision is based on whether its a good fit for the user interface — not on whether we have time to another Ajax project.

We can argue about the name, we can argue old wine on new bottles, but the attention this technique is getting and its integration in frameworks like Rails will rocket its use to the moon and further blur the decision on when you need to go rich and when not to.

Really, really, really cool!

I can only agree wholeheartedly. Using Ajax though, 9 times out of 10 when it comes to filling out a firm, is better than not, since you can provide the user/visitor with immediate feedback regarding the validity of the data he/she is putting in the form.

Ajax is old wine in a new bottle, definately, there is no arguing there. What's new and very brightly shining about this is that, like you said, adding Ajax-functionality is barely any more work than not doing so.

Ajax used to be sparse because it's too much work for too little gain, whereas from now on, I predict, it will be used whenever it can and should be, and in the process Ajax and Rails may even become at least a little bit synonymous, in the sense that almost all future Rails apps will have plenty of Ajaxified forms, whereas the rest of the world continues to implement Ajax only when time permits.

"Basically, each sliver of Ajax was a project in itself."

Yeah, that's why it hasn't really been too appealing to us at work yet. As much as we'd like to include it, the idea of hand-crafting DOM-manipulation callbacks for every little thing seemed like a maintenence nightmare. Although we're not developing in Rails (sigh), this model looks really elegant.

I think I shall start worshipping you, like the god you are. This is *awesome*.

Elegant & Slick.

This feature alone should be enough to convince fence-sitters to get on the Rail train.

Wow. This is really neat. I'm getting ready to do my first project in Rails and yesterday I was thinking "Looks like i'll need to do some user reg stuff", and then this morning I find the Login Generator. So I start thinking "Hmm, this ajax stuff might be complicated" and you release this just in time for me.

Utterly impressed.

Sweet.

One question though: Any analysis of how much the difference in wire speed is between the two methods for arbitrarily complex web apps?

Just thinking about when I'd want to say, "Okay, for Narrow Band user concerns, we're going to do the Ajax on the client."

With all the talk of "wires", "over/across the wire", and "wire speed", I feel like we're talking about telegraphs.

i agree with going the simpler innerHTML-replacement route. that's how i did a project a while back (in php) and wasn't sure it was the 'best' way to do it, even though it definitely seemed like the simplest way to go. it worked well, so i'm glad to see this becoming the rails way.

Integrating AJAX to web frameworks is definately the way to go. We will be seeing more of this. However, the method described here is not AJAX, it's AJAH: Asynchronous JAvascript and HTML!

I don't mean that as a big criticism, but now that everyone has decided on this new term 'AJAX' to represent something we've known about for a long time, let's not dilute the power of the terminology.

AJAX means something, and it doesn't mean this.

That said, I can't wait to try it out ....

David Roussel wrote: "AJAX means something, and it doesn't mean this"
Are you sure Jesse James Garret of Adaptive Path, who coined and defined the term "AJAX", meant to define it that narrowly? I believe that this is exactly the kind of thing Jesse meant when he defined the term, even though we're passing HTML instead of XML.

While this sounds good, I am bit concerned by the use of innerHTML, which is not part of the DOM - I know it is supported by almost all newer browsers, but people should really get used to using nodes instead..

Still pretty cool though - Ajax (hype left aside) is great!

I'd certainly debate that. In my mind, AJAX simply means cool and usefulvery dynamic web... stuff. It's totally a user oriented "technology" therefore it doesn't really matter at all what the transmission method is as long as the end product is freakin' sweet.

The only "downfall" to using innerHtml is that it's only supported in HTML and not in XHTML. But I think more and more people are concluding that XHTML isn't a silver bullet and have been reverting back to HTML.

Got ajax?

Wow, great. Having marched through an awful lot of javascript messiness I can only agree with your notion of the layers being hard work.

But, *please*, let us all stop using that dreadful name Ajax, please!

I'm not sure what Backpack does, but whatever it is, I sure hope the folks who've been trying out stuffs like Ta-da and Basecamp gets good transitioning/migration tools.

Sure I'd love to tie up my life's loose ends.. But having to tie and re-tie would suck.

It'd be nice to have a way to do:
{:action=>'call_me'}} %>">

Ah.. dumb html escape.
It'd be nice to have a way to do:
>notformtag onclick=">%= remote_call {:url=>{:action=>'call_me'}} %>">

Or have the prototype.js actually documented.

Using innerHTML is a great idea, but....

I don't think setting the innerHTML property works on tables and select lists in Internet Explorer, although it seems to work in Mozilla/Firefox. Can anybody else confirm this?

If so, is there an IE work around?

I looked around for innerHTML compatibility lists and found this useful chart on compatibility across browsers. Seems like the only quirks are in Mac IE 5.2.

There is a reported bug in IE 5.0 if you add content by innerHTML to table cells which have overflow: auto or hidden.

On that same site, I found really interesting speed test between DOM and innerHTML. The innerHTML approach spanks W3C DOM methods in every browser but Safari 1.0.

Bill,

Thanks for the link on innerHTML compatibility accross browsers.

OK, the example demonstrates creating a *new* table and putting it into a div tag. The bug I'm talking about: Create a table in HTML. Create JavaScript that builds a string representing a new row on the table. Now, try to append the new row to the table like the following:

var newRow = "Hello";
var targetTable = document.getElementById("targetTable");
targetTable.innerHTML = targetTable.innerHTML + newRow;

For me at least, it works in Mozilla/Firefox but always fails in Internet Explorer.

This seems to be an IE bug that is documented on the Web. Can anybody else confirm?

Thanks!!

innerHTML is read-only property for tables (and some other elements) in IE.

http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/innerhtml.asp

Interesting to consider the opposite of this approach: client-side templating, and a general client-side framework for turning XMLHttp calls retrieving semantic javascript into HTML and plugging them. Has this been done yet?

TrimPath has client side templating using javascript arrays/hashes: http://trimpath.com/. It also has an SQL-like query engine for javascript arrays. Use this in conjunction with JSON and you're all set. However, this would be considerably more difficult than using the built-in Ajax helpers. I'll try it out sometime soon.

Also, I was initially put off by the implementations reliance on the non-standard innerHtml property. But the last I checked, XmlHttpRequest isn't a standard either. It's a proprietary MS object that happens to have been cloned in other browsers (much like innerHtml and ContentEditable regions)

It'd be nice to have a way to do:
{:action=>'call_me'}} %>">

agenzie investigative italiane