Home/ Questions/Q 1066631
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-16T20:02:40+00:00

I have worked on two projects using Ajax and Ruby. In one project, I

  • 0

I have worked on two projects using Ajax and Ruby. In one project, I used Rails Prototype helpers and RJS. In the other project I used HAML and unobtrusive Javascript with jQuery. Each had a learning curve which I have overcome. However, the long-term costs and benefits of either approach are not clear. For my next project I am trying to decide between:

  1. Rails + HAML + jRails + jQuery
  2. Rails + HAML + unobtrusive jQuery

The trend in Rails, especially Rails 3.0, seems to be towards using unobtrusive Javascript, but it is not clear to me why this is better, especially when you get so many useful helpers (such as remote_form_for) from Rails/jRails. In trying to make this decision, I have the following questions:

  1. Which approach leads to less code to achieve the same amount of functionality?
  2. Which approach is less error-prone?
  3. Which approach is easier to test?
  4. Which approach is easier to read, maintain, and evolve?
  5. Which approach lets you more easily degrade your web application gracefully (by providing the same functionality without Ajax) when Javascript is disabled in the client browser?

I appreciate any help or insight you can provide.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I have a few answers to your questions – at least from my point of view. Answers to questions like this really are dependent on your experience and preferences.

    1) I would say that unobtrusive JavaScript is going to lead to less code overall especially if you are reusing the JavaScript methods.

    2 & 3) I’m going to go with unobtrusive JavaScript for both of these. When the JavaScript is decoupled from the page structure you have a better idea of what that specific piece of code does and can test it as well as know that you have tests for those methods. Mixed code is generally (in my experience) much more difficult to get good test coverage. This will help keep code less error-prone.

    One issue with decoupled js is if you remove a feature you may leave code behind or remove dependent code. Of course this is why you should have automated tests and good coverage.

    4) I think inline js is easier to understand because it is all right there however anything over one line and you are already reducing readability so you might as well just go unobtrusive all the way for the other benefits. Unobtrusive js also makes it much easier to maintain and document for other team members.

    5) In my experience this a wash. You have to provide extra methods either way.

    As an end note, I agree that Rails 3 also provides much better support for unobtrusive js and I view it as a best practice. I just started fixing up an old application for a client and with the mixed views of html, js, logic, it is really a pain to grasp what they are trying to accomplish. If things were separated it would be much easier to take in.

    I hope this helps.

    • 0