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.

What’s Up With All These Changes in Rails?

Yesterday, there was a blog post entitled “What the Hell is Happening to Rails” that stayed at the number one spot on Hacker News for quite a while. The post and many (but not most) the comments on the post reflect deep-seated concern about the recent direction of Rails. Others have addressed the core question about change in the framework, but I’d like to address questions about specific changes that came up in the post and comments.

The intent of this post is not to nitpick the specific arguments that were made, or to address the larger question of how much change is appropriate in the framework, but rather to provide some background on some of the changes that have been made since Rails 2.3 and to explain why we made them.

Block Helpers

I too get a feeling of “change for the sake of change” from Rails at times. That’s obviously not something they’re doing, as all the changes have some motivation, but at times it feels a bit like churn.
At one point in time, you did forms like <%= form …. and then they switched to <% form …. do and now they’ve switched back to <%= form … do again.
Also, the upgrade to Rails 3 is not an easy one. Yeah, you get some nice stuff, but because it’s so painful, it’s not happening for a lot of people, which is causing more problems.

Prior to Rails 3.0, Rails never used <= form_for because it was technically very difficult to make it work. I wrote a post about it in Summer 2009 that walked through the technical problems. The short version is that every ERB template is compiled into a Ruby method, and reliably converting &lt%= with blocks proved to be extremely complicated.

However, knowing when to use <% and when to use <= caused major issues for new developers, and it was a major 3.0 priority to make this work. In addition, because of the backwards compatibility issue, we went to extreme Ruby-exploiting lengths to enable deprecation warnings about the change, so that we could fix the issue for new apps, but also not break old apps.

The night José and I figured out how to do this (the Engine Yard party at Mountain West RubyConf 2009), we were pretty close to coming to the conclusion that it couldn’t be done short of using a full language parser in ERB, which should give you some sense of how vexing a problem it was for us.

Performance

The general disregard for improving performance, inherited from Ruby, is also something endemic from a while back.

Yes, there have been some performance regressions in Rails 3.0. However, the idea that the Rails core team doesn’t care about performance, and neither does the Ruby team doesn’t pass the smell test.

Aaron Patterson, the newest core team member, worked full time for almost a year to get the new ActiveRecord backend into decent performance shape. Totally new code often comes with some performance regressions, and the changes to ActiveRecord were important and a long-time coming. Many of us didn’t see the magnitude of the initial problem until it was too late for 3.0, but we take the problem extremely seriously.

Ruby core (“MRI”) itself has sunk an enormous amount of time into performance improvements in Ruby 1.9, going so far as to completely rewrite the core VM from scratch. This resulted in significant performance improvements, and the Ruby team continues to work on improvements to performance and to core systems like the garbage collector.

The Ruby C API poses some long-term problems for the upper-bound of Ruby performance improvements, but the JRuby and Rubinius projects are showing how you can use Ruby C extensions inside a state-of-the-art virtual machine. Indeed, the JRuby and Rubinius projects show that the Ruby community both cares about, and is willing to invest significant energy into improving the performance of Ruby.

Heroku and the Asset Pipeline

The assets pipeline feels horrible, it’s really slow. I upgraded to Rails 3.1rc, realized it fights with Heroku unless upgrading to the Cedar stack

The problem with Heroku is that the default Gemfile that comes with Rails 3.1 currently requires a JavaScript runtime to boot, even in production. This is clearly wrong and will be fixed posthaste. Requiring Rails apps to have node or a compiled v8 in production is an unacceptable burden.

On the flip side, the execjs gem, which manages compiling CoffeeScript (and more importantly minifying your JavaScript), is actually a pretty smart piece of work. It turns out that both Mac OSX and Windows ship with usable JavaScript binaries, so in development, most Rails users will already have a JavaScript library ready to use.

It’s worth noting that a JavaScript engine is needed to run “uglify.js”, the most popular and most effective JavaScript minifier. It is best practice to minify your JavaScript before deployment, so you can feel free to format and comment your code as you like without effecting the payload. You can learn more about minification in this excellent post by Steve Souders from a few years back. Rails adding minification by default is an unambiguous improvement in the workflow of Rails applications, because it makes it easy (almost invisible) to do something that everyone should be doing, but which has previously been something of a pain.

Again, making node a dependency in production is clearly wrong, and will be removed before the final release.

