Yehuda Katz is a member of the Ember.js, Ruby on Rails and jQuery Core Teams; his 9-to-5 home is at the startup he founded, Tilde Inc.. There he works on Skylight, the smart profiler for Rails, and does Ember.js consulting. He is best known for his open source work, which also includes Thor and Handlebars. He travels the world doing open source evangelism and web standards work.

RailsConf Talk Recap

There was a great turnout at the jQuery talk at RailsConf yesterday (packed house!), mostly not jQuery users, but hungry for an alternative to Prototype.

At the session, I explained what I thought were some seminal differences about the way jQuery works as opposed to using built-in helpers:

  • jQuery prefers passing *data* — not code. In other words, a jQuery-friendly action will pass back JSON data, to be processed by a jQuery callback, while RJS (Rails’ preferred method), sends back code to be executed by the client. Sending back data makes for a skinnier pipe needed to accomplish the same thing
  • Unobtrusive thinking is incompatible with Rails helpers that are dumped in the middle of views. Even going the UJS4Rails route, requiring code to be inserted in the views that they refer to violates unobtrusive principles and mashes together behavior and content (even though the CLIENT sees the code separately, UJS is a design philosophy, not a compile-time philosophy).
  • Using server-side JavaScript (RJS) leads to a reliance on the server to maintain state (or at least, a reliance on the server to tell the client what to do), but many RJS’ers end up making extra trips to the server to compensate for their lack of client-side code
  • Rails works exactly the same as any other server-side framework from the perspective of the client. From that perspective, requests are made of the server (via Ajax) and responses are returned. Rails can make returning responses saner via respond_to and to_json but it’s fundamentally a communication that can be easily understood in a server-framework-agnostic way.
  • Last but not least, it’s worth your time to learn JavaScript even if you’ve been putting it off. Learning the basics of jQuery shouldn’t take more than an hour, but it’ll be an hour that’ll free you from having to worry about how someone else implemented a JavaScript helper and bring you closer to a saner design philosophy
  • Again, I’m really happy about the turnout at the session and I hope to be posting more about Rails as well as the release of jQuery on Rails real soon :).

    11 Responses to “RailsConf Talk Recap”

    Yehuda — it was nice meeting you yesterday at the BOF. Hope to see more jQuery + Rails stuff in the future.

    Sounds like it went well, Yehuda. Wish I could’ve been there to check it out.

    This is exiting stuff. I have been eagerly waiting your brilliant initiative with JQuery support. Was not at Railsconf in US but hopefully you (or somebody else) could make a similar presentation at Railsconf Berlin in September.

    Did I oversee you posting the URL for the plugin? Can’t find it. Please point me to that URL.

    Also please keep us updated on any progress and limitations. Thanks!


    I should be posting a URL tonight or sometime tomorrow. I hope you enjoy!

    Great thanks! I’m looking forward

    The main problem i come across with jquery is simply having to invent my own helpers. Most of the prototype helpers are pretty much useless even if converted to work with Jquery becuase of the unobtrustive approach.

    You mention that a big problem is with the complexity around inclusion. Im not sure I agree here, since it’s simple to use a asset caching plugin or similar. Rails 2.0 in fact comes with a :cache => true baked into the javascript include.

    That said Im still very much interested to see what you have come up with.

    This link has a v interesting approach :

    @weepy: What type of helpers in particular have you had to invent. I’m strongly considering writing helpers to hook into common jQuery plugins, plus a library to activate the plugins via markup (like a helper and corresponding JS function for turning forms into Ajax forms via the form.js plugin).

    I’m exploring the path of completely ababonding AJAX related helpers, remote_form_for and RJS and really liking it so far.

    With JQuery or behaviour.js, it’s easy to setup events on your page elements. And with the MinusMOR plugin, you can just write real javascript to respond to these events, instead of rails generated JS.

    wycats – it’s mostly been doing ajax form stuff – some of the jquery plugins have been v useful so far.

    i think in general if u do jquery, you don’t tend to do things the RJS way. though it would be good if someone came up with a better way of thinking about it since i seem to keep reinventing the wheel :)

    weepy: if you look at the latest release of jQoR, you’ll see that I’ve started creating some proof-of-concept helpers for sortable tables and tabs. Next up will be ajaxForm helpers; take a look at the implementations and see if you can grok what’s going on.

    Excellent web site I will be visiting often.

    Leave a Reply