RoR sucks, and heres why


#1

Well now that I got your attention…

Why RoR sucks:

  1. It’s smarter than me. Just when I think I’ll have to do some mundane
    thing (like I use to in PHP or ASP), I find out RoR does it already for
    me.
  2. It takes about half or less code to put my stuff together in RoR than
    it did in PHP, ASP, ASP.NET, etc. It seems so unnatural that I can have
    a method with only 4 lines of code, and three of those were error
    handling - YET it does what it should, no fuss, no muss.
  3. I use to worry about giving my client an estimate and then running
    over the alloted hours BIGTIME. Now, RoR has me UNDER the hours
    consistently. I feel so dirty now still giving my old school estimates
    that ASP smashed into my head repeatedly knowing I had to hand hold it
    all the way.
  4. I can finally take those jobs that require “the other” databases like
    Postgresql, MySQL, etc. without rewritting my data layer.
  5. RoR took away my connection strings! Now its just too easy :slight_smile:
  6. RoR makes it easy to run tests across my code, next it will generate
    docs for me from my code … oh wait it’s buddy RDoc does that now…
  7. I use to enjoy those frustrating nights banging my head against the
    wall trying to figure out why my site worked on Windows 2000 but not
    Windows 2003, now with RoR, my sites “just work”.
  8. Now when I see a .NET article I cannot seem to stop yawning. How
    many MSDN magazines now sit beside my desk STILL in their plastic
    wrappers?
  9. AJAX in a few lines of code?!?!? But, but ASP.NET taught me it takes
    a good 20+ lines AT LEAST.

In case someone hasn’t caught on yet (their flame throwers ready at
hand) – RoR doesn’t suck. Just thought I’d add that in in case someone
didn’t have a sense of humor :slight_smile:

  • Mark

#2

Yeah, I see what you mean. RoR really does kick butt, er, suck. =-D

Mark H. wrote:

Well now that I got your attention…

In case someone hasn’t caught on yet (their flame throwers ready at
hand) – RoR doesn’t suck. Just thought I’d add that in in case someone
didn’t have a sense of humor :slight_smile:

  • Mark

#3

In case someone hasn’t caught on yet (their flame throwers ready at
hand) – RoR doesn’t suck. Just thought I’d add that in in case someone
didn’t have a sense of humor :slight_smile:

  1. It made me hate my non-rails job using ASP.Net :slight_smile:


rick
http://techno-weenie.net


#4

+1

Doing maintenance on an asp.net CRM now feels very painful.

Now if rails could get a reporting component like Microsoft Reporting
Services that would be amazing…

Zack


#5

On 1/5/06, Mark H. removed_email_address@domain.invalid wrote:

Well now that I got your attention…

Why RoR sucks:

  1. RoR took away my connection strings! Now its just too easy :slight_smile:

Connectionstrings are so hard :stuck_out_tongue:

  1. I use to enjoy those frustrating nights banging my head against the
    wall trying to figure out why my site worked on Windows 2000 but not
    Windows 2003, now with RoR, my sites “just work”.

Now there’s something I won’t see me doing :stuck_out_tongue:

  1. AJAX in a few lines of code?!?!? But, but ASP.NET taught me it takes
    a good 20+ lines AT LEAST.

www.comfortasp.de

0 lines of code AJAX (or something like it)

Seriously though I do agree with the other points :stuck_out_tongue:


#6

On 1/5/06, mischa kroon removed_email_address@domain.invalid wrote:

  1. AJAX in a few lines of code?!?!? But, but ASP.NET taught me it takes
    a good 20+ lines AT LEAST.

www.comfortasp.de

0 lines of code AJAX (or something like it)

That page is completely blank in Safari. Sounds like they have some
catching up to do.


sam


#7
  1. That Zed asshole still hasn’t released a new version of SCGI.
    Dammit things have to be released frequently or they will not work
    well. Where the hell is he?

Zed A. Shaw


#8

10. It made me hate my non-rails job using ASP.Net :slight_smile:

I second that! (Only I use PHP, not ASP.)

I’ll be the only coder there in about two weeks - I should tell them
I’ll
quit too unless they go balls to the wall with RoR. =D



#9

Here, here. =)

-c


#10