Change for Change’s Sake

The problem with Rails is not the pace of change so much as the wild changes of direction it takes, sometimes introducing serious performance degradations into official releases. Sometimes it’s hard to see a guiding core philosophy other than the fact they want to be on the shiny edge

When Rails shipped, it came with a number of defaults:

  • ActiveRecord
  • Test::Unit
  • ERB
  • Prototype

Since 2004, alternatives to all of those options have been created, and in many cases (Rspec, jQuery, Haml) have become somewhat popular. Rails 3.0 made no changes to the defaults, despite much clamoring for a change from Prototype to jQuery. Rails 3.1 changed to jQuery only when it became overwhelmingly clear that jQuery was the de facto standard on the web.

As someone who has sat in on many discussions about changing defaults, I can tell you that defaults in Rails are not changed lightly, and certainly not “to be on the shiny edge.” In fact, I think that Rails is more conservative than most would expect in changing defaults.

Right, but the problem is that there doesn’t seem to be a ‘right’ way, That’s the problem.

We were all prototype a few years ago, now it jquery … we (well I) hadn’t heard of coffeescript till a few months ago and now its a default option in rails, The way we were constructing ActiveRecord finders had been set all through Rails 2, now we’ve changed it, the way we dealt with gems was set all through rails 2 now its changed completely in Rails 3.

I like change, I like staying on the cutting edge of web technologies, but I don’t want to learn something, only to discard it and re-do it completely to bring it up to date with a new way of doing things all the time.

First, jQuery has become the de facto standard on the web. As I said earlier, Rails resisted making this change in 3.0, despite a lot of popular demand, and the change to jQuery is actually an example of the stability of Rails’ default choices over time, rather than the opposite.

Changes to gem handling evolved as the Rails community evolved to use gems more. In Rails 1, all extensions were implemented as plugins that got pulled out of svn and dumped into your project. This didn’t allow for versioning or dependencies, so Rails 2 introduced first-class support for Rails plugins as gems.

During the Rails 2 series, Rails added a dependency on Rack, which caused serious problems when Rails was used with other gems that rely on Rack, due to the way that raw Rubygems handles dependency activation. Because Rails 3 uses gem dependencies more extensively, we spent a year building bundler, which adds per-application dependency resolution to Rubygems. This was simply the natural evolution of the way that Rails has used dependencies over time.

The addition of CoffeeScript is interesting, because it’s a pretty young technology, but it’s also not really different from shipping a new template handler. When you create a new Rails app, the JavaScript file is a regular JS file, and the asset compilation and dependency support does not require CoffeeScript. Shipping CoffeeScript is basically like shipping Builder: should you want it, it’s there for you. Since we want to support minification out of the box anyway, CoffeeScript doesn’t add any new requirements. And since it’s just there in the default Gemfile, as opposed to included in Rails proper like Builder, turning it off (if you really want to) is as simple as removing a line in your Gemfile. Nothing scary here.

ActiveRecord Changes

The way we were constructing ActiveRecord finders had been set all through Rails 2, now we’ve changed it

The Rails core team does seem to treat the project as if it’s a personal playground

One of the biggest problems with ActiveRecord was the way it internally used Strings to represent queries. This meant that changes to queries often required gsubing String to make simple changes. Internally, it was a mess, and it expressed itself in the public API in how conditions were generated, and more importantly how named scopes were created.

One goal of the improvements in Rails 3 was to get rid of the ad-hoc query generation in Rails 2 and replace it with something better. ActiveRelation, this library, was literally multiple years in the making, and a large amount of the energy in the Rails 3.0 process was spent on integrating ActiveRelation.

From a user-facing perspective, we wanted to unify all of the different ways that queries were made. This means that scopes, class methods, and one-time-use queries all use the same API. As in the <= case, a significant amount of effort was spent on backwards compatibility with Rails 2.3. In fact, we decided to hold onto support for the old API as least as long as Rails 3.2, in order to soften the community transition to the new API.

In general, we were quite careful about backwards compatibility in Rails 3.0, and while a project as complex as Rails was not going to be perfect in this regard, characterizing the way we handled this as “irresponsible” or “playground” disregards the tremendous amount of work and gymnastics that the core team and community contributors put into supporting Rails 2.3 APIs across the entire codebase when changes were made.

