I don't think the author really gets why people have a problem with what's going on with Rails, and the article strikes me as a "I like this why don't you?!" type deal vs making a reasoned argument for why the constant change in the Rails way of doing things is necessary.
> If you’re learning a new language, a strong community consensus about a right and a wrong way to tackle problems aids learning
-----------------
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.
> If, as coders, we aren’t constantly striving to improve the status quo, what’s the point?
---------------------------
The point is that you have to realize that Rails isn't just your personal plaything any more, people are invested in it just as much any one person or group of people.
I have 5 Rails 2 apps that I support at work and a couple more outside of that, they're all on rails 2 ... bringing them up to Rails 3 without disruption, isn't going to be trivial and I'd be nice if folks acted like they understood that and didn't dismiss similar concerns, or berate folks for having concerns.
To that end, my personal preference would be to see fewer but more substantial releases and a little bit more engagement with the community before making major decisions about the framework instead of the steady drumbeat of updates and (seemingly) unilateral decisions (that coffee script decision really irked me, can you tell?)
This is where "state of the art" is really an apt phrase. Rails 3 is effectively a community consensus on the best way to make most webapps today. Rails 2 was the community's best stab at that same goal a few years ago. The distance between the two is explained by a changing state of art, and some ferreting out of weaknesses in the framework.
I think rails developers blindly upgrade their apps, just because they want to be on the hottest new technology. I know I am drawn by the glitter of rails 3.1 beta. But everyone should really weigh the business decision of upgrading; what do you really truly gain by being on the latest rails for all your apps? Sometimes the technical debt you take on by maintaining an old framework is less than the effort you have to spend to upgrade, especially for sunsetting apps.
Please. I've been writing rails apps professionally since 1.2. My observations:
1. jQuery quickly replaced prototype for most projects via the jrails gem. This just reflects the underlying reality.
2. Coffeescript as the default was a bad idea. This would make more sense in say a year from now.
3. Rails 3 active record w/ ARel is HUGELY better. I used to have to pull out find_by_sql every so often, haven't needed it yet in rails 3.
4. Bundler solves a whole raft of annoying dependency issues in rails 2. I can't tell you how many hours I lost to dealing with weird issues with vendored gems.
Bringing rails2 apps to rails 3 is going to suck for you. I'd argue that one of the prices for the elegance of rails is that you need to spend more time constantly upgrading it.
However, the advantage of this price is that you have a framework that has been consistently lead of the pack in terms of productivity and simplicity.
Personally I have worked with probably a dozen web frameworks thus far, on top of various languages, including Perl.
I'm not going to say that Ruby on Rails is the most productive, as python's Django (my bread and butter) is not too shabby either, and most popular platforms have some web framework that gets close or that are better at various tasks (e.g. I chose PlayFramework for some project I had because of its async support and couldn't be happier about it).
But IMHO, Rails 3 has the best design of the bunch - ActiveModel, ARel, Bundler, Passenger, database migrations that don't suck, less boilerplate than anything else of the same size/scope, the best plugins system I've seen (yes, I think it is better than Django's, no matter what Zed Shaw has to say about it) and also has the advantage of popularity.
This doesn't come without sacrifice. I hate that they've forcefully added SCSS/CoffeeScript as a default. But the great refactoring of Rails 3 had to be done, as frankly, the Rails 2 codebase was an incomprehensible mess. And you can't be on the leading edge of web frameworks without breaking stuff.
That said, Coffeescript as a default? Geez, I'd really like to know what they are smoking.
I'm sorry yes, the preceding post represents my opinion, and my opinion only. It does not represent the opinions of my employer, bank, or family, nor is it an official verdict of the United States Supreme Court.
Furthermore, any likenesses to people real, living, or yet-born are purely coincidental, or have been properly sublicensed through those who own their copyright.
You may not make copies of my post without the express, written consent, of the National Football, Baseball and Basketball leagues.
> Right, but the problem is that there doesn't seem to be a 'right' way, That's the problem.
The problem is that the state of the art changes. The reason Rails is still relevant is because the core team is committed to improvement, even at the expense of API stability and legacy support. That's definitely a valid concern for someone supporting apps on a shoestring, but on the other hand it makes Rails more suitable for someone who wants to stay on the cutting edge. You simply can't have it both ways...
> We were all prototype a few years ago, now it jquery ...
You mean __7__ years ago when they chose it as the default? Rails was the first framework with Ajax support built-in, and it was done poorly because nobody understood how it should really work at the time.
> we (well I) hadn't heard of coffeescript till a few months ago and now its a default option in rails
It's easy to argue that CoffeeScript shouldn't be a default, but then it's even easier to just turn it off. Shouldn't be a point of major contention, but I can see how people don't like it.
> The way we were constructing ActiveRecord finders had been set all through Rails 2, now we've changed it
Yes, they replaced a hodge-podge of ad-hoc query construction with a relational algebra library that enables dramatically more flexible query construction and lazy loading. Who knows how many broken edge cases were fixed merely by the switch to a proper mathematical basis.
> the way we dealt with gems was set all through rails 2 now its changed completely in Rails 3.
Bundler solves dozens of thorny issues that were intractable in the Rails system. Now Rails is simpler because it doesn't have to have any gem activation code, it's handled by a separate library that can solve your gem management problems for your non-Rails projects as well. You may not have run into any of these issues, but I assure you there were real and Bundler is a big step in the right direction.
> the way we dealt with gems was set all through rails 2 now its changed completely in Rails 3.
Yeah but what are the implications of that? You want Microsoft-style legacy support from Apple? They ain't gonna give it to you, because that lack of legacy support is what enables them to move forward at the pace they do. This has definitely impacted the type of projects I feel comfortable delivering in Rails (ie. no low-budget small client sites), but for an actively developed app it makes Rails a more attractive place to be.
Neither the first post ("WTH is going on with Rails?") nor this one is talking about upgrading existing 2.x apps to 3.x. There's a lot of stuff to change, and it can take a not insignificant development effort to port them.
But that's not the question here -- the question is whether Rails is getting progressively easier or harder for a newbie to pick up and whether those changes are going to result in better or worse applications.
But that's not the question here -- the question is whether Rails is getting progressively easier or harder for a newbie to pick up and whether those changes are going to result in better or worse applications.
--------------------------------
If you read the article he makes other points as well, the author of this article just seized on this because it was probably easiest to shoot down.
In the original article the author says ...
"The speed of change in using and learning rails however is a real worry for anyone who wants to use it. It might completely change by the end of next month"
That's what I'm interested in discussing, and I suspect where the real problem lies.
The problem, or the solution depending on your point of view, is that Rails is not backward compatible between minor releases. Each minor version is work to upgrade to it. My recommendation has always been "start with the latest version of Rails even if it's RC status" since upgrading will be a pain. Hopefully the RC will be complete before you need to launch.
Then you have to make the decision for each app - "Do I upgrade or stay on the latest version"? I personally prefer that tradeoff - Rails can cleanly add new features even it breaks the past. Then I decide if I need those features more than I need the pain of upgrading.
I understand your frustration -- you may not think so, but I get it. That being said, the other points I made were in support of the answer I pose to the question: Rails is growing up. The changes we've seen aren't just change for change's sake. They're changes that continue Rails' evolution by identifying pain points and presenting a default solution to them, one that can be opted out of if desired. This is not new for Rails, but it seems like every time we turn around, people are acting surprised.
They're changes that continue Rails' evolution by identifying pain points and presenting a default solution to them, one that can be opted out of if desired
-------------------------
You're thinking "Why can't they just opt out of this and let us have our fun" and we're thinking "why are they forcing this on everybody".
Its kind of how you get a windows box and it has all this crap on it by default ... you can go uninstall or turn stuff off, but its fricking annoying as heck.
Some things should be the way things are done in rails, bundler, the new ActiveRecord queries. yes
Some of this other stuff, not so much ... you should have to explicitly turn it on not turn it off, and then if we're seeing wide adoption then we can make it part of the core.
What is wrong with that approach?
one that can be opted out of if desired. This is not new for Rails, but it seems like every time we turn around, people are acting surprised.
---------------
Don't make people opt out of stuff especially on things that might not be so core to rails ... Opting out is annoying ... its much better to go "Wow, I didn't know that was there" than "crap ... I have to turn this stuff off now". It gets on people's nerves, the fact that you're not seeing that despite confessing that people complain each time it happens suggests a certain amount of tone deafness.
I could be wrong, but I think its worth re-evaluating.
"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."
As long as something is backwards compatible, I don't see the problem. That is the natural progression of a rapidly evolving industry like tech, there is always something new. I don't see how introducing coffeescript as an option makes a problem for anyone. I agree there shouldnt be change for changes sake, but often through trial and error we discover a more efficient way of doing things. If rails doesn't evolve, it will be replaced by frameworks like Django, CakePHP that do.
The Rails core team does seem to treat the project as if it's a personal playground. But the improvements they make do seem to (usually) be good ones. Since it's almost always the case that you can eschew their choices, the complaints I hear are not compelling.
I think you're missing the perspective of someone who has a major body of apps to maintain. I easily upgraded a trivial app. Now I'm slogging through a month long Rails upgrade process on a very large app. Unless you've been stuck with a large upgrade like this, it is probably hard to understand the upgrade pain.
That said, I love the changes in Rails 3. Considering strings unsafe and escaping them by default is great, bundler rocks, arel is very nice, and the mailer api is nice.
The rapid change and code purity ideals in the Rails world leads to benefits, so I tolerate it in Rails in spite of its costs.
This idealism has unfortunately infected projects in the Rails ecosystem that are really just infrastructure (where change should occur slowly). As examples, both Rspec and RubyGems are willing to break compatibility and code that I rely on for benefits that are neglible, aesthetic, or invisible to me. The difference is, when Rails breaks something, 90% of the time it buys me something.
The Rails core team does seem to treat the project as if it's a personal playground
---------------------
And thats a dangerous attitude to have, because as smart as they are (and they are very smart guys, make no mistake), they can also make bad decisions, just like the rest of us ... the difference being that the impact on all of us could be huge.
The author says Rails is growing up, part of growing up is learning to be responsible too.
> If you’re learning a new language, a strong community consensus about a right and a wrong way to tackle problems aids learning
-----------------
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.
> If, as coders, we aren’t constantly striving to improve the status quo, what’s the point?
---------------------------
The point is that you have to realize that Rails isn't just your personal plaything any more, people are invested in it just as much any one person or group of people.
I have 5 Rails 2 apps that I support at work and a couple more outside of that, they're all on rails 2 ... bringing them up to Rails 3 without disruption, isn't going to be trivial and I'd be nice if folks acted like they understood that and didn't dismiss similar concerns, or berate folks for having concerns.
To that end, my personal preference would be to see fewer but more substantial releases and a little bit more engagement with the community before making major decisions about the framework instead of the steady drumbeat of updates and (seemingly) unilateral decisions (that coffee script decision really irked me, can you tell?)