Why RoR Sucks (cont.)

  1. I spend 2 hours trying to figure out a difficult way to display
    action logic only to find that RoR already had a 30 sec remedy.
  2. The RoR community actually replies to [NOOB] posts.
  3. I don’t get to spend 3 months getting my head around a deployment
    container only to discover that it really is possessed by a whip
    lashing sadist demon.

On 1/5/06, @ wrath. rubyonrails. com wrote:


Rails mailing list
removed_email_address@domain.invalid
http://lists.rubyonrails.org/mailman/listinfo/rails

D'Andrew "Dave" Thompson
http://dathompson.blogspot.com

#11

On Thu, Jan 05, 2006 at 11:06:18AM -0600, Rick O. wrote:
} > In case someone hasn’t caught on yet (their flame throwers ready at
} > hand) – RoR doesn’t suck. Just thought I’d add that in in case
someone
} > didn’t have a sense of humor :slight_smile:
}
} 10. It made me hate my non-rails job using ASP.Net :slight_smile:

Amusing, but… actually, I’d say both have their place. When it comes
to
quick and dirty, nothing beats Rails. When it comes to highly complex,
data-backed user interface controls, nothing beats ASP.NET (particularly
several third-party controls). Everything in between is up for grabs.

I would like to emphasize that data-backed, third-party controls are a
big
deal. It was really great on my last ASP.NET project to be able to buy a
tree control that just pretty much worked on the data I was reading from
the DB. It saved me at least a week of development time, if not more,
and
that’s a minor example.

That said, I think I enjoy ASP.NET and Rails development pretty equally.
The community (mailing list and IRC) for Ruby/Rails is a damn sight
better
than ASP.NET when you get stuck, though.

} rick
–Greg


#12

That said, I think I enjoy ASP.NET and Rails development pretty equally.
The community (mailing list and IRC) for Ruby/Rails is a damn sight better
than ASP.NET when you get stuck, though.

I don’t count the fact that it requires a 752 page book (see
Developing Microsoft ASP.NET Server Controls and Components) to write
server controls a plus.

Rails isn’t, and will never be a way to drag and drop your way to a
beautiful site. So, there is of course plenty of room for other
frameworks. All I was saying is that ASP.Net doesn’t make me happy.
It gives me a feeling of “holy crap, it actually worked” if anything
:slight_smile:


rick
http://techno-weenie.net


#13

On 1/5/06, Rick O. removed_email_address@domain.invalid wrote:

I don’t count the fact that it requires a 752 page book (see
Developing Microsoft ASP.NET Server Controls and Components) to write
server controls a plus.

You don’t have to write the things :stuck_out_tongue:

You just have to implement them, like Rails… you don’t have to write
it to use it :slight_smile:
And usually the docs for how to use server controls are a lot smaller
then 752 pages.

But a bit better documented then most open source solutions :stuck_out_tongue:

> All I was saying is that ASP.Net doesn't make me happy. > It gives me a feeling of "holy crap, it actually worked" if anything > :) >

Thats the case in any environment that your not used to :slight_smile:
Writing your first bits in Rails is sure to have given you the same
feeling :slight_smile:


#14

It saved me at least a week of development time, if not more, and
that’s a minor example.

The lure of components is directly proportional with the pain of
development.

David Heinemeier H.
http://www.loudthinking.com – Broadcasting Brain
http://www.basecamphq.com – Online project management
http://www.backpackit.com – Personal information manager
http://www.rubyonrails.com – Web-application framework


#15

On 1/6/06, mischa kroon removed_email_address@domain.invalid wrote:

All I was saying is that ASP.Net doesn’t make me happy.
It gives me a feeling of “holy crap, it actually worked” if anything
:slight_smile:

Thats the case in any environment that your not used to :slight_smile:
Writing your first bits in Rails is sure to have given you the same feeling :slight_smile:

Developing my first Rails project (which was also my first real
exposure to Ruby) left me with a feeling of pure joy and rekindled my
love of programming (which, after a few years as an ASP.NET
programmer, was in serious need of revival).

That being said, I agree that different projects call for different
tools, but I’m yet to find one that calls for ASP.NET over Ruby on
Rails.

Ben


#16

On Thu, Jan 05, 2006 at 01:19:12PM -0600, Rick O. wrote:
[…]
} I don’t count the fact that it requires a 752 page book (see
} Developing Microsoft ASP.NET Server Controls and Components) to write
} server controls a plus.

