
Rails Is Not For Beginners - oscar-the-horse
http://www.horsesaysinternet.com/code/rails-is-not-for-beginners/
======
dhh
If you optimize a framework for beginners, you're optimizing for learnability.
That's great for the first few days or even weeks of learning. But once you're
past that, it's not so great. What you care more about is the usability of the
thing once you know it. There are plenty of cases where learnability and
usability are in conflict. Letting learnability win is a short-term relief.

If you on the other hand optimize for usability, for making things simple and
easy to use for someone who understands the basics, you'll often end up with
something that has great learnability as well. Maybe not as much as could be
achieved as if that was your only goal, but plenty still.

The other aspect is whether you as a framework designer are designing
something for yourself and your peers or if you're trying to dumb things down
on behalf of beginners. In other words, designing for what you think beginners
might find easy in their learning phase. That's really hard to do. Most
technology I've seen designed in such a master/apprentice fashion sucks.

Finally, when you're comparing complexity, it's generally more helpful to look
at the complexity involved with completing an entire task. Comparing
complexity of "hello world" tells you little about what the complexity is
going to be like developing a complete, modern web application from database
migrations to XSS/CRSF protection.

That's where learnability and usability are again in conflict. Yes, it's
harder to learn a framework that has answers for things like "how do I migrate
a database once I have data I care about", or whatever feature you want to
focus on, but once you hit that problem, you'll be glad that it's there and
find the solution less complex than stringing something together from tons of
separate parts yourself.

All that being said, I think Sinatra is wonderful. So what if it's not a fit
for building a whole Basecamp or Github? It's great for teaching someone the
basics of how HTTP works and it's great for smaller surface apps or for
smaller, isolated parts of bigger apps.

~~~
bodegajed
I beg to disagree. Learnability and usability can get along together. Good
examples are Jquery and Cakephp. Both have executed this very well from
producing well written and well maintained documentation then add a good
amount of plugins that is contributed by the community.

For example, in cakephp we have this cook book <http://book.cakephp.org> which
the quality of the content surpasses every cakephp book on amazon.

So, like apps "simple & feature rich" can get along together like
"learnability & usability" can get along too. It just needs more work.

~~~
swq
The problem with cakephp is that every book written on this subject surpasses
the quality of the framework itself. cakephp is easy to learn, but for me it's
unusable in the long run. Easy stuff get's even easier, hard stuff get's
harder. That's exactly what David meant. If you trade everything for
learnability, it's not usable.

~~~
adriand
That sums up my experience with cakePHP too. I don't know what's happened with
this framework in the last couple of years, but when I was first learning
Rails and enjoying it, I used cakePHP for a big project because I knew PHP
well, and didn't yet feel comfortable with committing to using Rails for it.

That was a decision I regretted many times. The hoops I had to jump through to
deal with complex database queries were ridiculous. The difference in quality
and robustness between ActiveRecord and cakePHP's ORM (at that time, anyway)
were pronounced, with AR coming out way, way ahead.

There's no doubt, in my mind, that if you are going to take on a large,
ambitious web application project, you'll be better served by Rails.

~~~
josegonzalez
Yes, CakePHP's "ORM" isn't a real ORM - it was built when Objects were
awesomely broken in PHP4 - but I've actually found it much more usable than
the current state of Ruby's ActiveRecord/Datamapper. Manipulating arrays to
get just the SQL you want is sometimes annoying, but for the queries that you
honestly can't get out of the ORM in CakePHP, it's also likely you wouldn't be
able to do the same in any other ORM.

You'll also have to note that both frameworks have progressed significantly in
the last few years - CakePHP actually just released a new major version, as
did Rails a few months ago - so your experience a few years ago - was this in
the 1.1 era - would just be indicative of the framework's beginnings, not
where it currently is.

Feel free to message me with your thoughts if they still conflict; I'd love to
hear the other side of the story since improving CakePHP as a framework helps
not just my ego, but other developers who are using CakePHP to make a living
:)

------
fleitz
The size of the code base has nothing to do with whether something is for
beginners. Beginners don't read the code to find out what something does, they
read the docs and the tutorials. It's mostly about tutorials to get them
started, and quick iteration so they can see the fruits of their progress,
combined with being a solution to a problem they have.