49 Responses to “What’s Up With All These Changes in Rails?”

Patient and reasonable response to a combative, poorly argued rant. Well played.

I haven’t played with Rails 3.1 yet, but moving from 2.X to 3.0 was an unambiguous improvement in many ways. There are only a few huge upgrades (Bundler is the one that comes to mind), but the entire stack just feels cleaner, easier to deal with and integrate with, and more flexible.

The downside of continuous improvement is that it requires continuous change, and we’re at a point in technology where it is almost impossible to keep up with everything at once. I have to wonder how much the complaints are coming from a dissatisfaction with Rails in particular but more a general frustration with the need to be continually learning new technology.

I for one would prefer a constantly improving framework than having to keep learning new frameworks to improve my productivity, but I wonder what the distribution of opinions is on that tradeoff

thanks yehuda, well said <3 <3

Funny, I feel the opposite:

Rails releases such nice new features, it can be frustrating sometimes if your project is still using 3.0.x instead of 3.1, even though your sanity says you shouldn’t be running beta versions in production ;)

I really love how Rails Team do the changes, they make people know better ways to do the things. The problem is there are a lot of lazy people around there, sitting in their confort zone, that don’t want know new things. Keep improving Rails Team, keep on the edge, this is how you get where you are now, and this is how I mean you should keep doing, this is the most awesome part of Rails Team and Ruby culture around there. And thanks for all the great efforts to make this framework always better.

Other than the Asset Pipeline in Production issue, I’m loving Rails 3.1. With this fixed, I’ll be a happy camper again, and the Asset Pipeline is the right way to go.

The lack of actual documentation for the Asset Pipeline really didn’t help with the transition either. Any time a big change is provided, the documentation for how to use it needs to be available. Watching DHH’s talk 15 times to see how it works isn’t the best way to document a new feature

Thanks for clarifying these issues Yahuda.

ps. I like CoffeeScript too!

I think that there might be a point that’s being overlooked here. Rather than just seeing incorrect criticisms of Rails, I think we all need to see these as uninformed criticisms.

I think that this is worth looking closer at. The Rails community (like all communities) is like an onion. I think it’s very easy to be so focused on coding that you/we/they overlook the importance of communication to not just the inner layers of the onion, but all the way to the outer layers of the onion.

I don’t think the take-away here is to slow the development of Rails, but to improve the ratio between changes and communication of those changes and the thinking behind them. And I think this is a valuable lesson to learn right now.

I believe that Rails *does* sacrifice something in terms of stability compared to other projects, but that is also what allows Rails to be a industry-leading framework 7 years in. If you are a developer stuck supporting a lot of old Rails 1.x and 2.x projects with no budget, then absolutely you will feel the pain of upgrading and marginal legacy support that you wouldn’t necessarily feel had you gone with a more venerable Java stack (for instance). That said, if you are actively building an application over several years then the forward development of Rails means greater productivity and functionality on an ongoing basis rather than being stuck with an outdated framework.

My current project is over 4 years old, started in the Rails 1.2 era, 100+ models, 30+ gems, 50k LOC, and I can vouch for the pain that the Rails 3 upgrade caused. That said, the upgrade gave us a lot of immediate benefits: the rails_xss upgrade forced us to close a number of small XSS holes that we probably never would have found otherwise, the Bundler upgrade solved several real-world deployment issues that led to downtime over the years, ActiveRecord 3 allowed us to clean up a ton of hairy querying code we had written with its fantastic composability and laziness, the modularity and instrumentation allowed massive logging and generator improvements to be inline with project standards, the ActionMailer API allowed us to significantly DRY up our extensive email notification suite.

In short, Rails development is still definitely heading in the right direction for my organization. There’s no doubt that API stability is better in many other frameworks, but as Yehuda points out here, the changes made in Rails are done for good reason that can benefit a lot of people. If stability is more important than agility for your project (without disparagement), then Rails is probably the wrong choice (I tend to use PHP in those cases).

An upgrade from 2.3 -> 3.0.x is going to be somewhat painful for existing applications. This developer seems to be overlooking the fact that some of the defaults have changed, but they are relatively easy to disable (or change back).

As a Merb refugee, I’m happy Rails 3.0 came along because it’s become much more flexible (something I’ve come to expect after using Merb). So I don’t necessarily need to follow the defaults unlike with rails 2.3