Er, what? It takes a fair amount of work to give your control a fancy
VS.NET designer interface, but it’s absolutely trivial to create a
control
in general. More to the point, I was primarily talking about using,
rather
than developing, controls.

} Rails isn’t, and will never be a way to drag and drop your way to a
} beautiful site. So, there is of course plenty of room for other
} frameworks. All I was saying is that ASP.Net doesn’t make me happy.
} It gives me a feeling of “holy crap, it actually worked” if anything
} :slight_smile:

Heh. Well, I’ve been doing dynamic web development since 1994 (yes,
really). I have used all of the following technologies, roughly in
chronological order:

  1. make and cpp to produce static files from dynamic data
  2. CGI scripts in C with Remote Database Access (yeah, you’ve never
    heard
    of it, nor should you have)
  3. CGI scripts in C with embedded SQL (ew)
  4. CGI scripts in C++ (or maybe it was C) to produce interactive VRML
    1.0
  5. Client-side Java (it’s dynamic web, kind of, it just isn’t HTML)
  6. JSP + JDBC
  7. Struts + JSP + iBatis
  8. (modifying other people’s) PHP
  9. ASP.NET + ADO.NET (C#)
  10. Ruby + RoR

Of these, I’ve managed to actually enjoy numbers 4, 6, 9, and 10. Having
used all of those, I would avoid to the best of my ability anything
other
than ASP.NET and RoR. They were the only two where I didn’t feel like I
had
succeeded in doing something difficult that I wouldn’t want to repeat.
(Well, the Apache2/fcgid/RoR integration kind of felt like that, but it
wasn’t too bad.)

An important advantage of C# (or even VB.NET, when strict) over Ruby is
static type analysis. While duck typing and extraordinary dynamism is a
pleasure to work with, one loses the ability to rely on a compiler to
verify that the objects one is attempting to work with are actually
going
to match the use one is putting them to (i.e. conforming to an
interface).

I do not claim that C# or ASP.NET are “better” than Ruby or RoR. I will
claim that there is a place for each, and that one should use the right
tool for the job. (Note that this does not apply to two tools that are
for
the same job, such as Java and .NET; C#/.NET really are as good or
better
than Java in every way other than platform independence, and the Mono
folks
are working on that.)

} rick
–Greg


#17

n+1. Rails makes you less macho. You won’t be able to relate to those
surly, curmudgeony, masochistic C, C++, C#, and Java developers who have
done many times more heavy lifting by writing far more code; been super
anal-retentive in getting definitions and syntax correct; gotten a wide
array of technologies to work together; and rolled many of their own
reinvented wheels many-a-time. It’s like those people who drive older
cars and can - and have - rebuilt their own transmissions, engines, etc.
vs. those wimps who spend all their car time actually driving and
Getting Stuff Done.

n+2. Rails makes you less smart. Unlike those PHP developers who Know
Everything and prove it by writing yet another template engine,
framework, etc.


#18

On 1/5/06, Ben M. removed_email_address@domain.invalid wrote:

exposure to Ruby) left me with a feeling of pure joy and rekindled my
love of programming (which, after a few years as an ASP.NET
programmer, was in serious need of revival).

That being said, I agree that different projects call for different
tools, but I’m yet to find one that calls for ASP.NET over Ruby on
Rails.

Ben

Just out of curiousity, which language did you use under .Net ?


#19

In the interests of starting a more serious discussion of problems with
Rails:

  1. The internals are undocumented and sparsely commented, making it
    difficult to patch when you discover yet another bug.

  2. Non-trivial patches only get applied if they affect the core team.

  3. Implementing new features takes priority over fixing bugs.

  4. There are a lot of bugs.

  5. There are numerous cases where Rails will die without any feedback
    to the administrator or user.

  6. It’s slower than other frameworks (if you can’t use caching).

  7. It consumes a lot of RAM.

  8. def many_method_names_are_really_long_like_this_one; end

I like Rails and I think it is the best web framework for my needs,
but there are still a lot of problems with it.


#20

On Sat, Jan 07, 2006 at 01:56:44PM -0800, Jeremy E. wrote:

In the interests of starting a more serious discussion of problems with Rails:

As a core member I’ll respond to some of the issues you bring up.

  1. The internals are undocumented and sparsely commented, making it
    difficult to patch when you discover yet another bug.

