

What’s Up With All These Changes in Rails? - jcorcuera
http://yehudakatz.com/2011/06/14/what-the-hell-is-happening-to-rails/

======
Jd
There's a deeper problem that Yehuda isn't hitting and that is that there is
an inverse correlation between being cool and cutting edge and being consumer
friendly.

Rails is, and really has always been, a framework which changes very quickly.
Although virtually all of these changes are for the _better_ either in some
abstract feels-better sense or in a tangible practical sense, each of these
changes imposes a cost on other people.

This isn't really a problem with the decisions of the rails core team, it is
the entire ethos accompanying rails. Authentication plugins I remember from 4
years ago are barely maintained today, and there are a whole bunch of new
ones. I'm guessing my knowledge re: authentication has a half-life of
approximately 1.5 years.

The implications are as follows:

(1) If you are a Rails developer you need to be a full-time Rails developer
and not do too much else. You can't do Rails and a bunch of other things
because Rails will take up _a lot_ of your time.

(2) Think you can code, release, and forget about it? Think again. If you have
projects, you (and the people who commissioned the projects) need to know that
these projects need to have at least 5 hrs / week budgeted for the indefinite
future (perhaps less, but the point is that they need a developer on staff --
they can't simply be released and forgotten about).

(3) Extra caution, since not all change is good change. You may end up to
subject whatever is cool at the time. That's not to say that this really
affects the core team, but there are a gazillion Rubyists out there attempting
to change everything over to MongoDB that works just fine in whatever flavor
of SQL they were running before. A lot of people have been burned here.

All of these take away from the promise and excitement of Rails for many
people -- which was not simply "oh we can be on the cutting edge of
technology," but "oh, we can have a sexy app with decent functionality up in a
matter of a couple weeks with half the budget of what we thought." That second
impression, which is what a lot of the Rails ecosystem is built off of, is
largely false (esp. now that there are a bunch of other quickstart web
frameworks).

~~~
chollida1
> (1) If you are a Rails developer you need to be a full-time Rails developer
> and not do too much else. You can't do Rails and a bunch of other things
> because Rails will take up a lot of your time.

I'm glad to see someone else say this. I don't use rails often, nor am I a
"front end" developer by trade.

I have put together some simple web apps using rails, but it seems that each
time I go back to rails and try to use the newest released version I'm
starting back close to square 1 due to how things always seem to change.

I always just assumed that I didn't grok web frameworks, though this is still
a possibility.

~~~
jarin
I think most Rails developers I know are also full-time designers,
JavaScripters, database admins (SQL and NoSQL), server admins, IT people,
project managers, forum posters, Stack Overflow answerers, social media gurus,
SEO/SEM experts, and salespeople.

It just sort of comes with the territory that being a good Rails developer
means being a polymath.

~~~
awj
Yeah, as a Rails developer I seriously doubt any of us are _full_ time _any_
of those things. I've met people that _actually_ do full time JavaScript dev
and DB admin, the knowledge difference between us is staggering.

Rails developers need to wear lots of hats to get their jobs done. They need
to be "good enough" at each of those. That, in itself, is a difficult enough
task. You don't need to go trying to claim they do full time level work for
six different jobs.

------
ssmoot
I'm not a fan of Rails myself, but I sympathize with Yehuda's position. The
helpers are my #1 gripe with Rails. It really kills productivity to have to
dig through all your views for what feels like pet changes.

The one point Yehuda's making I'd dispute is the impact of Arel.

I saw a very early version of Arel back when I was maintaining DataMapper. To
be clear, Arel is beautiful code. It's ridiculously well done IMO from an OO
stand-point. It's the code I wished I could write in DM.

I didn't use it (or something like it) in DM because I'd been there and seen
the consequences. To give the point some context, you might expect NHibernate
to impose a 10% overhead on c#. NHibernate is a very complex library, doing a
lot more than most (any?) Ruby O/RM. In Ruby, once you get beyond the most
trivial examples, you can easily see numbers like 50% overhead, and some
queries that would be a cake-walk in .NET are impractical or even impossible
in Ruby with constrained resources or service timeouts.

Ruby method dispatch and object instantiation is slow. Damn slow. Ridiculously
slow.

The reason DM and now AR perform two-query-eager-loads to avoid JOINs has
almost nothing to do with database performance. I doubt many Rubyists really
understand or grok what that means. It has everything to do with the
instantiation and even simple iteration of a cartesian product in Ruby being
infeasibly slow.

Getting back to Arel: It's probably the very best of Rails OO. But that it's
introduced some very serious performance regressions is no surprise at all. I
said as much to NK and Yehuda when we discussed it during DataMapper 0.9
development.

With Ruby you have to make compromises. Especially in such a critical-loop
portion of your stack.

On the other hand, if you're going to stay with AR, then it probably needed to
happen sooner or later.

Best of all worlds would have been to drop AR altogether and promote a
migration to Sequel for the official Rails O/RM. ;-)