Yikes! I was the one who implied Rails sometimes seems like a “personal playground” — but I meant no disrespect or to be taken especially seriously. What I meant was that the reasoning behind the changes is often opaque, even though they do improve Rails. Communication about the Whys has done a world of good. (And who knew I was going to be quoted by The Yehuda Katz?)

Yehuda: What ReinH said. Way to keep it civil!

I appreciate the post Yehuda and am a huge fan, you used my comments as teeing off points for your remarks but I feel that what I was trying to say has been lost in his response, probably because I was unclear.

Lets start with this …

“The Rails core team does seem to treat the project as if it’s a personal playground”

This was said more in frustration with the coffeescript/sass decision than any real belief that it really was the case.
I understand it may be hurtful and disparaging of the amazing effort that the Rails core team has dedicated to making Rails fantastic, and I apologize unreservedly.

With respect to outlining the changes (prototype to jquery etc), I was not complaining about the changes per se (because I like most of them), what I was complaining about is the pacing of the changes.
Something as major as the asset pipelining feature (where you move assets out of the public folder and change the way css and js served up), for example, seems big enough that it should be a 3.2 release not the next release after an already major change in 3.0.

That is all I was trying to say, albeit, clumsily.

I haven’t worked on the Rails core, so this can be taken with a pinch of salt, but I feel like it would be a good idea to adopt the Intel tick tock refresh style of cpu releases http://en.wikipedia.org/wiki/Intel_Tick-Tock, where major releases come out on the ‘tock’ and are refined on the ‘tick’. That would work well for Rails releases, giving major releases enough time to settle into the Rails consciousness before the next set of changes comes down.

It was great to get a thorough explanation of the rationalization behind the decisions that have been made recently, it would be awesome to see that increase in frequency. I learn so much from each one of these kind of posts.

Finally, I just want to thank the Rails team for all the hard work and have them understand that while I may argue hard for what I believe, that I have nothing but the absolute highest regard for them, in fact I hope to be like them some day.

pwned, can we all stop bitching now?

Decided to rewrite everything from scratch when upgrading rails 2.3 app to 3.1, because of so many new great things in latest releases. Overall I love rails 3.1, don’t understand all those concerns about the recent direction of Rails, seems like DHH made it clear at the conf.

Thanks for clearing all this up. I saw DHH’s keynote but did not learn much (except for how great he thinks he is).

Yehuda,

Great to see this solid response to the critics. Thanks!

Also good to see that the Rails core team shares my distaste for strings in SQL. Now, about getting Squeel merged… ;)

Wow, thanks for such a detailed and reasonable response to a Rails hate article. I personally see this behavior as one of the greatest assets of the Ruby/Rails community. Thanks!

Regarding Rails, I also felt that Rails changed a lot and too much in a short period of time. That said with Rails 3.x coming, it all makes sense and Rails (although it was just renewed) feels more mature. E.g. when you read Jose Valims book, you can clearly see that Rails has well thought APIs and structure now.

Thanks for your post. Over all those why-Sass-and-not-Haml debates it’s easy to forget how much thought and effort were put into every single version of Rails. I really can’t imagine developing without i. E. Bundler and ActiveRelation any more.

I helped put together a lot of the Rails 2 gem handling stuff, and anybody who’s bemoaning *that* mess going away probably never really used it – there were major, nasty gotchas that were basically un-fixable in the 2.x approach: circular dependencies, weird behavior with some gems that got loaded early (the fast_xs stuff was notorious for this), script/generate not finding gems, etc. It worked for probably 95% of use cases, but succumbed to utter fail past that. HUGE props to the Bundler team for building something far better.

I do have one quibble with the “OMG RAILS KEEPS CHANGING” folks, though – it’s really pretty amazing how much *hasn’t* changed over the years. I recently had to dig into some old 1.x apps and, while there were certainly some rough spots, tons of stuff that I tried with the expectation of getting NoMethodError and friends was already there…

Thanks yehuda, I needed that.
People, honestly stop bitching because you can’t stay with the times.

I like rails3.1, especially the feature of pipeline. The change to block helpers doesn’t make any sense to me as many have got used to the usual way. Change to this means nothing. If rails still uses prototype, there were many complaining why not use jquery. The fade of prototype is inevitable. The switch is in place a little later.

