jQuery Session at RailsConf
I’m happy to announce that my proposal for a Birds of a Feather session about “jQuery on Rails” at RailsConf has been accepted!
If you’re at RailsConf, please come by room c125 on Thursday night at 9:30pm and join in the discussion. I’ll be chatting about my ongoing work on jQuery on Rails, and should have some code to demo if anyone would be interested.
If you’re interested in hearing about how others have solved problems regarding the integration of jQuery with Rails, or just want to share something cool you’ve done, swing on by. See you there!
More Details
Yehuda has just posted more details on how jQuery on Rails works:
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 am waiting for the next version of jQuery before implementation… so forgive the repeated questions. But… when is the growing longer awaited upgrade going to arrive? (I am very interested in using “Interface” but it doesn’t do the drag and drop right in IE for the three stacked columns example. And since my goal is to do a portal with it that is sorta crucial. Works good in FF and even in the browser I wrote with Apollo beta 1. It’s broke in MS IE, go figure. Maybe they cannot afford to build it so it works. Either way… just hopeful that it is very soon.)
Hope this goes well — I won’t be there, but I’ll interested to hear about what you and others have discovered. I’ve posted about my own learnings here: http://mad.ly/2007/05/17/jquery-ajax-rails/
I don’t know if anyone else has discovered this — you can use RJS out-of-the-box to render JQuery Javascript, via the element proxy and its method_missing capability. Examples:
page["#posts"].append render(:partial => ‘post’, :locals => {:post => @post})
#=> $("#posts").append("Post #29 info…");
page["#hide-this"].hide
#=> $(’#hide-this’).hide();
page["#foo"].html("bar").append("baz")
#=> $("#foo").html("bar").append("baz");
page["h1"].add_class "make-red"
#=> $("h1").addClass("make-red");
@geoff: I don’t like to use RJS because it just sends back a chunk of JS to be evaluated on the client-side, which separates you from the page context. Callbacks retain the page context (giving you access to all sorts of useful information), and will produce shorter, tighter, and more maintainable code.
jQuery on Rails focuses on allowing you to keep your jQuery code modular while allowing you to push a single file to the client and leverage caching as appropriate. What I’ll be demoing at RailsConf is really a proof-of-concept; I’ll be adding better caching options and packing in the next few days before the (big? small?) release.
To reiterate, this release will target jQuery developers who want an easier time using Rails and jQuery together. It does not provide “helpers” or allow you to code in pure-ruby and forget about JS. If you don’t want to write any JavaScript, I’m not convinced jQuery is for you in the first place.
Agreed, returning a glob of Javascript code to evaluate on the client is kind of messy; I would gladly embrace a cleaner approach.
JQuery on Rails sounds promising — excited to see it!
please excuse my ignorance, but what is the benefit of tightly binding the application to the client? All the work I have done since XHR became widely accepted has moved the opposite direction. If there is a common data interchange (xml or json) then the choice of application technology and display technology can be made independently. It has been my impression that this is a good thing.
What am I missing?
-wade
@wade: the approach I described, from the server-side perspective, decouples the client from the server. The “rails way” is to send client-side code from the server back to the client. The jQuery way is to send JSON back.
jQuery simply provides a client-side implementation for the JSON data that is sent back.