Excel is a great example of something that can get beginners involved in
computing. Huge code base, but lots of tutorials, and solves problems people
have.

If people's problems were along the lines of needing a website that can say
"hello world" then Sinatra would be perfect, if their needs are more along the
lines of CRUD app with web and iphone front ends then rails will likely serve
them better.

I've been dealing recently with a guy who asked me for some tutorials on
XCode, although he absolutely cannot code with Storyboards and Interface
Builder he's fully mocked out apps that he wants developed. It's that kind of
thing that gets people coding.

~~~
jamesgeck0
> Beginners don't read the code to find out what something does, they read the
> docs and the tutorials.

Until the docs and tutorials fall short, or something unexpected happens, or
they want to see why something behaves the way it does.

------
bphogan
I teach Rails a _lot_. I've ranted and raved for the last year how Rails 3 is
much harder for a beginner to grasp than previous versions, but the things
that make it difficult for the beginners are not specifically Rails itself.
Usually the difficulties come from a few specific things:

First, it's the absolutely fragmented ecosystem, made up of everyone who has
opinions on the best way to do Rails development. "You need this gem, and this
gem, and ZOMG you're using that library? So last week! Use this one!"

Sure, it's funny to exaggerate that, but if you joined a community, you'd
probably look around. A person who does daily work in Rails is going to have a
preferred development stack. They may write tests with Rspec, they may use
Cucumber. They may even use CoffeeScript. And they'll tell a newbie that they
should too.

But a wide-eyed developer who thinks Rails will solve all his or her problems
will get freaked out at all of the options available.

When I teach beginners, I don't teach RSpec or Cucumber, and I try to even
avoid talking about Bundler. I stick with the core components of Rails. I stay
on the happy path. Rails has all these hooks for experts that you can unravel
after a few months (or years) of daily work. But a beginner can understand
ActiveRecord, controllers, and views easily.

I love the Dreyfus Model. It basically says newbies don't need choices in the
beginning. They need clear instruction, clear tutorials. Once they master
those, they can move on to reading the docs, exploring the options, etc.

I've been pretty successful teaching Rails to folks who know how to program.

Where Rails falls flat on its face for the beginner is when the beginner
doesn't know SQL or HTML. That's a whole different ballgame. Then something
like Sinatra is a nice slow introduction.

------
mseebach
There seems to be a silent disagreement on what the goal of a beginner is: Is
it to become a better programmer or is it to get a working app with the
minimal amount of work?

Sinatra seems to be better for the former, Rails is better for the latter.

I'm partial to thinking that the former goal is the more noble. But I'm also
immensely proud to work in a field that allows anyone with little more than
motivation and patience to apply the immense power of computing to whatever
itch they need scratched.

One of my favourite consulting jobs of all times was when a friend of a friend
asked me to come in: They knew _just_ enough of a certain PHP CMS to build an
online history textbook, which they'd then gone on to sell to, oh, well, every
school in the country. The traffic was strangling them and only just knew
enough that they knew they didn't have a clue what to do. A week and change
later, upgraded hardware and the clumsy CMS search engine replace by Solr,
they were flying.

If they'd started out with the equivalent of Sinatra (essentially plain PHP),
I'm not sure they'd have launched at all.

------
Argorak
Rails is definitely not for beginners and the code size is an indicator -
there is a steep curve to understand everything that Rails 3.1 uses per
default - especially the (initially) arcane handling of javascript runtimes to
compile coffeescript...

But: Sinatra ain't beginner-friendly either, I also don't think thats the
goal. Sinatra is basically a minimal base framework for matching HTTP
requests, generating responses and building a Rack stack around the base
class. But it doesn't give you a lot beyond that. As such, it requires deep
knowledge of how to use HTTP and Rack to do more fancy stuff.

I also don't think that there are "beginner-friendly" frameworks beyond the
most simple ones. The problem is that each feature that a framework encodes
also requires the user to learn how it works. Most beginners don't even
understand the benefits, drawbacks and best practices when it comes to HTTP -
how would they understand all the things that Rails has amassed over the
years?[1]

If any, I would recommend pure Rack: its a one page specification that can be
read and understood in an hour.

As a shameless plug: if you consider Rails too feature-laden, consider Padrino
- it is definitely worth a look. (Disclaimer: i have commit access to the
Padrino repository and sometimes use it)