Pipeline and CoffeeScript are wonderful, same as the Sass. In fact, unless I read these three features, I would not come back to continue learn rail3.1. Yes, I simply keep an eye at rails3, but never use it or learn it seriously. Rails3.0 is an upgrade for itself, and becomes more rational. There is no sugar with Rail3.0. But Rails3.1 is too great to resist to learn and use. I love Rails3.1.

In general, I do like the fact that Rails is constantly improving and evolving and I think the core team does a fantastic job in balancing change, stability, and backward compatibility. Maybe I haven’t heard of coffeescript or don’t like its syntax, but perhaps after taking a closer look (since it is the recommended way in Rails) I’ll find it useful. Either way, I appreciate the ease with which I can choose to use it or loose it.

The one point in the original post I do agree with is performance. Don’t get me wrong, I do appreciate all the work by Aaron and the rest, but I think Rails tends to lag in this respect. This is especially true when it comes to large applications (say 50+ gems, 150+ models). At these sizes, little slower start-up times are much more felt, little memory issues turn into big headaches, and etc.

I guess I’d be interested in how you speak to the added default deps since you used to be a supporter of the Merb project which prided itself on starting as a more bare-bones platform.

Yehuda, your combination of brilliance, forthrightness, and immense contribution to Rails is deeply appreciated. Thank you!

Nice reasoning. Before reading this article, I was in a very bad opinion about recent changes to Rails. Now I feel good about Rails Core team members, Core contributors and others in rails community!

One question though: You said that Rails team discusses a lot before making things default, to take care of Backwards Compatibility and other issues. Where do you guys hangout and have discussions like this? I want to follow them.

If the community is clearly made aware of these ongoing discussions, I guess these rants on changes, could have been avoided.

Hat off, all of you have done an enormous amount of work to make things better and I appreciate it. Thanks and keep up the awesome work!

Is there any guide for migrating from 3.0.x to 3.1?

I think the progression is great, but sometimes it’s a little frustrating trying to keep up.

I suspect that people such as @”Justin Baker” have never worked in a PCI compliant environment and are ignorant to the long winded change request process in place that makes it difficult and slow to make changes to any application or system.

@wycats: well played.

@trustfundbaby: Intel never used semantic versioning. They don’t even release their stuff as open source. The linux kernel would have been a better example (odd vs. even minor versions), but this way is not the true and only. Anyways, most of my rails 3.0 code could have been migrated to 3.1rc with slight modifications. I’m not talking about migrating to the new features, because their optional nature, but just to make them working. What else do you need from an upgrade? Sure, don’t use it in production yet.

You shouldn’t waste your time replying to this. Haters will always hate.
But great article anyway :)

Wow I must have missed the initial debate. 0_o Good thing, I would never go back to Rails 2.3 at this point. Just ported an old Rails 2.3.2 app to Rails 3 and that took days because of some 3rd party plugins that was not maintained anymore – otherwise it was a breeze. The only thing to complain about is the Rails 3.1 vs Compass was not taken into account as so many rely on Compass and it seems it was not compatible with new asset pipeline, but it seems it’s fixed now. One tiny miscommunication-mistake, otherwise I’m impressed so much new things didn’t mess things up even more. B)

Thanks a lot yehuda for posting this. I am working my way through Rails´s codebase at the moment and think that it´s really clean and solid and therefore future proof. Rails has really made a step forward in evolution!! Evolution implies change! All in all I think Rails is heading in the right direction to supply a more stable API in future releases.

People will always complain about change. When you start using Rails or any other agile framework for that matter you should adopt change as a good thing. Rails is NOT the same tool today that is was at version 1. In my personal opinion that is a very good thing. It has grown, the community around it has grown, and it has become a great pleasure to work with in developing applications.

Using rails is already a departure from the way most people build websites. It is not for those that want to do things the same old way. It IS for those that want a better way. Maybe those who can’t keep up with continued evolution should check out the Zend framework, or some other such PHP nonsense.

In general, I agree with the reasoning behind most of the changes in 3.0 and 3.1. I have myself just suffered through a painful upgrade of a site from 2.3 to 3.0. But the real problems turned out to be not with Rails 3 itself, but with certain gems that behaved in a non-standard fashion or were poorly documented.

