Hacker News Reader

Comment by nirvdrum | Hacker News Reader

Surely there's some middle ground though, no? At what point do you have a stable core and then you just bolt things on? There's nothing stopping you from using SASS and Coffeescript with Rails 2.3.

I skipped the Rails 3 upgrade just simply because I couldn't justify the time sink. rspec made it ridiculously worse with the difference in Rails support between 1.x and 2.x. I'm guessing with Rails 3.1 coming out I'll have to upgrade just because most of the plugins I use have moved on and don't backport bugfixes.

It'd be nice to evolve an app without having to constantly wasting time on version compatibility. It's an absolute nightmare if you have any non-trivial-sized app.

View on HN

Surely there's some middle ground though, no? At what point do you have a stable core and then you just bolt things on?

Very true. Frameworks should strive for a solid API that makes it easy for people to write add-ons, and avoid adding anything that is not essential.

Of course, one hacker's essential is another's bloat, but developers should give things a long hard look before adding stuff.

It's the reason I like Ramaze so much. Has what's needed, gets out of your way, it's easy to evolve or extend if you know Ruby, and it respects your opinions.

"I skipped the Rails 3 upgrade just simply because I couldn't justify the time sink."

This is where you lost me. I spent about 2 hours, aggregate, spent solving upgrade-related problems across a bunch of different apps.

Where is the time sink?

The time sink is in migrating all the plugins/gems that either dropped support for Rails 2.x in favor of 3 (i.e. no version that supports both), or were abandoned for some other competing gem. What this means is that for any app that uses lots of plugins, it's a nightmare to upgrade to Rails 3.0, not because of Rails itself, but because it means you have to migrate all those plugins simultaneously just to preserve existing functionality.

There are entire sites like http://railsplugins.org/ to help you figure out if your plugins are Rails 3 compatible. Unfortunately, there simply aren't enough users to crowdsource the compatibility of all the plugins out there.

Which gems are we talking about, specifically? If it was abandoned, then you should be replacing them anyway. Backward compatibility is vastly overrated.

Actually, it doesn't really matter if it was abandoned or not. Upgrading a large number of dependencies at once is going to create problems for any project. Hell, working out the redis-rb nightmare of an upgrade took well over a week of effort trying to coordinate with the various projects that depend on it.

But, if you think backward compatibility is vastly overrated, there's really no seeing eye-to-eye on this.

100% correct. The other fun one is rspec 1.x supports Rails 2.x but not Rails 3.x. spec 2.x supports Rails 3.x but not Rails 2.x. Since the Rails support was modular, I have no idea how this situation resulted. But it basically means I have to upgrade with no test suite.

You are not forced to use SASS and Coffeescript. You can just switch them off. You can also switch off the asset pipeline.

That wasn't the argument I was making. My argument was if those are the new technologies you want to play with, you don't need a major new Rails release. Since the opposing argument seems to be that Rails needs to keep breaking compatibility in order to keep up with the latest technologies.

Actually Rails 3.1 has a lot more features then just the Asset Pipeline and SASS/Coffeescript default. This blog post lists most of them: http://weblog.rubyonrails.org/2011/5/22/rails-3-1-release-ca...

Also there are a lot of deprecated things that must have been removed in 3.1 ― TBH I haven't kept in touch with 3.1 development but I'm sure a lot more has happened besides the default switch and Asset Pipeline. :)

Basically in the end, Rails is a curated framework. It either fits your requirements or it doesn't. There is no need for it to work for "all possible" cases.

Also like I said you don't have to use the defaults. :)

> Rails is a curated framework. It either fits your requirements or it doesn't.

"Opinionated" was the original description. "Curated" is just some buzzword that means "people look after it" rather than "automatically generated", which is, uh, pretty much going to be par for the course for a maintained framework.

"Here's the Rails gospel: Promote good ideas and technologies. See Ajax, REST, Atom, testing. Rails is a curated set of tech choices." ― DHH

source: https://twitter.com/#!/dhh/status/58286524151775232

DHH saying it does not make it any less of a silly buzzword. I much prefer his original "opinionated", as it much more clearly gets at the heart of what Rails is, that it doesn't try and be everything to everyone.

Curated does not just mean "people look after it." It also means that people make editorial choices about what belongs and what doesn't.

So pretty much like most software ever developed?

"Opinionated" communicates the idea so much better - it means not only that yes, some choices were made, but that some of them are the result of strong opinions, and do not necessarily try and accommodate all points of view.

Hang on while I grab my beret.

The link you posted above to the blog post describing Rails 3.1 seems to be broken.

Reply on news.ycombinator.com