[1] I don't consider users coming from other frameworks (even in other
languages) as "beginners" - usually, they already know the domain language -
for example what CSRF is and what Rails does against it.

------
mmahemoff
Although Rails code can be straightforward if you stick to the conventions,
many real-world apps call for something more than that. So in practice, it's
usually necessary to perform at least some level of metaprogramming, or at
least some more exotic configuration.

Also, if you're using Rails library, you'll notice the hipster aspect of the
Ruby/Rails community, which is to say many libraries are active for 1 or 2
years before the developer gets bored and someone else comes up with a hotter
alternative. That's cool, it's quick evolution, but it also means real-world
Rails developers have to spend a fair amount of time dealing with libraries
that are either no longer maintained or are not yet mature.

~~~
sebilasse
I Disagree.

I've built many real world applications. Very complicated ones and not just
your average CRUD apps. I never had to do exotic configurations or
metaprogramming craziness.

If a popular gem is replaced, I see many times, that the API of the gem,
mimicks the old one, or detailed migration tutorials will be delivered. So a
new gem is often similar to a major version bump.

~~~
dasil003
I don't know if labeling rapid evolution as "hipster" is quite fair, but the
underlying point is true. Have you gone back to a update a Rails project that
is 3 years old or more? I have, and it's significantly more hassle in general
than going back and updating a PHP project that is 10 years old.

Personally I think this is a small price to pay for a framework that stays up
to date and still releases forward-thinking features on a regular basis (Rails
modularization in 3.0 and the asset pipeline in 3.1 are amazing features that
an emphasis on backwards compatibility could have made more difficult), but
let's acknowledge that it is not an unmitigated win in all aspects.

------
fingerprinter
I usually say this about the types of webframeworks they are:

Rails - > great for intermediate people who see benefits it brings. Great for
pretty straight forward projects for beginners that can follow a book.

Sinatra -> Great for beginners to "just get something working". Not great if
someone needs everything decided for them. Awesome for advanced people.
Awesome for non-standard projects.

Padrino (Why don't we hear about this more?) -> kind of the sweet spot between
the two. I honestly think that Padrino should rightfully start taking
mindshare. I don't know why it hasn't.

~~~
rman666
People get Padrino confused with Audrino and think they're gonna have to hack
hardware. That scares them and they move on :-)

------
danneu
I'd tout Rails as more beginner-friendly than Sinatra. Much more beginner
friendly.

Once a beginner gets past the trivial usage of Sinatra, where does he go next?
Rails already has everything set up for you. If you want to implement
something, you can just google it or find a tutorial or Railscast that can
scoot you along. Or a free online tutorial that shows you how to test and
implement a nontrivial application from scratch including testing. Or just
dive into the massive community.

------
dasil003
This article rubs me the wrong way. Rails _is_ good for beginners because it
has more tutorials than probably any other web framework ever. That's the main
metric that matters for a true beginner.

The fact that Rails has a ton more features that will take longer to
understand than Sinatra is neither here nor there. If you don't need those
features than Sinatra is the obvious choice, if you do need them then Rails is
the obvious choice. This is orthogonal to the user's experience level.

------
hmans
By the way, "beginners" wanting to get started building Ruby-based web
applications should have a look at Serve (get-serve.com). It's not a framework
per se, but if you're coming from PHP, it will probably get you started with
the Ruby ecosystem pretty fast (and well), since it allows you to just create
an .erb file and add inline code.

(Which is what most PHP people seem to want initially - you know, before that
magic thing happens where they realize that real applications need structure.)

------
Tichy
Sinatra is cool. However, then I need to start thinking about how to integrate
database connectivity (configure it, set up controllers, what not). I need to
worry about XSS attacks, and a zillion other tiny details that go into a web
app. So I often end up choosing Rails anyway, because they made a lot of
choices for me already that I frankly don't care much about making myself.

Still, Sinatra is great for a lot of small web projects.

------
andrewvc
I use both rails and sinatra.

Sinatra is great for small things and beginners.

However, if you're going to spend all day writing web-app code, learning rails
pays off HUGELY. It's the full package for modern web-app development, with
massive productivity bonuses at the expense of a higher upfront.