However, I think the issue of the pace of change has been give short shrift here, when it should be taken more seriously. It is a real issue, and pooh-poohing it won’t make it go away.

Just as an example, many of you may remember when Microsoft was putting out significant upgrades to its products (including Windows… not version changes but significant and game-changing updates) on the order of every few months. This caused so much developer frustration and so many user complaints that Microsoft publicly pledged to reduce the number of major changes to about once a year at most. While the significant changes still got made, they got made a lot less frequently, and that eliminated a lot of scrambling to constantly upgrade and re-learn on the part of their customers. The result was a win-win: developers and end users had their frustration levels reduced quite a bit, and Microsoft’s costs were actually cut down somewhat because they were making less frequent releases… but all the same features still got released.

I think the Rails team could learn something from this. I realize that the official 3.0 release is about a year old now, so 3.1 is not necessarily premature, but it is pushing a bit. How long until 3.2? There should NEVER be less than a year between the first release with deprecation warnings, and the removal of support for a feature.

While we can appreciate the efforts of the development team(s), keep in mind that the end-user developers also have to put in a lot of effort to build and maintain their products, and may not have as much time to devote to re-learning how to use Rails as they do. It does not behoove the core team to make developers’ jobs more difficult than necessary.

Microsoft eventually moved to a minimum 5-year release cycle of major version upgrades, with only relatively minor upgrades in between. 5 years may be far too long, but 6 months is definitely too often.

Yehuda,

First off thanks so much for what you and the rest of the core team have done leading up to Rails 3 and beyond.

Second a +1 for Ernies request to merge squeel, assuming it is as awesome as metawhere.

I’m really looking forward to moving to 3.1, but I’ve got a few concerns with the current state of the asset pipeline.

The first concern is how to debug javascript with firebug or the webkit debugger when I have a single 25K javascript file including jQuery, any JQuery plugins, etc, etc. In development mode I really want to be able to have separate js files in the browser.

Maybe there’s a way to do that and it’s just the lack of documentation on how sprockets works and is being used. I must admit that I haven’t had too much time to dig into this and haven’t looked at it in a week or so so …

Second, right now it doesn’t look like Compass and the 3.1 asset pipeline are completely compatible. I see lots of activity in the relevant issues trackers/wikis, but I’m not sure I completely understand where this sits and how soon a solution will be available.

Third, and this relates to the first concern, I thought that there were performance gains to be had in serving common large assets, like jQuery and jQueryUI from well known servers (e.g. Google), because it’s then likely that the user’s browser may already have them cached. Is there or will there be a way to make sprockets let this happen?

I personally feel less uncomfortable with than other ActionView helpers like:

* select that accepts two hashes – one for select options and one for html options.
* form_for tab options that pass html with :html subhash

and others.

I think if rails starts having LTS releases, it’ll make many of the valid arguments against the continuous changes go away.

I had been meaning to ask you about the performance regressions in Rails 3, considering the fact that Merb was so performance-oriented, and much of your blog during your work on Rails 3 was dedicated to the performance enhancements you were getting from refactoring efforts. I’m curious what happened to those performance enhancements? I’m not sure if blog comments are really the place to have this conversation, but I’m not sure where else to ask.

Actually, despite this fanboy gathering of Rails adherents who would clearly stoop to tie Yehuda(!oh!)’s sandals, this response does little to address much of what the original post was legitimately criticizing. A large part of the original post — some of you might want to re-read it when you finish washing off the brow-sweat that began at the mere thought of posting on something Yehuda(!oohhh!) might read — had to do with Rails’ increasing barrier to entry. What Yehuda(!praise ye!)’s response does do well is to explain the logic behind technical choices. But the original question remains: is Rails making itself too difficult to adopt for newcomers?

I’m no longer a Rails user — I’ve switched to Django and haven’t looked back — and I never was a Yehuda(!blessed be thy name!) fan — not because Yehuda(!glory!)’s not a gifted programmer, but because being a fan of a programmer feels to me like being a fan of a good mechanic — but I won’t be porting my legacy Rails applications to 3.0 or 3.1. There are a variety of reasons for this, some of which have to do with Rails, which feels far too opinionated and convoluted to me, and increasingly so, and some of which have to do with my own path as a developer.