~~~
jamesbritt
_Best of all worlds would have been to drop AR altogether and promote a
migration to Sequel for the official Rails O/RM. ;-)_

Indeed. Or decouple the ORM entirely, though that likely removes a key aspect
of what Rails is about.

It is, however, what makes Ramaze so appealing. No coupling to any ORM, but
there is a community inclination to use Sequel (so you can learn from example
and there are people to answer questions).

~~~
lifo
You seem to know very little about Rails 3. But if you think ramaze has a
"community", I guess I can understand why.

~~~
sunir
Teach, don't snark. Snarking only teaches that the teacher is a snark.

------
stephth
I feel like this discussion wouldn't be getting so much traction if it was
easier to _learn_ the differences between specific versions. Today there's
enough resources out there to learn about rails and/or the differences between
versions and/or 'the right way' of doing things, but it's scavenger hunt meets
jigsaw puzzle. Currently, if you don't follow the Rails evolution regularly,
going out there and catch up with it can be intimidating for some.

There's a need for a central Rails reference that makes this task trivial.
Maybe a document with some sort of interactive diff functionality that allows
to see specific version differences side by side in a friendly manner. Some
system that doesn't force the writers to re-think a full document for every
version, that can evolve without erasing older information, and that assists
the reader by showing specific chunks of information that she should read in
order to catch up to the specific version she is aiming for. Getting this
started is a non-trivial task, but it seems like there's enough energy,
innovation and attention to detail surrounding Rails to solve this problem.

~~~
bonaldi
I abandoned Rails years back because of precisely this problem. Releases would
break or arbitrarily drop functionality, with little or no documentation. If
you got more than a few point releases behind you were really screwed.

I couldn't explain the dearth of documentation for these changes at all, it
seemed so lax compared to other platforms. Then I realised all the incentives
for those who would produce the documents were towards producing books and
paid-for screencasts, and knew my time was up.

~~~
bcardarella
Prior to Rails 3 Rails' versioning scheme left a lot to be desired. However,
starting with Rails 3 it is supposed to be following Semantic Versioning.
(<http://semver.org>) This should help with giving people an idea if they can
update without fear their app will break.

------
dasil003
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).

------
trustfundbaby
I appreciate the post and am a huge fan of Yehuda, he 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'm not
complaining about the changes per se (because I like most of them), what I'm
complaining about is the pace of the changes.

Something as major as the asset pipelining feature (where you move assets out
of the public folder and into the app folder), 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.

See what I'm saying?

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 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 highest regard for them.

~~~
mnutt
Do assets in public/ break in 3.1? Sure, it's encouraged, but I'm pretty sure
if you tell your web server to point to public/ it will serve your static
assets from there. As far as I know you can upgrade your existing rails app
from 3.0 to 3.1 and start using asset pipelining on your own schedule.

~~~
trustfundbaby
It seems like you're not seeing the forest for the trees, with respect to what
I'm saying.

I don't need help upgrading. I just think the Rails core team should do
releases in such a way that big features which drastically change the way
Rails does things, aren't put in the pipeline back to back, like this was
(3.0, then 3.1) that way Rails doesn't get a reputation for constantly redoing
the "Rails Way".

------
ry0ohki
It seems like a tough line, and I sympathize with both sides.

Either you can go the Microsoft route and be backwards compatible til the end
of time (which is great for devs, but causes baggage) or you can embrace
change while the community is still young(ish).

It seems like at a minimum, everything in a major version should be backwards
compatible (ie a 3.0 project will work in 3.1 without changes) though.

~~~
bad_user

        Either you can go the Microsoft route and 
        be backwards compatible til the end of time
    

You probably never went with Microsoft to say that.