~~~
ichverstehe
Sinatra, Cuba[1] etc. can finely be used for larger apps as well. It may
require some more discipline upfront, but the notion that those are only
usable for small hacks is moot. In fact, I have found it easier to introduce
new coworkers (without prior knowledge of either) to medium sized (5k LOC)
Sinatra apps than Rails apps the same size.

[1] <https://github.com/soveran/cuba>

~~~
InfernalH
Everytime when you try to build bigger app with sinatra, you will probably end
up building half-rails. So it the end it doesn't make much sense just the time
it was needed to put in to find and require additional libs

------
ericb
It occurred to me while interviewing the other day--web development is not
really for beginners anymore. To do web development without endangering
customer passwords, data security and credit card numbers now takes very
substantial knowledge, and it is knowledge that some beginners won't realize
they need.

If you don't understand how to prevent sql injection attacks, cross site
scripting, why SSL by default for web apps is needed, and whole host of
things, you should probably stay away from anything more serious than flat
html.

~~~
SomeOtherGuy
It never was for beginners. All those problems have been around since the web
has, and beginners have been making insecure crap ever since the first perl
cgis.

~~~
ericb
Perhaps I'm dating myself a bit here, but there was a time when there was no
such thing as an "e-commerce app" and no wi-fi to eavesdrop on. Black hat
hacking has evolved also, so although some techniques have always been
possible, new vectors have opened up over time as they are discovered and
disseminated, and I would suggest the corresponding knowledge burden needed to
enter the arms race for a developer is higher now. Also, the tools have
evolved in such a way that the barrier to entry is lower and lower. For
example, FireSheep.

~~~
SomeOtherGuy
Of course there was a time before ecommerce apps. That would probably explain
why I was talking about the very first perl cgis. While there's a lower
barrier to entry for people to exploit security holes, there's also far more
targets. Automated tools to go around exploiting the latest holes in "insert
shitty PHP app here" aren't an issue for web developers who are writing their
own apps. The security issues that impact web developers are the same as they
have always been for all kinds of developers, input filtering, escaping
output, etc. Web developers have always needed to understand basic security
issues, it is just that 99% of web developers historically have been
completely incompetent. This does not appear to have changed recently.

------
tmroyal
I am a beginner. I am trying to learn Rails. I am finding it difficult because
the tutorials tend to be walkthroughs of creating very specific types of web
apps, with understanding of the concepts being offered a side effect. I often
have questions about why and wherefore of certain decisions tutorial authors
make. My only recourse is the documentation, which is too large for me to
maintain my excitement for too long, especially with my busy schedule.

I do not get excited about the sudden ability to make things because I have
been making things (not webapps) for some time.

I have had much more success learning Sinatra. While the tutorials are
similarly designed, the reduced reliance of magic makes it easier for me
understand the purpose of the commands given. There are no files that are
generated for me in places that I have to go looking for that do something
important that I don't have to think about (but I do have to understand.) In
fact, Sinatra has helped me to understand Rails in hindsight.

I think the issue is that the tutorials I have looked at tend to be trying to
sell Rails as an awesome tool to make things. This has emphasized ease of use
over understanding of concepts. You can contrast these tutorials with books or
tutorials for any programming language. Books on programming languages tend to
be more abstract and while they limit one's power at first, they enhance one's
awareness in the end. Tutorials on Rails do the opposite for me.

Maybe I should have just bought a book on Rails (like the tutorials said.)

------
teyc
I read the article, and while it is easy to see where he is coming from, I
remembered the WTF the first time I encountered web programming more than a
decade ago. The idea of GET vs POST didn't make any sense at all to a person
who wanted to put something on the screen and capture its value.

Some of these higher level frameworks dispense with get and post. This means
that to an old timer, there is suddenly nothing left to build on, and this is
why the learning curve appears high again.

------
pistacchio
the fact that rails is not for beginners is true (and main developers say so),
but suggesting for beginners a smaller framework that gives you less and hence
requires you to do more, know more and make choices that rails has done for
you is simply nonsense.

------
rhizome
Weirdly, this post has a Shyamalanic twist where it ends up being an
exhortation to use Sinatra.

------
kingkilr
What does the number of lines of code have to do with whether it's appropriate
for beginners?

~~~
gabyar
The number of lines of codes, in this case, speaks to the amount of features
in the framework. Rails is harder to __fully __understand than Sinatra because
there are many, many more features, and it's possible for a beginner to get
lost in, or confused by, all those features.