Fine. Whatever. But I did read the original post, to which this post is a response, and I thought legitimate points were made. It’s not, as some commenters here have asserted, a “hate post” or “hate” of any kind, and it’s not fear of change and it’s not even really a rant. It’s a well-reasoned posting of some legitimate criticism. Yehuda(!golly!)’s response was also well-reasoned, but incomplete. But if the community’s general take on that kind of criticism is reflected in the way this post deflects a good point and in the way these comments shout down other community members, then Rails, and its community, really is disappearing up its own asshole.

Ok, I read the original article, and (obviously) I’ve read Yehuda’s. I think people just gotta chill out. If things are moving too fast for you, or you’re new and just got a handle on AJAX, let alone coffeescript, use a previous version of rails (2.x is still getting updates). No one’s saying that you *must* use 3.1. I think Yehuda made a nice, calm expansion of understanding on the things that the referred-to article hit on.

I disagree with the article/comments that Rails is “disappearing up its own asshole.” Rails seems to me to always be trying things out (with the spirit of making it better for users and developers) and isn’t afraid to just fucking do it sans any bullshit. Seriously, I’ve used other frameworks (not necessarily web frameworks) and they talk and they plan and they debate and they never fucking do anything. At least Rails has the balls to just put coffeescript and sass in and just put it out there (and let’s be honest, the idea to include these things isn’t coming out of left field either: these are things people have been using and finding useful for a while, which make some real-world improvements (albeit not necessarily everybody’s cup of tea)). I have personally been using haml and sass for years, and when coffeescript came out, I jumped on that train too, because it made javascript feel like the other stuff I was doing (which were done in ways I liked aesthetically and practically). I don’t think the decisions the Rails team makes are arbitrary or stupid. I think the framework is moving forward in a positive direction (the key word here being “moving”). And I don’t think it’s hurting anybody that doesn’t want to use the new features that are coming out if they don’t want to.

Barriers to entry are another thing. Personally it did take some effort to wrap my head around the whole thing when I started out (but it was totally worth the effort in the end! I’m so much happier using Rails). But yeah, it’s not easy. Does it need to be easy? Is that a requirement? I guess more people would use it if it was easier and that would bolster the community and blah blah blah. But I think it’s more important that it’s *good*. Make it *good* first, then make it as easy as you can (part of making it good might mean making it easy, but my point is that the emphasis should be made on sanity over dumbing it down). Rails can be hard, but using it comes with a lot of benefits that make a lot of other things easier (I’ve gone through the effort of understanding Activerecord (and now Arel) because, man, that’s so much better than writing straight up sequel (especially complex join statements) for regular everyday stuff; it allows me to focus on my app (the thing I actually give a shit about) and not worry about the boring stuff).

Writing documentation (and books) are hard for anything in technology, and I don’t feel it’s a fault of the framework that it’s moving faster than books can be published about it. Maybe that’s just a good indication that the print medium itself is becoming more and more obsolete. We need *live* text documentation that is constantly updating and adapting to its changing target. Books will never be able to keep up (I have a shelf of books that are all completely obsolete now. I don’t buy books anymore because the stuff I want to know is online and the newest book at the bookstore is already a year out of touch with what’s actually going on). I feel the Rails community at large is really great at talking about how to use the framework and is generally really nice and helpful when someone has questions.

All in all, Rails is forward thinking and moving and adapting itself to how people are actually doing things. It’s moving. Deal with it. If you don’t want to move, just stay where you are with an older version of it. It can be hard for new users to get into, but I don’t think that alone should dictate how things get changed. Documentation will always be hard to keep up-to-date, but printed documentation (especially about technology) might just be the wrong medium these days. Now, we’re *able* to change faster, and I think that’s a good thing. I think Rails is *not* “disappearing up its own asshole” but is manfully displaying its protruding balls.

We love rails and the new release. Keep up the good work Yahuda we appreciate it.

Thanks!

Thanks Katz, This was an excellent explanation of the “why” of these changes. I am all for trying new technologies, but I’m always hesistant to accept new tech in major/primary libraries and frameworks. This has eased my mind on the changes and I certainly feel the changes are necessary. The only issue I still have is CoffeeScript. It still feels like “fancy fever” to me.

rails is a language. imagine if you got to learn a new language every year to survive. Have you ever met a person who is good in 10 languages ?

( lifespan of a poor software programmer )