Yes, they are shipping the DLLs till the end of time, but you can also find
the _source code_ to Rails 2.3 till the end of time (it's right there, in your
face), just as you can find the source code of Linux 0.01 (the initial
release).

On the other hand, what's the latest recommended path for building UI, the
Microsoft recommended way? The Win16 API? The Win32 API? MFC? WTL? Windows
Forms? WPF? Silverlight? HTML5?

Evolution happens, you need to deal with it. The only stable API I know that
is still relevant and still important to learn (instead of an abstraction) is
POSIX-stuff.

~~~
ry0ohki
Microsoft definitely has a lot of the "hey try this new thing" going on, but
the key difference is I don't have to painfully upgrade all of my ASP.NET 2.0
applications when ASP.NET 3.0 or 3.5 comes out. Sure those support new
features, but they are usually 99% compatible with the old versions (I believe
they deprecate over two versions for the things that do change). Also if I
look for code on the web, it's usually valid for any version (with the
exception of LINQ).

~~~
bad_user
Yeah, but ASP.NET sucks. Don't get me wrong, it was great in 2001 when it was
released, but the Viewstate/Postback model really sucks judging by modern
standards and it was a really bad idea when viewed in perspective.

And ASP.NET MVC is different and whatever compatibility it has with ASP.NET is
actually hurting, IMHO. I mean, here's a framework with potential, but it has
to carry the old bagage of ASP.NET from the start.

I get it that a framework like Rails moves TOO FAST for its own good, but
nothing compels you to upgrade right now. Lots of people are still on Rails
2.3, it's a stable and reliable version and if you'll look around many
projects have 2 branches, one for 2.3 and one for 3.0. And some of the
projects, especially Rack middleware, don't need 2 branches.

It kind of sucks from one perspective - the 2.3 branches are going to receive
less patches/upgrades, but you have the source code. If something really
important is missing, or there's some unfixed bug, you can go ahead and fix it
yourself.

You can't say the same thing about a binary DLL. I remember when I first tried
out ASP.NET 2.0 - it contained an annoying bug related to their CSRF
protection (if you clicked any control before the page loaded, it triggered an
error since the CSRF token was getting loaded right before the </form> tag, at
the end of the page), and it took a service pack and 2 months to get it fixed.

------
erikpukinskis
I kind of wish they would go further. While I prefer Rspec, I understand and
sympathize with those who feel Test::Unit is a better default.

But HAML feels like such a vast, unambiguous, never-going-back improvement
over ERB that I am honestly baffled Rails hasn't adopted it. It's at least as
big a win as Sass and CoffeeScript, if not bigger.

I agree with Katz here. If anything, Rails has shown remarkable restraint in
the face of a smorgasbord of shiny, new, and often superior, competing
technologies.

~~~
mhartl
Haml is great for many cases, but it's terrible when the ratio of text to
embedded code gets large. Chris Eppstein, one of the developers of Haml, made
a blog post to this effect last year:

[http://chriseppstein.github.com/blog/2010/02/08/haml-
sucks-f...](http://chriseppstein.github.com/blog/2010/02/08/haml-sucks-for-
content/)

As a result, though I love Haml, I think ERb is a more sensible default.

~~~
bonzoesc
I think ERB ends up kind of ugly for prose too; adding rdiscount as a
dependency and using the markdown filter in Haml is usually how I do it.

~~~
mhartl
Sounds like a good solution. I'll have to try that out.

------
jmtame
Thanks Yehuda--you had quoted me on the asset pipeline and I have since
upgraded to Cedar on Heroku. I suppose the slow loading of images in the asset
pipeline was the biggest gripe on my part, but didn't realize images should
still be served through /public. I would say that I am still hesitant to
deploy apps using release candidates, but overall think the Rails team does a
great job on the upgrades. Maybe more emphasis on documentation, but
understandably it's a release candidate.

Also, DHH chimed in and offered some awesome advice that I didn't know about:

 _rake assets:precompile will automatically copy images from app/assets/images
to public/assets._

------
sams99
What surprises me is that lack of backlash for the shoddy upgrade process...

Moving from Rails 2 to Rails 3 is a nightmare, a documented nightmare in 3
parts <http://goo.gl/2Xw7n>

Sure you can get part of the way by porting to bundler and upgrading to ruby
1.9.2, but there is no plugin or way to have an app work with both Rails 2 and
Rails 3 at the same time. And this is a year after it was released with 3.1
just around the corner.