When you run up against internal code that is poorly documented or not
documented at all and struggle to figure out how it works, documentation
patches would be appreciated. We work hard to make the outward facing
API
always backwards compatible. Documentation is like code. The more you
write
the more you have to maintain, so we privilege the public API over the
private API in this regard, as the internals tend to be refactored more
frequently (which requires the overhead of documentation updates). Also,
those delving into the internals are likely more able to determine how
they
work. Point taken though. Rails would likely benefit from some more
documentation of the internals. Again, patches welcome. Documentation
patches
don’t require tests :wink:

  1. Non-trivial patches only get applied if they affect the core team.

If a patch is non-trivial it needs to be well tested. If it doesn’t
apply
cleanly the core team doesn’t have the time to make it unless it is
really
important. If it is well tested then it still takes time to evaluate.
That’s
how open source works. There are two sides to everything.

I take issue with the “only get applied if they affect the core team”
part.
As a member of the core team who has taken the time to apply, test and
commit
plenty of code that has nothing to do with me I can’t accept such a
broad claim.

We try to make an effort to express in ticket comments when a patch is
not
complete or needs more work. If a patch is of high quality, well tested
and
appropriate for inclusion in Rails then it is often applied relatively
expediently. In the cases where this does not happen I apologize. Gentle
pestering on the rails-core list is encouraged. Gentle…

You may take issue with what “appropriate for inclusion in Rails” means.
Rails came out of David and 37signals’ needs for Basecamp so it has its
original motivations springing out of necessity. The core team does have
needs in the applications they build. David, for example, had a need for
tagging in Sunrise. But he did not add a tagging framework to Rails.
Instead,
after implementing a tagging system he was happy with, he extracted the
higher level database relationship model (the new polymorphic
associations)
into ActiveRecord. In other words, there is a distinction to be made
between
people’s needs and thing that are appropriate to the framework. We
ultimately
are the judge of what the appropriate level is. If it’s at the framework
level and is a good fit for Rails, it goes in. Scott B., a core team
member with the keys to the svn repository, is using the plugin system
in
Rails for several of his projects. He has needs for his apps but
recognizes
they don’t fit in on the framework level.

The relatively high barrier of entry to patch submissions is also
largely the
reason why you like Rails so much. We say no before we say yes.

  1. Implementing new features takes priority over fixing bugs.

Rails has been in growth mode for a while. With the release of 1.0 we
have
said, “This has enough features.” The 1.0 branch will only receive bug
fixes
now. Rails hasn’t stopped its development but non of the core team has
an
interest in making it huge and bloated so a lot of the work post 1.0 is
going
into the tools used in conjunction with Rails and not as much on Rails
itself. Either way, new features will be implemented and bugs will be
fixed.
We could all spend more time fixing bugs but as the considerable test
coverage of Rails indicates, its code health is good.

  1. There are a lot of bugs.

Undeniably, there are many pending bug reports. There is a distinction,
though, between there being many tickets and many egregious bugs. Rails
is
always going to have bugs. A lot of bugs, though, are edge cases or
otherwise
not a priority so simply going off the number of pending bug reports is
not
the whole picture. Regardless, if you are so inclined go through and
identify, say, the 10 most critical bugs as you see it and post their
ticket
numbers to the core mailing list making a case. Help prioritizing bug
reports
would be appreciated.

  1. It’s slower than other frameworks (if you can’t use caching).

Rails privileges programmer productivity over execution speed. Always
has
and will. As does Ruby itself. That aside, the core team is mindful of
performance and we are working closely with Stefan K. who has taken it
upon
himself to work exclusively on Rails performance. I personally spent
over 20
hours for the 0.13.x release integrating his performance work into
Rails. So,
Rails is slower than other frameworks. There are other criteria by which
it
can be compared to those same frameworks as well. Ruby 2, out there in
the
distance, will likely make that a non issue. Rails is most of the time
fast
enough. There are real world apps with lots of traffic backing that
claim.

  1. def many_method_names_are_really_long_like_this_one; end

What is the problem with this? You want intension revealing method
names.
Your text editor should alleviate the hassle of typing the whole thing
out.

I like Rails and I think it is the best web framework for my needs,
but there are still a lot of problems with it.

Thanks for the list. It’s very useful to have people who like Rails
pointing
out what they don’t like rather than people who’ve already made up their
mind
to hate it looker for things to throw rocks at. So I do really
appreciate
your candor. I’m all for people willing to help.

marcel