Is it okay to use Rails 3.1 for a new project? Is hard to convert over?

I have just started using 3.0.7. I am about 2 weeks of development in.

I was wondering if I should keep building for 3.0.7 or switch to 3.1 before I have too much code to port over? I like most of the new features (my only fear is not having good error messages when I use coffeescript), so I'd like to code towards the latest and greatest if it's relatively safe.

The javascript standards look interesting, and the attr_accessible fix sounds like it's very much appreciated.

Is Rails 3.1 compatible with all the gems out there though?

Also, if I go the 3.1 route, is hard or easy to migrate my project towards it? How might one go about that?

I guess this is a lot of mini yet related questions. I'd really appreciate some answers. Thank you.

Well, I got most things to work. I just have to figure out my assets now. I made the folders and organized them. Now it's time to get them to work :wink:

If you see a lot of improvements that you personal would use in 3.1 over 3.0.7, then you should think about switching. Another thing to consider is deadlines, as upgrading will push the moment you are ready to go to production further. You yourself raised a great question: will all the gems work with the new version? If you are using few of them, you should check that out before making the decision. Some projects use 50+ gems and then an incompatible gem can bring considerable slowdown to development. Are you willing to patch the gems/plugins yourself if they aren’t compatible? My personal opinion would be continue with development, and upgrade when the project is on production, because then you’ll be able to focus on 1 task - upgrading, while if you migrate now, you will have to both keep developing the functionality, and solve incompatability problems.

Yay, I got the css to work. I had a circular dependency since I had 2 main stylesheets - one for the public page and for the actual site when a user is signed in. I will need to namespace the styles with Scss so that I can confidently merge them together in one, but for now, I just disabled one of the require statements that includes the whole tree.

Now to work on the javascripts.

All really good points. I am so early in development that upgrading turned out not to be a problem. Everything basically just worked. Sure, I had to remove/add configuration in various places... make a few directories... move some files... etc... but it all just worked.

I think my only big question now concerns the javascript code - where do I put page-specific javascript? Since it all gets put into 1 javascript file, where do I put my code for the individual pages? Or do I not worry about it? That seems a bit odd. Do I no longer need something like require.js?

I'm just a little confused about how to go about this.

Hi again :slight_smile:

Glad it all worked for you. Even if you didn’t migrate right now, it would be a good learning experience (upgrading rails version of production site). So it’s a win win situation basically. Don’t know the answer to your JS problem, maybe somebody else might help on that.

Depending on the kind of site you might want to use mvc views through backbone or something similar and launch specific views depending on the current page, something like so:


body class=´users search_page´

and in your coffeescripts (you do use coffeescript :P)

class UserSearchView extends Backbone.View # or controller

initialize: →

here goes your page specific initializers

$ →

window.currentView = new UserSearchView if $(´’).length > 0

I have never been a huge fan of libs like require.js except for real big web apps, mostly it is better to just dump the whole javascript in one minified file.

My project is probably going to turn out to be one big web app :wink:

I can work with whatever design Rails wants me to go with... I just want to make sure what that is.

So if I were to use backbone (I probably will), what is top those backbone objects from getting instantiated on pages where they aren't needed?

With require.js, I was able to put 1 script_include_tag at the bottom of the page that loaded a javascript file which ignited the rest of the javascript code for that page. It was like a controller, but for javascript basically. This ensured that this controller code would only be executed on this page - and no other.

Now I am at a loss as to how to achieve this without using page- specific pages. I guess I don't need Javascript anymore, but I'm thinking I will still have to remove this line:

//= require_tree .


class UserSearchView extends Backbone.View # or controller   ... initialize: ->    here goes your page specific initializers

$ -> window.currentView = new UserSearchView if $(´').length > 0

This solution looks interesting, and it also looks potentially dangerous. I'm not a fan of string-based rules like this. I guess I can just get used to it (and of course not rely on the body, but perhaps a <div id="user_search"> or something like that.

I will play with it. It might be nice to never have to care to include the script tag at the bottom of page, using require or not.

I guess I am going to blog about this once I have a bit more time.

In general my observation with websites and javascript is that you have lots of code that applies to all pages if you structure it right (usage of class names in css), and very few pages that have intense, page specific code. The project I am working right now has about 1000 lines of coffeescript for the search page and maybe 200 for the rest of the site (and some custom jquery plugins), which makes solutions like the one I proposed rather save. The class is attached to the body because I am following the


I'd love to read it. I will try your way and see how it goes. The more I think about it, the more I like the "if exists on the page, then run it" strategy. I guess this would let you slap elements in and out of pages everywhere and the javascript will just continue to work. Pretty nice.