Bill Burcham’s memeRocket

I’m upgrading a project from Rails 2.0.2 to Rails 2.1.

This thing uses Comatose 0.8.1. Unfortunately, Comatose 0.8.1 isn’t compatible with Rails 2.1. Fine, I’ll just upgrade to Comatose 2.0 (uber-alpha) and that’ll work. Oops, Comatose 2.0 uber-alpha breaks Rails migrations. Fixing that breakage requires a patch to Rails itself.

Oh and did I mention that this project of mine also requires a patch to Comatose proper (adds before_filters to the Comatose configuration object).

So I need a patched version of Comatose and a patched version of Rails. “OK” you say, just use Piston to manage those vendor branches. Not so fast. Piston only works with Subversion and the Rails project is no longer hosted on a Subversion repository. The old repository was deprecated after Rails 2.0.2. Rails is now hosted on Github. Oh and so is Comatose.

Never fear, Github support for Piston is coming Real Soon Now™. Until then I’m stuck in limbo. I suppose I’ll do the manual vendor branch thing—essentially manage my own private Subversion repositories for Rails and Comatose.

The fact that François Beausoleil is implementing Piston support for all-Git projects leads me to believe that there is no convenient alternative (to Piston) for vendor branches in Git. Hum, that’s hard to believe. Anyhow, I can’t migrate this project to Git yet so all-Git alternatives are sort of moot.

A few weeks ago I wrote about Unobtrusive JavaScript using the Prototype versus JQuery stacks. In that post I came down on the side of the JQuery stack. Something I didn’t analyze at the time, was: is it possible to use a little of each? For instance, say (hypothetically) that you have a big old Rails project that uses RJS all over the place and you’d like to continue using RJS — is there a way to leverage pieces of JQuery in that scenario.

In this pursuit I learned a few things. Firstly, plain old JQuery does not “do” UJS in the following sense: if you bind a behavior to an element (via a CSS selector), that binding will not be reapplied as the DOM is manipulated. For dynamic binding, or “live” binding that gets re-applied after every DOM update, you need Brandon Aaron’s livequery plugin for JQuery. Livequery is to JQuery as Dan Webb’s Low Pro is to Prototype — kind of. Difference being that livequery hooks each of JQuery’s DOM manipulation routines, whereas Low Pro hooks each of Prototype’s Ajax.Responders “onComplete” event — the event that happens when an XHR is complete.

What all this means is that you can use JQuery’s UJS (livequery) if you use JQuery for all your DOM manipulations, or you can use Prototypes UJS (Low Pro) if you use Prototype for all your Ajax calls. The unfortunate bit is that you cannot (yet) use livequery with Prototype Ajax calls, or Low Pro with JQuery DOM manipulations. Can’t we all just get along?

I wonder if a UJS package could remain stack agnostic. I think livequery is on to something by hooking DOM manipulation routines. That seems more robust (if potentially less performant) than hooking the Ajax returns. By hooking DOM manipulation it seems that you’ve plugged more holes and have a more general-purpose solution. Could the livequery approach (of watching for DOM manipulation) be done in a stack-agnostic fashion rather than by hooking JQuery routines? If we could do that then we’d have a UJS package we could use no matter which JavaScript base library we choose — or perhaps whichever library chooses us.

I am accustomed to using Unobtrusive JavaScript (UJS) in my apps. UJS dynamically adds event handlers to the DOM. These event handers implement behaviors via DOM manipulations and XMLHttpRequests (XHR’s). This approach is in contrast to the historical approach of specifying event handlers on HTML elements directly. The value of the UJS approach are:

• it separates behavior (JavaScript) from markup (HTML) and this is good for the same reasons separating style (CSS) from markup is good
• it can reduce page weight

I had been using ujs4rails but that thing is being deprecated so it isn’t an option for me. If I want to do UJS I can either use Prototype or JQuery. I don’t know of any other good options.

I’m using JQuery a bit now. Pretty light use: a highlight effect here, a show/hide toggle there; some AJAX form submission. In thinking about how to proceed I’m kind of torn. I don’t want to use both JQuery and Prototype longer term. For starters, that’s too much mental baggage to carry around — one must gain fluency in one or ‘tother I think. Also it’s a lot of page weight to load both libraries.

Another dimension is RJS vs. POJS. RJS is Rails’ templating and API that lets you generate JavaScript from Ruby. POJS is “Plain Old JavaScript”. If we do RJS then we almost have to stay on the Prototype stack. But with POJS a guy could go with either stack and in fact I think the scale tips to the JQuery stack for POJS as I’ll show in a sec.

So here’s how I see the top two options:

RJS: Prototype + Scriptaculous + RJS + Dan Webb’s Lowpro:
+ Lowpro supports UJS
+ most of us have used prototype + scriptaculous and are somewhat comfortable with it
+ native Rails (RJS) support
- Lowpro is not as well documented (nor as widely used) as JQuery for UJS
- I see no centralized library of plugins (other than Scriptaculous itself) for this stack

POJS: JQuery + MinusMOR:
+ it supports UJS out of the box in a pretty clean way
+ people I respect seem to be moving to JQuery
+ there is a large library of plugins including autocompleters and flash upload progress indicators
- very little native Rails (RJS) support — you can do some things but it’s hard to know exactly what will work
- if you already know scriptaculous effects, you have to learn new effects

A big part of this decision hinges on the value of RJS. After using Rails RJS templates for a year and a half or so my conclusion is that they are more trouble than they are worth. Many believe RJS is easier to write/maintain that POJS — especially for a Ruby programmer. I believe RJS is actually a false economy. In real applications you really have to code in real JavaScript.

An RJS template generates JavaScript from Ruby code — but that Ruby API is insufficiently documented (in particular with regard to the scriptaculous effects) and insufficiently capable (e.g. there is no easy way to update DOM elements matching a CSS selector through that API). Essentially a guy can waste a lot of time trying to get RJS to work for anything but the simplest demos. So I lean toward plain-old JavaScript (POJS) instead.

I wonder what you think. Do you place higher value on RJS for real applications? Have you found an alternate stack, or perhaps a different combination of stack elements? Must I pick one stack or the other, or is it possible and profitable to use both at once?