Yehuda Katz is a member of the Ember.js, Ruby on Rails and jQuery Core Teams; he spends his daytime hours at the startup he founded, Tilde Inc.. Yehuda is co-author of best-selling jQuery in Action and Rails 3 in Action. He spends most of his time hacking on open source—his main projects, like Thor, Handlebars and Janus—or traveling the world doing evangelism work. He can be found on Twitter as @wycats and on Github.

jQuery on Rails: A Fresh Approach

My apologies for dropping off the face of the earth. I’ve been working hard at Procore, which I mentioned last time, and getting neck-deep in the specific problems that make working with jQuery and Rails at the same time so difficult.

Since I last publicly discussed jQuery on Rails, I’ve gone down a lot of avenues, and written a lot of code, and came to some conclusions:

  • jQuery and Unobtrusive JavaScript are fundamentally incompatible with an attempt to describe behavior inside markup, as Rails does via “JavaScript helpers.”
  • Attempts to fix the problem, specifically UJS for Rails, still require that you include your JS behaviors in your views, which are then marshalled into JavaScript files on the fly (and cached as appropriate). If you wanted to include the same JS behavior in multiple pages, you’d need to create custom helpers and call out to them.
  • jQuery is already the perfect mechanism for unobtrusive JavaScript, baked right into the library
  • The biggest problem faced by jQuery developers is not simplicity (which, again, you get for free in the library), but difficulty in including the correct jQuery “modules” in the Rails views that require them.

The most common problem with using jQuery with Rails in an app of moderate or higher complexity is the trade-off between including everything in a single application.js (which can lead to serious slowdowns in larger apps) and having multiple, modular files (which are a serious pain to include correctly as needed).

This is a problem for jQuery users who want to use Rails more than Rails users who are used to Prototype helpers and want to be able to use the jQuery library as a drop-in replacement. In the first release of jQuery on Rails, I will be targeting jQuery developers who want to work with Rails. In other words, jQuery on Rails is for you if you know jQuery or are willing to use jQuery.

This release of jQuery is not for you if you don’t want to learn jQuery, and want to program purely in Ruby. There will be a future release that will include some features for pure-Ruby developers, but I maintain that Unobtrusive JavaScript is fundamentally incompatible with that mode of thinking.

With all that said, what does jQuery on Rails actually do?

First up, it’s a Rails plugin, which you activate by adding <%= include_jquery %> in your application.rhtml. When your server is started, it’ll parse all of your JavaScript files, and identify selectors in those files. When include_jquery is called in your layout, it’ll get the rendered HTML and use Hpricot (which shares syntax with jQuery) to determine whether any instances of the selectors identified on server startup are present.

The JavaScript files that have selectors that are also present in your HTML will be loaded, and run as expected.

So in short:

  • Create your JavaScript files, using selectors as usual
  • Use include_jquery in your layout
  • You’re done

I’ll be demoing the code at RailsConf tonight and should be releasing the first beta version sometime in the next week. If you’re at RailsConf, check out the Birds of a Feather presentation at Room c122 at 9:30 pm tonight.

6 Responses to “jQuery on Rails: A Fresh Approach”

i don’t quite understand what this does ?

would you mind explaining in a bit more detail the point of this ?

weepy

whats going on with jquery on rails? no news?

jQuery on rails is the same slow as in the php?

Leave a Reply

Archives

Categories

Meta