Thanks Yehuda. For pointing it out. I really admire you guys doing so much for other people and share all your stuff.
I am really grateful, for all the amazing work you all do. For me, its a blessing, that I found rails,
I loved it from the first day on….
I guess, that most of the people, that are complaining not even contributed a single little thing, not even submitting a bug…

What I am still missing though… and… it IS quite difficult to do, is build and integrate with a largely used CMS solution, with an enterprise CMS like Typo3 is.

We often have requirements to integrate an app with a bigger Website.
Relying on the numerous smallish CMS makes it often still a “No-Go”, when we offer it to clients.
That’s why we still have to go with PHP even if some parts would be amazing built on ruby and rails.
The still don’t want to experiment with self factured software (Micro CMS) or baked together, which isn’t that reliable as a CMS like Typo3 or Drupal (PHP) which has a humangous Userbase and 10’000 of plugins.

This is why php had such a success, because of the variety of (not only but mostly) CMS’ out there.
A Software like an enterprise CMS would push Rails to a whole new level, like Rails with Ruby did. (sorry Ruby purists :-) )
I think, to establish a programming language or even a framework, it has to be used a lot not only in custom apps, there has to be not only some frameworks (rails, sinatra etc.) and many many libraries (gems), but a Software, which builds on it and supports a great way to write your own plugins (relying on that CMS Libraries on top)

It’s a shame, Typo3 CMS didn’t switch technology over to RoR, when deciding to refactor the framework and rebuild its entire framework too.
Because, all the former Typo3 Developers have to learn the new Version anyway.
It could have revolutionized a big part of the websector.

And deep in my heart, I still hope for a crazy great CMS like Typo3 CMS is, but for Ruby/Rails.
It may be time to copy some of their really good concepts, like Apple did from Google :)

Yehuda,

You know that I have the deepest respect for your efforts and the totally thankless (well, almost thankless) task of maintaining software – I know all about it!

Please consider the following carefully: at dojo4 (http://dojo4.com) we have a lot of people hanging out and hacking – everyone from hard core ruby devs, designers learning rails, and investors trying to understand the landscape. I’ve been programming ruby web apps since before fastcgi, before rails, before merb… you know I’ve seen alot. I can tell you definitively that the drone of complaints regarding installing, learning, and deploying rails has increased 10x since the big re-factor. I’d love to talk about this in IM if you have a chance but I can tell you that the perception of many regarding the new shiny bits is obscured by some major hurdles. Also, they are all fixable. I’ll look forward to discussing more in person – wanna come stay in boulder for a bit? We’ll put you up! ;-)

I’ve been learning Rails and related topics recently and I can sympathise with the frustration some people have.

My experience is that I regularly run against issues, some of which have been features from Rails 3.1 which weren’t yet covered in the Rails books. In those situations I’ve generally done the obvious:

1. Google – Not that effective as a high percentage of the posts I find are out of date and/or show an approach which you later find causes further issues.
2. Rails Guides – I’ve found these to be pretty mixed, for example the asset pipeline one has failed to answer many of my simple questions.

This has made the learning process far more painful than it should have been.

So from my perspective if there’s one thing that’d be a big improvement it’d be more comprehensive Rails documentation around new features to help people get onto the right path quickly.

Rails and the constant changes are really cool to techies but not quite encouraging for a stable corporate environment or a new beginner. There needs to be a better approach to the way features are being added or modified to ensure backward compatibility. It is becoming increasingly difficult to have applications or gems or managed. There need to be a new paradigm added to rails for the core developers – DON’T BREAK IT WHILE FIXING IT (OR MAKING IT BETTER). Stop brekaing t

Moved to rails 3.2.0.rc1 and my javascripts are not working again. The amount of time wasted to fix such teething issues are just not worth it.

The problem is that CoffeeScript is a method of indirection that obfuscates something that is already simple.

If it is “only a line in a gem file’ then why bother including it since 99%+ of the time it is going to get removed anyway.

Putting it in the gemfile is like putting Prawn, or paperclip in there by default. It is senseless.

I was hoping that when rails and merb merged that the merb teams humbleness and reasonableness would rub off of the rails team, especially DHH.

Instead it seems like DHH’s arrogance and to be blunt, stupidity, is rubbing off on you.

Rails 3.1 was change for the sake of change, no spinning by you will change that.

Leave a Reply

Archives

Categories

Meta