
What the hell is happening to rails? - tswicegood
http://blog.stevecoast.com/what-the-hell-is-happening-to-rails
======
ekidd
What's happening to Rails? DHH is adding some new APIs, and he's suggesting
new programming guidelines and conventions.

This is nothing new. He's been doing this every 6 to 12 months since Rails
0.13 (at least). Here are some of the bigger disruptions:

\- Rails 1.2: Rewrite all your controllers to use the new REST model. (This
was annoying, but the results looked a lot better.)

\- Rails 2.0: Change from ";" to "/" in standard resource routes, and rewrite
controllers to use respond_to.

\- Rails 3.0: Deal with bundler, ActiveModel, Arel, a total overhaul of
ActionMailer, etc., etc.

By historical standards, the asset pipeline is a medium-sized change, and
certainly much smaller than the Rails 3.0 changes. And unlike the Rails 3.0
changes, you can turn it off in about 2 minutes.

Personally, I rather liked most of these new features at the time: They
addressed my day-to-day pain, they made my code cleaner, and they helped me
keep in sync with other programmers. Rails is optimized for a certain set of
opinions, which overlap about 80% with my own, and that's usually good enough
for me. If your tastes diverge from DHH's tastes to a greater extent, it won't
be as much fun.

------
latch
I spent the end of last year doing Java/Struts. Felt like time travelling back
to 2002. Back when I knew PHP, versions increased, but nothing really changed
for years and years (I'd be surprised if it was much different today). The
.NET folk will tell you how great ASP.NET MVC is, but they live in their own
world - a new view engine doesn't close the gap which exists between it and
more progressive MVC frameworks.

The point? If you want stagnant frameworks there's plenty to pick. A lot of
them aren't easier to learn, but none of them require you to keep learning.
This is great because it tends to attract all the programmers you want to
avoid into obvious communities.

~~~
kenjackson
_If you want stagnant frameworks there's plenty to pick._

There's a difference between stagnant and growing in the right direction. I
think the author believes that RoR is moving away from what many thought was
one of its core pillars: The ability to go from nothing to an up and running
web app quickly.

Lots of things aren't stagnant -- few things move in the right direction. I'm
not saying that RoR isn't moving in the right direction, but I think you've
created a strawman of sorts.

~~~
jshen
" The ability to go from nothing to an up and running web app quickly."

How in the world do the changes lead to a situation where you can't get an app
up and running quickly? I don't see that at all.

~~~
riffraff
I have no opinion on this, but the original article makes a few cases for
this: no more ajax/javascript helpers in core, no more catch all route by
default etc.

~~~
jshen
The catch all route is there, you just have to uncomment it. It takes one
second.

There are other points where the article is plain wrong to. "It used to be
that you just used Prototype, now it goes to vast efforts to be agnostic." No,
it switched the default to JQuery, thank god.

------
_pius
_If you want to learn rails, don’t get the latest pragmatic programmers book.
Go and get the 1st or 2nd edition. Get an old copy of rails and ignore all
this._

Worst. Advice. Ever.

 _Once you’ve figured that all out then upgrade and expect to spend the same
amount of time learning all the new stuff. You don’t save any time jumping to
Rails 3+._

This just isn't true.

~~~
nfm
Agreed. Rails has significantly changed since 2.3.x, and is extremely
different to 1.2.x. These changes aren't just for the sake of it - Rails keeps
on improving! Start at 3.1 and you won't be sorry.

~~~
tdfx
I started with rails 3 and I haven't had any major hurdles to overcome. I've
been very impressed with Rails. I'm coming from a Python/PHP framework
background, and so far rails is my favorite (only done a few apps so far, mind
you).

------
mrinterweb
I think the big difference between now and when Rails was first starting to
gain popularity is that now most of the blogs are primarily covering
advanced/obscure topics related to rails. Years ago, most blog posts were
about the basics of getting started with rails. Now those old posts no longer
apply to the newer version of rails. This is not the fault of rails and it is
not the fault of bloggers. There is no shortage of books available to learn
rails, but learning a new framework via books is not always the most
approachable way for newcomers to learn rails. It would be awesome if someone
rebooted some of the older railscasts by Ryan Bates Railscasts for rails 3.1,
but that takes a lot of effort and in another year or two the content will
again become stale. I would love to see some people blog about the basics of
using new versions of rails.

Rails has been improving over the years, and I think excellent design
decisions have been made. I do not think it is the fault of rails that the
author feels that rails is less approachable.

~~~
joshwa
The pace of Rails development isn't a problem in and of itself, it's that the
pace of change and the _overall Rails development culture_ wrecks the
documentation ecosystem.

Of the top rails documentation resources:

* Rails Guides are still out of date and incomplete for 3.x series. I often have to go to the API docs since some big topics just aren't covered in any level of detail.

* Railscasts deals exclusively with deltas-- new features, new techniques, etc, and no longer has a nice pedagogical sequence. The original tutorials are just plain out of date. (Maybe the peepcode tutorials are more up-to-date and comprehensive?)

* Google. The biggest of all. Rails pace of change and its agnosticism means that the corpus of blog posts with recommendations, bugfixes, tips, tweaks, tutorials, etc, become out of date quickly, and more importantly it's extremely hard to tell what version of rails or of a plugin a given post or thread is referring to.

A secondary issue: Rails newfound agnosticism (compared to its previous
"opinionated" nature), along with the culture of the "flavor of the week"
creates problems in the development and documentation ecosystem:

* The plugin ecosystem: the "flexibility" of rack means that there are so many plugin options it's blinding, and the flavor of the week changes so often that it's hard to know if you're on a dead-end track or not.

* Google: the same issue with Rails core changes applies manyfold to the development ecosystem: blog posts, stackoverflow threads, forums, etc are quickly obsolete and it's difficult to determine staleness and whether the recommendations are pointing to a development dead-end where the project is no longer under active development.

The panoply of options and the chaotic development ecosystem can equally be
attributed to Rails' newfound agnosticism, the development culture that
engenders, and that chaos multiplied by the huge popularity of Rails makes
navigating and getting things done difficult.

It's my experience that Rails involves a lot more yak-shaving than it used to
due to the issues above.

I kind of wish there were a more conservative Rails community/blog/resource
that issued recommendations and documentation/tutorials about a more stable
way of doing Rails, making sure that the surrounding ecosystem is more stable
and has less entropy than the community at large.

------
bricestacey
This sounds like an old person ranting about the good ol' days when it's
probably a personal phobia against change.

I started learning rails just as 3 was coming out. I had made a site with
rails 2 and while googling around for help I found all these tutorials about
rails 3 and they definitely made everything much easier. Sure, if I had more
time invested in 2 (like this guy?) I'd be peeved, but I'm luckily more
aligned with the direction of rails rather than its past.

~~~
nthj

      This sounds like an old person ranting about the good ol' days 
      when it's probably a personal phobia against change.
    

Crafting software requires a fine balance between getting stuff done with what
you know and losing productivity because you're stuck with older technology.

Some of my best decisions as a software craftsman required change. Subversion
to Git, PHP to Ruby on Rails, VPN to Heroku, all helped me build great stuff
far more effectively. And some of my biggest problems came from attempting to
adopt new technology x instead of building something great quickly with what I
already knew.

I don't have a simple answer for maintaining that balance. It's hard. Being
aware of needing that balance is a great first step. Complaining about change,
though, seems to be the least productive response. Can I build something great
right now? No? OK, can I learn something new right now? No? OK, then some
downtime might be my best choice.

For right now.

------
trustfundbaby
This seems to be a complaint that Rails is a moving target, and that the
target is being moved in absence of a genuine need.

\------------------------

I think this is more my problem with the whole thing. The coffeescript thing
just bugs me for some reason, it seems a bit like the javascript helper, rjs
days and look how those panned out.

There's a Joel Spolsky article making fun of the way .NET releases come thick
and fast just to keep Microsoft developers constantly worrying about catching
up ... I just have this weird feeling that we're becoming the punchline in
that joke.

~~~
kristianp
The Spolsky article was about how Microsoft changes the whole framework on you
every few years. Which is why there seems to be some uproar about the Windows
8 information not mentioning .net at all.

~~~
trustfundbaby
The Spolsky article was about how Microsoft changes the whole framework on you
every few years

\-------------

Judge for yourself.
<http://www.joelonsoftware.com/articles/fog0000000339.html>

------
jrockway
Catalyst is the main web framework for Perl, and it's always been of this
design. No opinions, craft every little component exactly to your own
specifications. No default ORM, no default Javascript helpers, no default form
builder, no default templating library. Bring Your Own (or download from
CPAN).

Back in the day, I remember writing reddit comments and blog posts to explain
the relative popularity of Rails over Catalyst. It was usually along the lines
of, "people want to be told what to do. given a screw, they would rather bash
it in with a hammer than to read about what a screwdriver is." Posts like this
reinforce that point: people don't use Rails because they want to use Rails,
people use it because they're afraid of anything else. Rails gave them
everything that they thought they needed, and no easy way to back out of the
defaults. It was a comfortable world where you could never do something wrong.
Now that Rails is becoming a meta-framework like Catalyst, people are being
driven away because they have to think before they program, and they have to
customize Rails into the framework _they_ want instead of just using the
framework that dhh wants.

You can even see this in the Perl community; people are switching away from
Catalyst in favor of mini-frameworks that barely meet their needs, just
because they feel like the framework author has thought of everything and they
will never write a line of boring code again.

If only.

~~~
sunchild
"people don't use Rails because they want to use Rails, people use it because
they're afraid of anything else"

Nonsense. Almost doesn't deserve a response, but...people use Rails because
they agree with many of the choices made by the framework. Where they don't
agree, and are willing to absorb the cost to maintainability, they override
the framework.

~~~
eropple
...or because they think it's trendy, and don't have the breadth of experience
to know if they actually agree with it or not.

(Not you, but the legions of people who think they're web developers because
they learned RoR and never bother to learn anything else are pretty annoying.)

------
flocial
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. It's nice that they
aren't stuck with bad design decisions forever but when you go in for an
upgrade and you depend on some unpopular plugins, you can bet on pain and even
performance problems.

A major issue with some parts of the community is that some programmers think
that being rubyists automatically makes them elegant programmers even if they
don't have a clue about proper algorithms and that's probably why others call
them "hipsters". The general disregard for improving performance, inherited
from Ruby, is also something endemic from a while back. Sure programmer time
is important but how many successful companies have started with Rails only to
end up with a patchwork of Java, Scala, C++, etc. after lots of downtime and
growing pains.

Getting your app into production is also another pain point with the all the
dirty tricks you need to master, not to mention an array of lackluster choices
be it nginx, passenger, unicorn, rvm, REE, bundler, etc.

So with that background, I think the author's gripes are understandable but it
really doesn't touch on the undercurrent of discontent surrounding the current
ecosystem.

~~~
Volpe
> how many successful companies have started with Rails only to end up with a
> patchwork of Java, Scala, C++, etc. after lots of downtime and growing
> pains.

So how many? I've hardly heard of this as the 'norm' for growing companies on
rails... ? This sounds like 'Does Rails Scale' FUD.

Getting your app into production is not a pain point at all, services like
heroku, or engineyard have made this as simple as 'git push'. Which nirvana of
release management are you coming from where this is a 'pain point' ?

~~~
philwelch
Heroku exists because Ruby deployment is a major pain point and developers are
willing to embrace serious architectural limitations and high rates in
exchange for willing this problem away. I'm not down on Heroku at all, I think
they're brilliant, but "use Heroku" isn't a universally viable technical
solution to this problem.

~~~
Volpe
Okay, pre-heroku, Capistrano, which again was a huge simplification on other
deployment processes. How is rails more of a pain point than anything else?
Deployment is always going to be a task that is required. Rails has for a long
time had pretty good solutions to this.

I'm objecting to the parent stating that deployment is a serious pain point
for rails.

I would like to know what the 'simple' deployment stack people are comparing
the Rails stack too?

~~~
nasmorn
PHP. I used rails exclusively for webdev the last 6-7 years and I just now
worked on a PHP project. Deployment of PHP is the same as deployment of static
HTML. How is that not simpler than what we got in rails. For rails you need to
understand version control, webservers and scripting. For PHP you need to
understand copy.

For a serious project I think rails is great but you can't deny it involves
lots of abstractions which sometimes break down and then necessitate expert
knowledge that most people don't have.

~~~
bad_user

        Deployment of PHP is the same as deployment 
        of static HTML
    

Until somebody other than you does a database schema change or data migration,
and forgets to tell you about it. Or until somebody adds a new PHP dependency
(for resizing images or other shit like that) and forgets to tell the rest of
the team.

    
    
        For rails you need to understand version control, 
        webservers and scripting
    

No shit - those things are required in PHP too, unless you're building a
contact form.

    
    
        you can't deny it involves lots of abstractions 
        which sometimes break down and then necessitate 
        expert knowledge
    

Those abstractions save you from dealing with boilerplate or with repetitive
tasks that you can easily forget about. They are based on sane practices used
by experts. And those same abstractions are also present in mature PHP
frameworks like Symfony and not because the developers were bored to death and
just wanted to complicate your life.

Rails is not for contact forms. You are better off using PHP for that - but I
saw contact forms evolve into big piles of unmaintainable crap and developers
doing that because they thought a mature framework was too complicated and
haven't evolved since then - shouldn't have a place in this industry.

~~~
nasmorn
I truly understand the points you give and I like the fact that rails has a
proper process for all of this. Fact is though that 90% of projects that I
didn't start myself involve FTPing stuff to a server were all the developers
muck around writing over each others files.

Horrible yes. State of the art in most web consultancies also yes.

Passenger allows one to basically work this way with ruby too and it is sorely
needed because there are 'developers' out there that seemingly haven't worked
with Sourcecontrol in their entire career. If you need to give them access to
some templates it is nice if you don't have to bring them up to speed on git
first.

I wouldn't hire those people but I was forced to work with some.

My point: Allowing a less robust but easier deployment method is a pareto
improvement because I can now choose. It is also a path towards sane practices
used by experts when you start with a big pile of unmaintainable crap.

~~~
bad_user
I get what you're saying - and I think simple scripts uploaded by FTP are good
in many contexts.

However, Ruby on Rails was never good for shared hosting. It was never
designed or intended for this purpose. The deployment solutions available are
not doing so good in a shared hosting environment. Or at least, not as good as
PHP (nothing is as good as PHP in shared hosting).

The deployment story got a lot better when Passenger came along in 2008, which
is a self-healing and easy to configure server, capable of functioning with
Nginx or Apache in front. You wouldn't believe the shit you had to pull before
that for reliable servers.

Personally, I hate Heroku because their prices are for the moment too high and
I could partly replicate their environment on my own, using already available
tools. But such hosting services will become the norm as they are so kick-ass
and convenient; for instance I just received an invitation for Gondor, a
Heroku-like service for Python and Django.

------
tomfakes
I've been building a new app with the Rails 3.1 rcs for the last 3 or 4 weeks.
I still have no idea how to actually deploy into production in a way that has
a chance of working.

As far as I can tell, I need the V8 code built on my production boxes! That
seems insane, unless I want to switch to using node.js....

On my FreeBSD system, I still have no idea how to get V8 built correctly. I've
bailed on it for now and am running my 'production' server with the
'development' environment.

Remember, I'm not running beta software, I'm running a 'release candidate'.

When this works, it'll probably be great, but stick with 3.0 if you actually
want to make progress on your application.

~~~
cheald
You could compile coffeescript in development and commit the resulting JS
file. Automatically recompiled Coffeescript is fantastic in development, but
IMO, there's really no compelling reason to be compiling it production-side.

~~~
cheald
(I can't seem to reply to your comment, so replying here)

You could look at using something like a Git pre-commit hook to do that pretty
trivially. I personally use a rake task that compiles all my Sass and
Coffeescript to their respective CSS and JS files, then packs it into
minified-and-gzipped files with jammit, then commit the resulting bundle. I
end up serving pre-baked-and-concatenated assets and it works just fine.

~~~
bguthrie
This is the best way to do it, and using a continuous integration server to
emit a binary as the output of your build, as our ancestors in compiled
languages did in days of yore, is a good way to make it happen. You don't even
need to commit it; just use the tarball (or whatever) as the artifact of
deployment.

------
joelmichael
I've been coding in Rails since pre-1.0, and while some decisions have annoyed
me, I am ultimately happy with the direction Rails has gone. It keeps Rails at
the forefront of web technology.

------
felipemnoa
What is happening is that the language/framework continues to grow/mature/(get
older). Not sure if that is a good thing. My guess is that as more Use Cases
are being implemented a lot of the early simplicity is being lost. As it gets
older it starts to accumulate good stuff and bad stuff. Just like any other
language. I think most languages go through this.

<satire> My guess is that eventually there will be another golden boy and a
whole new generation of programmers will swear that it is the best thing since
the invention of the wheel while at the same time complaining of all the
baggage and bad decisions made in Ruby/Rails and ridiculing anybody that still
uses it. Meanwhile the Ruby/Rails developers will look and scratch their heads
wondering what all the hate is about. After all, Ruby/Rails gets the job done
even if it is not perfect and anybody that is a language fanboy does not have
a brain. After all, a programming language is just a tool. A whole generation
latter the cycle repeats itself with yet another golden boy language. Sigh! To
be young and stupid. Those were the days. </satire>

~~~
wtn
There was another golden boy, it was called Merb. Then their team joined Rails
and started refactoring things…

Members of the Rails core team recognize that growth has limits. They are
looking for ways to reduce the stack to improve the design and make things
more performant. See Aaron Patterson's RailsConf 2011 keynote.

------
localhost3000
I don't get it. I found rails 3 exceptionally easy to learn. Sass is a dream.
It's what css should have been. Haml has its annoyances but in general is
great. Both of these are also exceptionally easy to learn. I love where rails
is going.

------
chrismealy
I stay caught up on everything in railsland just by watching Railscasts. I
can't deny that it's chaotic right now but I'm enjoying the rapid progress. I
like the little things, like js and css moving from public to app.

Also, I think the switch from prototype to jQuery will help beginners.

------
dev_jim
I could never wrap my head around the Rails world. I enjoy the elegance and
simplicity of Python/Django. There's a lot less 'holy shit magic' moments.

------
damoncali
The problem is not that rails has gotten too difficult to pick up (although,
I'd agree it's not as easy as it once was). The problem is the documentation
is lagging behind the development - in some cases pretty severely.

But what do you do? Slow down? Not sure that's good either.

------
davidw
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.

All in all, I still think it's the best thing going in web development today
for what I do, and am not contemplating alternatives.

------
jmtame
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.
Lesson learned: stay away from Rails release candidates. But I downgraded to
Rails 3.0.8 because 3.1 was just more of a hassle starting out. Maybe I'm
doing something wrong, usually when I'm fighting the framework it's a sign
that I don't fully understand something. I loved Rails 3.0 when it was
announced, but I share the same sentiment as the OP re: 3.1 at the moment.

~~~
joevandyk
None of the heroku stacks support mysql.

~~~
jmtame
Right, though I think I was more hesitant on upgrading to Cedar--probably
could have done that without any problems, but ultimately I just didn't like
3.1rc. My major gripe was with the assets pipeline.

Edit: are images not supposed to be served through /assets? They were loading
too slowly for me, that was my major complaint.

~~~
joevandyk
No, images are not supposed to be served through /assets. Put them in /public.

~~~
dhh
rake assets:precompile will automatically copy images from app/assets/images
to public/assets.

The asset pipeline can be a development concern only, if you want it to.

~~~
huetsch
I love the 3.1 rcs but using 3rd party css files that reference images are
kind of painful to deal with in conjunction with the asset pipeline. I find
myself making awkward directory structures in the vendor directory to avoid
making modifications to 3rd party css libraries (like jQuery UI). I'm hoping a
lot of this will go away when those things are packed into gems that I can
just put in my Gemfile and forget. I'm sure Compass and Blueprint will get to
that point pretty quickly but I'm not sure that something custom-generated
like by jQuery UI ThemeRoller will ever be smooth to set up.

------
audionerd
If you're hesitant to be an early adopter (AKA "guinea pig") Rails 2.3.x is
very stable, and most of the useful plugins in the Rails ecosystem are still
maintained for Rails 2.3.x.

Many big names are still on Rails 2.3.x, too. Forgive me if I go astray here,
but GitHub and DocumentCloud are two examples that come to mind.

~~~
dhh
Staying on Rails 2.3.x is certainly fine for existing apps, but starting a new
app on 2.3 is a very bad idea. You're setting yourself up for a lot of
headache for the inevitable migration. Let alone depriving yourself of all the
wonders of Rails 3.

That being said, nobody is forcing you to jump on a release candidate. Just
use the latest released, stable version. In this case Rails 3.0.x.

------
swampthing
I think the author is conflating two issues - (1) learning Rails and (2)
keeping up with the latest developments in Rails.

I agree with the author that (2) is getting harder - but this is the price you
pay for improvement.

I disagree that (1) is getting to be overly difficult. By and large, the
changes to Rails 3 and Rails 3.1 make it easier for developers to do more
advanced things with Rails. If you just look at the simple tutorial
applications that newcomers to Rails are starting out with, I don't think
their complexity has increased very much from Rails 2 to 3 to 3.1. Yes, they
are different from version to version, but this doesn't matter to the
newcomer.

TL;DR - the framework has more functionality, which makes it more difficult to
learn the entire framework, but it is not significantly more difficult to
learn how to accomplish any given task.

------
bstar
My brother, who is a novice programmer, picked up the rails basics in a couple
weeks (with some help, of course). He was able to create the app he set out
to, going from zero experience to a fully functioning app in 2 months.

If you are having trouble with rails, it's for two possible reasons... 1) you
won't accept that it's opinionated software and throw out your preconceptions
or 2) you're just not trying hard enough. The amount of books, screencasts,
tutorials, podcasts out there for rails is just insane. I'm completely jealous
these things weren't around in '06 when I started.

Edit: Should have mentioned that he did the Michael Hartl screencasts/tutorial
(<http://ruby.railstutorial.org/>)

------
elrodeo
> But we’re making it harder and harder for anyone to join the club from
> scratch.

That's a brilliant point. Some time ago I wanted to try out RoR to create a
fast prototype. It turned out, that if you need just one prototype and if you
don't know RoR, you'd be way faster if you use things you already know or just
read the short Sinatra manual instead of spending weeks of learning only to be
able to START the development.

------
nfm
I agree that the barrier for entry to Rails is quite high. To really get into
it, you might have to learn:

* A new language

* A new framework

* A new programming paradigm

* A new set of libraries

This is going to be really hard if you're currently a spaghetti coder. Will
you learn a lot? Will you become a better programmer? Will you enjoy coding
more? I say yes!

~~~
andrewflnr
Generally, I agree. But a spaghetti coder is going to have trouble no matter
where they go. For such a person, moving to a new framework might not actually
result in much valuable learning. If they were open to that, would they still
be a spaghetti coder?

------
Itf
As a beginner who started trying to learn rails from 1.2-2.0 I just wanted to
say that Rails was never simple with all its magic and metaprogramming. "Blog
in 15 minutes" is about being productive.

Defaults, conventions and DSL's are for less code only. You still have to know
the rules. (Both DSL and what's underneath it.)

Javascript is not simple - so we have CoffeeScript. HTML isn't - there's HAML.
(1 line of code to add it to Rails 3.1) Web applications are now more complex
- client logic finally moved to /app folder.) We can still enable old routing
(uncommenting one line).

But you have to learn bundler for dependency management, know application.rb
configuration options, etc.

So I don't get what 'simple' about that technology stack. It's DRY and rather
flexible, but not simple.

------
rimantas
Good things are happening. I am glad to see more attention to front-end stuff.
What's so scary there? I am using SCSS and CoffeeScript outside the Rails too
(for WordPress themes) and I do pack my JS and compress my CSS. This is how it
should be done and I am glad to see it is default in RoR.

------
stretchwithme
Over time, Rails changes to make it easier to deal with the complex needs of
web applications.

Part of that is changing things to make things more orderly, so you can
actually find your way around a complex application without too much wasted
effort. That places demands on developers, especially when migrating, but
makes it easier in the future.

The amount of power you can weld in the present is dependent on how much
capability you acquired in the past. You can always enter a battle with your
bare fists and no learning curve, but if someone gives you a free sword,
learning to use it before the battle is more likely to lead to victory.

This is not learning for the sake of learning. But even learning for the sake
of learning grows your ability to learn.

~~~
jamesbritt
_Over time, Rails changes to make it easier to deal with the complex needs of
web applications._

Why? Why is _Rails_ changing to handle this, instead of add-ons, plug-ins, and
gems changing?

~~~
dhh
Because that's always been the mission. Have a solution for most people, most
of the time. With the target being building full-fledged apps ala Basecamp
(that touches on all parts of web tech).

So we've been pursuing this mission for 7+ years. We've just gotten better at
it.

------
pdenya
My biggest issue with rails was more getting my development environment setup.
Constant gem compilation issues, I spent hours resolving them. Aside from that
I haven't had much trouble stepping into the language or the new environment.

~~~
getsat
> Constant gem compilation issues, I spent hours resolving them.

While this is common, it doesn't really have anything to do with Rails itself.
I can't think of any Rails dependencies that have mandatory native extensions
off the top of my head.

~~~
jamesgeck0
If you want SQLite, there's that. Not mandatory, but pretty useful.
Fortunately there are the jdbc-sqlite3 and activerecord-jdbcsqlite3-adapter
gems for Jruby.

~~~
getsat
Ah, good point, I forgot that Rails defaults to SQLite.

------
porras
I don't think Rails never was about been quick to learn. It was about being
easy to use (once you had bothered to learn to use it, or at least the
basics). I don't think that has changed.

------
stephenhandley
lol this is just some pay your dues nonsense. "You will love rails if you
begin at the start like we all did"

<http://pine.fm/LearnToProgram/> (probably not relevant for HN)
<http://ruby.railstutorial.org/ruby-on-rails-tutorial-book>
<http://devcenter.heroku.com/articles/quickstart>

------
tomkarlo
I do agree that defaulting to have SASS and Coffeescript on unecessarily
increases the learning curve for new adopters. Along with HAML they're
fantastic technologies but in many cases you're asking people to learn Ruby,
Rails, HAML, SASS and/or Coffescript all at once now.

Make the base setup as such that it minimizes what they have to learn to
achieve some success, and let them turn on technologies such as
HAML/SASS/Coffeescript later on once the cognitive load of switching to Ruby
and Rails has decreased.

~~~
Volpe
> many cases you're asking people to learn Ruby, Rails, HAML, SASS and/or
> Coffescript all at once now.

As oppose to Ruby, Rails, ERB, CSS, and Javascript?

\- CSS is valid SASS \- Coffeescript is closer to Ruby/Python than javascript
and is possibly an easier learning curve (if you don't already know
javascript) (You can use javascript if you want as well).

~~~
tomkarlo
ERB is extremely similar to PHP and regular HTML. CSS and Javascript will
already be familiar to someone who has done development in other languages.

Call it FUD (despite the fact that I do all my development in Rails) but the
issue isn't the reality, it's the perception. You make these the defaults for
Rails and/or you write the new user tutorials in them, and you increase the
perceived difficulty of starting to use Rails. You make them options that more
advanced users can choose to turn on, you reduce that friction. That's all I'm
saying.

To clarify: I'm pro HAML, SASS/SCSS and I like the idea of Coffeescript even
though I'm not using it. I just think that some of the way the've been going
with Rails is not great from the perspective of growing the adoption of the
platform.

And yeah, my mistake about HAML. I've been using it so long with Rails I've
forgotten it's not a default.

~~~
Volpe
I find the quality of javascript produced through coffeescript is much higher
than devs who proclaim competency with javascript. Even the simple stuff
(using closures properly, and '===')

I've found a lot of devs while they have been 'trained' in C/Java/Pyhon/Ruby
have kind of just picked up bits and pieces of javascript without a really a
firm understanding of how it works or it's idioms. Coffeescript on the other
hand, has a very (python-esque) prescriptive set of idioms that produces very
decent javascript, if you don't follow the idioms, it doesn't compile.

For an absolute "i know nothing" I think the Ruby, Rails, HAML, SASS,
Coffescript is a smaller learning curve than ERB, CSS, Javascript.

------
grandalf
I think it's quite telling that DHH frequently tweets his opposition to
aspects of what is happening with Rails, and that Yehuda quit the core team.

In a world where some time on the core team can land someone $300K per year in
salary + speaking + book deals, there is bound to be this sort of chaos. I
view the push toward agnosticism as a misguided attempt to be the "one true
framework" and also to salve the egos of those whose decisions and work are
being undone.

~~~
bradleyland
"I think it's quite telling that DHH frequently tweets his opposition to
aspects of what is happening with Rails, and that Yehuda quit the core team."

That's a bit disingenuous, isn't it? Yehuda was offered an opportunity that
makes sense for him. It's not as if he's abandoned the Rails community in a
flurry of drama.

DHH is the kind of guy that is going to speak his mind, and if you're wise
you'll at least listen to what he has to say. If you find yourself agreeing
100% of the time, it's time to find different company.

~~~
dasil003
Yeah, did Yehuda quit so much as fade into the background? He's clearly a guy
who likes ambitious projects. His contributions to the Ruby community have
been notable because of their challenging nature. Merging Merb and Rails was a
gargantuan project, getting a large established framework to accept that level
of outside input was impressive. The level of refactoring that went into it
went against prudence, but I can't argue with the results. Rails 3 is awesome.

Similarly Yehuda and Carl spearheaded Bundler development. They bit off a
massive problem that touches anyone doing large scale ruby development and
through sheer force of will hammered out a powerful solution that solves the
majority of common issues in a relatively straightforward manner. There's lots
to argue with, for sure, maybe it's over-engineered, maybe they didn't work
closely enough with RubyGems core, etc; but at the end of the day they solved
a problem that was too hairy for the average dev to have much hope of solving.

Yehuda's been there, done that. He doesn't need to stick around and be Rails
core forever, there's plenty of new blood to pick up the torch, and bigger
problems to solve elsewhere.

------
ethyreal
i found the ever changing world of rails intimidating when i first started and
that was in the wonderful world of 1 moving to 2 but at the end of the day all
you really need is to get the same version of rails that your book/tutorial
covers and stick with it..

------
pspeter3
I used to be a rails developer. After rails upgraded to 3.1, I switched to
Padrino and haven't looked back

~~~
mhartl
I'm confused. Rails 3.0.8 is the current version. Rails 3.1 is still in beta.
What's in the beta release of Rails 3.1 that caused you to leave? A couple of
_defaults_ have changed, but valid Rails 3.0 applications can be upgraded to
3.1 with a minimum of effort.

~~~
pspeter3
When I tried the Rails 3.1 beta, I had issues with getting Mongoid and various
other dependencies working and could not get it to run. My Rails 3.0 app
completely broke. I might be an edge case though.

~~~
mhartl
I'm preparing a screencast on upgrading the Rails Tutorial sample application
from Rails 3.0 to Rails 3.1. Maybe you'll find it useful. Subscribe to the
news feed (<http://news.railstutorial.org/>) to be notified when it's ready.

------
eagsalazar
(1) Regarding the article: boo f-ing hoo. (2) Why Rails 3.1 _actually_ is
blowing it: There is no way to turn off concatenation of js/css files in
development! WTF? Have these guys ever developed a client heavy app before?
That is a total non-starter. I love how the entire goal was to make js a first
class rails citizen but you can only debug these files in firebug as one giant
file! What a f-up!

~~~
dhh
This has already been solved. Just add ?debug_assets=1 to any url and it'll be
rendered with individual include lines instead of concatenation.

We're building client heavy apps, though, and haven't felt a need for it. But
now it's there if you need it. Enjoy!

~~~
eagsalazar
That is great news! Rails 3.1 otherwise has many great features.

However, I'll be honest, I find it completely unbelievable that you don't have
a problem debugging in one huge js file. I guess when using coffee script the
connection between what you are debugging and what you are editing is already
completely severed so maybe at that point it doesn't matter anymore.

------
OstiaAntica
It feels like Rails is slowly dying. It doesn't have the broad penetration of
PHP, and most folks taking up a scripting language today choose Python.

~~~
cantbecool
I disagree. With the proliferation of new tutorial books and screencasts in
addition to more and more web developers choosing Rails, it's far from dying,
it's actually in growing at rapid rate.

~~~
ssmoot
Where do you get your numbers for that? I'm genuinely curious. I had the
opposite impression; but I don't have any numbers at all to back it up.

~~~
cantbecool
Just anecdotal evidence. I'm just seeing an increase of job postings online,
but after doing research, the term 'Ruby on Rails' is actually declining on
Google trends.
[http://trends.google.com/trends?q=ruby+on+rails&ctab=0&#...</a> I thought at
least there would be a slight bump after Rails 3.0 release, guess not.