~~~
kingkilr
Well, it's harder to understand _all_ of rails, because it has more features.
That's a fair claim I think.

However, the question is: Is it harder to understand the subset of rails that
does what sinatra does, than it is to understand sinatra as a result?

------
choxi
That's why we chose to start with Sinatra with our interactive courses on
<http://www.trybloc.com>. It's an easier transition to learn Sinatra which is
conceptually much simpler.

~~~
spacemanaki
FYI There's a bug in the REPL on your Ruby basics course: if you enter more
than a handful of lines the cursor runs down the page while the actual input
is at the bottom of the JQuery console...

------
bad_user
I have a harder time using Sinatra because I never know where to put things.

Also, the biggest problem with learning Rails is the Ruby language. After you
learn the language, switching from Sinatra to Rails and back is not
problematic.

~~~
mnutt
Yeah, Rails gives beginners a big advantage by generating a huge scaffolding.
It clears up a lot of ambiguities about where things go, and as a beginner it
lets you explore different things that you can do in Rails.

~~~
guard-of-terra
As a novice developer, I absolutely loathed scaffolding (IDE-generated header
and source files) because I could never understand why all the code got there,
how do those files relate and what does it do.

I tried to learn COM once but gave up essentially because I could not find any
docs not falling back on IDE code generation (and that code was huge and
absolutely opaque).

I always loved tools which let you to type in a small program from the scratch
and run it. So, perhaps, sinatra is the way to go for beginners.

------
krsgoss
I've enjoyed using Rails for a long time now and still do. That being said,
I've started steering towards Sinatra more given the minimal startup time and
speed. The biggest gripe I have with Rails is the long startup time. It's a
real drag on test driven development. Waiting close to 30 seconds per test run
while the framework boots really sucks.

------
nagnatron
Rails is not for beginners because if you aren't good at OO design it's
extremely easy to write horrible code that does a lot.

------
geoffroy
I've just getting started with Rails and what I miss the most is good
documentation like CodeIgniter. But other than that that's an impressive piece
of software!

------
john2x
PHP is pretty good for beginners. Right tool for the job?

------
amorphid
I think beginners can struggle through Rails. Learning Rails is much less
difficult that learn best practices for programming in general, in my opinion.

------
southpolesteve
My response: <http://www.southpolesteve.com/rails-is-for-beginners/>

------
geoffw8
I am the profile this article talks about, and I can assure you Rails is
perfect for beginners. Sinatra confuses the hell out of me, admittedly and I
think the key - less and less so every day.

I also taught, being a total noob myself, my best friend how to code Rails in
2 months. He doesn't even know HTML, or how to make/compile something. But he
can code Ruby/Rails. And I mean Ruby, not just plug together a scaffolded app.

So yeah, I'm not so sure I agree with this.

------
taybin
Implementing your own version of Rails is left as an exercise for the reader.

------
alvinsj
rails is indeed make things easy, and sinatra is indeed easy to learn.
however, imho they are in different leagues, just like different code patterns
you are going to make use of.

------
hmans
Web application development is not for beginners.

------
verroq
>rails is hard, let's go shopping.

------
nknight
I'm actually starting to think there's something to be said for letting each
generation of programmers grow up simultaneously with a hot new framework. It
encourages learning through experimentation, lets them make the mistakes we
all have to make, helps spread new ideas unbounded by the received wisdom
(many of which will be stupid, some will have important influence for decades
to come).

In the end, you get a bunch of developers that are both comfortable with a
modern framework, have some understanding of the growing pains of new,
complicated systems, and are ready to bring fresh ideas to more mature parts
of the industry.

The contrasting mentality of sticking to what we already know is "good enough"
leaves developers dull and uninspired, less equipped to think outside the
"rules" inherited from previous generations that came from solving problems
that look a lot different when you examine them 10 years later.

All of which is to say, Rails probably isn't for beginners anymore, and it
shouldn't be, but I don't think trying to substitute a simple framework that
explicitly avoids becoming complicated is necessarily what the doctor
ordered...

------
cq
I can't read the font on this webpage, it is making my eyes blur.

~~~
steauengeglase
Afta Serif has some issues. With weaker eyesight I find myself mistaking
characters. That k keeps turning into ß.