For the upgrade you need to change boot.rb, application.rb your routes and all
your other configuration. Potentially you may need to update a ton of views to
allow for the xss protection.

By themselves none of the changes in Rails 3 are bad, its just that somehow
they managed to make it very very hard to upgrade, so less people use it, and
it gets less testing and stuff regresses.

I think if the team focused on a bridge / integrated upgrade path for rails 2
that allows you to switch to rails 3 seamlessly it would do wonders for
adoption.

------
mmaunder
Rails seems to be focused on it's own navel. It's written by developers to
solve problems developers perceive they have. The platform rewards new layers
of abstraction within the community - and those layers really exist to enforce
a discipline which may not be needed and becomes restrictive if you don't want
to do things the Rails way.

From my perspective as a serial startup founder, I won't touch the platform
because startups must innovate or die and to enforce too much discipline on
the way things are done within a platform is to risk killing innovation.

The best startups not only use platforms in unexpected ways, but are platform
agnostic and use multiple platforms that probably didn't expect to have to
talk to each other.

Startups choosing Rails need to remember that 37Signals have a group of mature
apps that are maintaining and incrementally improving with (I'm guessing)
growing team of devs. Their apps are also B2B and have relatively low traffic
compared to many consumer focused startups. Their focus is code and team
scaleability. They aren't rapidly prototyping or rapidly innovating. Also as
the center of the Rails community, they don't need to care that Ruby devs are
harder to come by than PHP or more mainstream languages.

Rails also strikes me as a rockstar dev culture that puts marketing,
innovation and being perceived as a thought leader ahead of everything else,
including the boring crap like productivity, simplicity and performance:

[http://www.flickr.com/photos/46457493@N00/4441909186/in/set-...](http://www.flickr.com/photos/46457493@N00/4441909186/in/set-72157594262577872/)

~~~
tjogin
You seem to be _very unfamiliar_ with Rails and the Rails community.

------
kingkilr
> 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 isn't particularly accurate, my understanding is that what became the 1.9
VM was originally an external fork (or rewrite, I'm not clear on which) known
as YARV, which was later integrated, but was _not_ originally developed by the
MRI team. As always feel free to tell me I'm a moron who has no idea what he's
talking about.

~~~
wycats
YARV was an external fork that was integrated into MRI pretty early, and then
worked on by the core team for several years. My point was simply that YARV's
existence and the commitment of the core team to get it into core (and the
resulting performance improvements) disprove the idea that the Ruby core team
doesn't care about performance.

------
tjogin
I'm so impressed with Yehuda's ability to be both persuasive and calm while
completely destroying every aspect of the argument he is refuting.

~~~
SeanDav
Agree that Yehuda is calm and makes good points - However the main point of
the original article still remains intact - Rails is very hard for the
beginner to learn, much harder than before.

~~~
ayb
>> _Rails is very hard for the beginner to learn, much harder than before._

I think that Rails is hard to learn for several reasons:

* unless you've used it before, you have to learn Ruby too

* Rails is fast moving and has a lot of pieces

* the error messages can be cryptic and hard to decipher

I've been developing with Ruby and Rails for several years now and I still
encounter cryptic error messages.

As a newbie I found it incredibly frustrating when Google did not bring up an
immediate answer, it basically built a brick wall around me. I don't think
this is Rails' fault per se, it's just the nature of the beast.

~~~
chernevik
I found the Hartl RoR tutorial slow going, and couldn't parse whether my
confusion was Rails, or Ruby, or REST concepts (& Rails implementation
thereof), or TDD (which I found takes some getting used to). "Learning Rails"
seems to involve learning some design practices and process tools that are
less mandatory when learning other frameworks. But I'm just a newbie with some
Python / Django familiarity, others may take to this stuff faster.

I have found those additions worthwhile. The work I've done in Django has gone
a _lot_ faster, and I think better written, for the orientation to REST and
TDD.

Perhaps real devs with more experience find these pieces less helpful and more
intrusive?

------
kreek
Coming from PHP Rails was a great way for me to learn best practices and get
disciplined. Now that I have a good foundation I find myself using Sinatra
plus whatever gems fit my small to medium projects. So it might not be that
Rails is too heavy, it could be that some of these projects don't require the
learning curve of Rails to be successful.

------
ryan-allen
We have always been at war with Eurasia!

