AJAX and Rails at ETech

I'm at the O'Reilly Emerging Technology Conference, called ETech, all this week.  I'll be posting updates on interesting happenings throughout the week.
Written by Phil Windley, Contributor on

I'm at the O'Reilly Emerging Technology Conference, called ETech, all this week.  I'll be posting updates on interesting happenings throughout the week.  For me, day one of ETech was mostly about JavaScript, AJAX, and Ruby. I spent the morning in a tutorial by Simon Willison on JavaScript and the afternoon in David Heinemeier Hansson's session on soon-to-be-released support for AJAX in Rails (v1.1).

The JavaScript tutorial (detailed notes) was very good, sprinkled with bits of wisdom about what to do and what to avoid inside JavaScript programs. I came away with the impression that JavaScript was covered with warts and conceptual inconsistencies, but since it's the only real programming language in the browser, it's at the nexus of some fascinating development work.

Here were the walkaways:

  • Everything in JavaScript is an object, even functions.
  • Every object is always mutable
  • The dot operator is equivalent to de-referencing by hash
  • The new keyword creates an object that class constructors run inside of, thereby imprinting them
  • Functions are always closures
  • The this keyword is relative to the execution context, not the declaration context (dynamically scoped)
  • The prototype property is mutable. This is the basis of inheritance in JavaScript.

One more: there are several libraries that try to layer on compatibility features, but they all fall short in various ways. Still, if you're trying to do something in JavaScript, start from a good library, rather than inventing the wheel yourself.

The afternoon session (detailed notes) showed off new features in Rails (v1.1) that support AJAX. In typical Rails fashion, the focus was on reducing the places where programmers have to repeat themselves.

The chief culprit of repetition in AJAX is that you have to create the page in the first place, then you have to write JavaScript that understands that page model and can modify it. So, changing the page requires not only updating the HTML, but the JavaScript as well.

Rails 1.1 solves this problem by moving the HTML into what are called "partials," small bits of HTML that render the relevant pieces and  writing RJS files (Rails JavaScript) that manipulate them. The RJS files don't necessarily contain JavaScript, they contain Ruby that generates JavaScript.

David created a shopping cart app on-the-fly and AJAX enabled it as we watched. The AJAXification was quite easy. What wasn't easy was the new programming model that AJAXification introduces (whether done in Rails or not). For example, since the page is not reloading each time, you have to link the various pieces and update them yourself. With one or two AJAX components, it's not bad, but as the number rises, you get a combinatorial explosion of components that might be dependent on each other.

I liked these tutorials because they were soothing. Soothing in the sense that I found myself believing that rich Web-based clients weren't the purview of magicians or teams of programmers, but that this technology could find its way onto the Web--and soon.  

Editorial standards