codahale.com٭blog

harley davidson ringtonesonata arctica ringtoneshellomoto ringtonescable guy larry ringtonecrazy frog original ringtone
Coda Hale lives in Berkeley, CA, where he writes about Ruby on Rails, usability, web design and development, and the occasional bit about bicycles.

Six Ground Rules for “Rails Sucks” Articles

This guy crossed a line, and I think it’s time we began to establish community norms about this kind of thing. I’m proposing six ground rules for “Rails Sucks” posts.

Rule One: No Ponies

You have to compare Rails to something that exists. An ontological argument based on a theoretical perfect good is not interesting, and likewise an argument that Rails sucks because it doesn’t magically integrate generated code with your hacktastic mess of a “Hello World” app isn’t interesting because programs do not magically intuit and obey your intent. The scaffolding code generation is there to start you off, not bail your ass out when you realize you have no idea what you’re doing.

Also, ActiveRecord’s ORM cannot be expected to magically work with all aspects of your database schema, including your own particular naming scheme. It offers meaningful defaults, and if you want it to conform to your own scheme, you have to configure it. (We’ve already covered why it can’t magically intuit and obey your intent.) You want something that will understand and conform to all of the foreign key constraints and database-specific tweaks you’ve come up with? Try SQL. You think everyone should be using [insert favorite database flavor here]? Get in line with the rest of the freaks.

Rule Two: Anything You Say Can And Will Be Used Against You

If you get one of the fundamentals of the field wrong, you’re out. Ruby is a programming language and Rails is a web framework; this is not paint by numbers. So, for example, if you say that the “relation” in “relational database” is how tables “relate” to each other, sit down, shut up, and start paying attention in class. If you can’t be bothered to learn about the relational model, I’m not willing to listen to your opinion on anything based on it, including database-driven web development.

Please make sure that the easiest explanation for your criticism is not your own lack of knowledge.

Rule Three: You Not Getting It != Rails Sucks

Any complaints must be real, in the sense that they have at least a foothold in consensus reality. You have to restart WEBrick to load changes to the database schema in development mode? No, no you don’t. You have to restart the web server when you:

  1. Edit anything in the config, lib, or vendor directories.

That’s it, and it’s a damn waste of a ol element. That’s consensus reality right there, and if your experiences don’t match up with it I can only assume that you’re either trying to use Apache+FCGI as a development platform (in which case I punch you in the neck) or you’re totally delusional (which is actually preferable to using Apache+FCGI as a development platform, and not because of me punching you in the neck).

If you try to do something stupid, you will be frustrated with the result. This has nothing to do with Rails; it’s how life teaches you to be less stupid.

Rule Four: Programming != Zen Koan

First there is a scaffold. Then there is no scaffold. Then there is.

A newb asked DHH, “Does ActiveRecord’s ORM have DRY-nature?” “Nej,” replied DHH. At this word, the newb was enlightened.

Learning is something which takes effort, and if you’re expecting anything complicated to not require effort, see Rule One. Yes, the documentation needs to be improved.

But this is just too-much-cough-syrup crazy talk, plain and simple:

What gets me is I am just *not* going to pay to read 570 PAGES about a framework! I’d actually pay twice as much if they could boil this sucker down to 200 pages or less!

This is an actual quote. If you actually expect to be able to learn how to effectively use a full-stack web development framework based on man pages, blog articles, and the kindness of strangers, and if your objection to getting a book is that it’s too long… actually, you know what? This right here explains the entirety of his rant. There is a manual, but it takes longer than the average bowel movement to make it through the damn thing. Well there’s your problem right there: you don’t want a web development framework, you want a copy of People. “Ooo! Brangelina photos!”

(God only knows what this guy would think of Knuth… “Three whole volumes?! But I wanna know C now!”)

Rule Five: No Doomsday Scenarios

Rails sucks because it wouldn’t be able to handle my trillion-table database which spanned galaxies in its conception and is normalized to the 17th form–down to the letters. Until Rails is ready for the enterprise, it’s just a toy.

No, nothing will solve your imaginary (or, *shudder* real) enterprise situation, Rails or otherwise. If you’re honest about it being real and having a bazillion tables, etc., etc., I suggest you start saving snippets for The Daily WTF and looking for a new job. No web framework, no matter how it’s described to you by a Web2.0 blog, will ever fix the horrendous mess that is that schema, and faulting Rails for not being able to undo the atrocity performed by either you, the DB admin, or some hobo they kidnapped off the streets is a psychological coping mechanism, not a valid critique.

You’re looking for a glass of whisky the size of your chest, not a web framework.

(Unless, of course, you’re just making things up for the sake of argument. But really, who does things like that?)

Rule Six: “Rails Sucks” Is Not A Good Way To Ask For Help

There are plenty of people willing to explain how things work, and the Rails community is growing by leaps and bounds. If you were to ask them, say, “why do I have to always restart the web server to see my changes,” you’d get help. If you post a “Rails sucks” article on the JoS forum, you’re going to get made fun of.

Conclusion

I’ll arm-wrestle anyone who says DHH isn’t Apollo incarnate.

17 Responses to “Six Ground Rules for “Rails Sucks” Articles”

  1. ArmedGeek Says:

    Absolutely perfect. Personally, I don’t use Rails, but this comes close to applying to just about anything. Good read.

  2. Diego Says:

    You’re right on almost all, but I think that you should say things in another way if you want to teach something to someone. This is the kind of attitude that can make something really good (RoR) unpleasant to people because someone (you in this case) defends it with too much force: who do you think you are? You cannot say for example “stupid” to someone (even hypothetically) and expect something good back, for you but above all for RoR. I hope that in your intentions you put more irony in what you said. Peace.

  3. Coda Says:

    Diego–I’m not an evangelist. I’m not trying to convert or convince. Rails works for me personally and professionally. Beyond that, I really don’t care. If someone tries it out and likes it, awesome. If someone tries it out and doesn’t like it, oh well. If someone tries it out and posts several pages of utter nonsense, I’ll call them out on it.

  4. Bobby Says:

    I totally agree with everything. I (used to) make a living designing (and hacking) Joomla, two weeks ago I dropped everything and took up RoR. Why? Because it gives me a fighting chance as a designer, of having my ideas see the light of day. Rails pushes us forward, and Rails rewards us for trying.

  5. Justin Says:

    Very well put, Coda. Couldn’t have said it better myself, and certainly not as humorously.

    Diego: I don’t think Coda was trying to teach something to the guy in question, so therefore Coda shouldn’t have said things in any other way than the way he said it. Frankly, Coda simply said exactly what was on the minds of nearly everyone* who read the original guy’s clueless rant.

    (*Definition: “everyone” = people who know the slightest bit about web application development and who have functional use of at least 2.7% of their brains.)

  6. Jiho Han Says:

    Coda: I agree with Diego. You say you’re not a RoR evangelist. Rails works for you and beyond that you really don’t care. Then why not just happily go on with your business instead of responding to this guy? Compare this post to DHH’s response on the JoS forum. Which one is more helpful? And he has more stake in the thing then you probably, wouldn’t you say? This post is just a rant against another rant after all.

  7. Coda Says:

    Jiho, I think you’re confused, both about what I said and what I should do. I never said rants were bad, and yes, this post was a rant about a rant. So? I suggested ground rules for rants, not an across-the-board ban.

    Should I have been helpful? Screw being helpful. (This is why I say I’m not an evangelist.) If I want help with something, I don’t write a 10-page article about how much it sucks. I research the problem, and politely ask people for help if I’m stuck. That guy wasn’t asking for help, he was entertaining himself and others with misinformation and opinion. I’m not flaming a newbie for asking stupid questions, I’m flaming someone who should know better.

    So why do I bother? Well, first of all, I find it hard personally to hear someone speak poorly of something I myself like. Call it a personality flaw.

    Second, because he wasn’t writing about his own experiences or his own opinions, for the most part. He said a lot of stuff about Ruby and Rails that are objectively false. See if you can tell the difference between the following statements:

    1. “…Having to reboot the webserver makes Rails feel like a step backward from even CGI Perl in terms of speed.”
    2. “I think Ruby looks ugly, and I’m still not convinced that Rails will work for large projects.”

    Did you see the difference? Statement 1 asserts something which is objectively false (i.e., that one must constantly reboot the Rails server during development), and Statement 2 describes personal opinions. Statement 1, bad; Statement 2, good. Look at how many diggs that story got. If people didn’t have an opinion (or information) about Rails when they went in, they came out with the “knowledge” that you have to restart the webserver in order to see changes in Rails, etc. etc. That crosses the line from forceful opinion (”I don’t like Rails”) to objectively false (”You need to restart the web server each time”).

  8. Marcus Says:

    Great article :) I think you’ve definitely summed up the counter-arguments to that post really well. Basically no one has said that Rails is the end-all of a web frameworks, but it definitely does a good job at what it was intended to do.

  9. albert Says:

    Well, I favor Rails and Ruby over just about anything.. but a few remarks….

    You _do_ have to restart the server _if_ you for example work in some module.. or Observer.. or plugin.. Or some other model that isnt a normal Rails one.

    And in some ways it does remove the relational model, at least as regard to the dbms in question. Sure the data still relates, but you cannot have the dbms handle the integrity, but is forced to do that yourself. Or have Rails do it. That kinda sucks for some people I would assume, fortunately it isnt that big of a deal for them since they can just use their precious SQL instead. I really hate that “language” :)

  10. Prince Paul Says:

    Go eat a yummy sandwhich and try to smile.

  11. Coda Says:

    albert: If you’re writing a non-ActiveRecord model, check this out:

    
    class MyCrazyAssModel < NotActiveRecord
      include Reloadable
      # etc.
    end
    

    Now Rails will reload that class when appropriate. Works for modules, too. And yes, DHH has been pretty iconoclastic about databases, but the fact of the matter is that while ActiveRecord doesn’t make it any easier to create foreign keys, key constraints, etc., it also doesn’t make it any harder. I’ve deployed a few Rails apps which used database-level integrity constraints. You have to make sure your test fixtures line up properly (e.g., load the join fixtures last), but other than that, it’s fine.

    Prince Paul: Would pizza work, do you think?

  12. Corgar Says:

    The RoR community is probably the most defensive ever and the awakening will probably be brutal. Get a life for god’s sake…

  13. Coda Says:

    Corgar–Okay, I’ll bite: what, exactly, will the Rails community awaken to?

  14. Inter-Sections » Blog Archive » Rails sucks? Says:

    [...] doing so for so long, that some people even bothered to write pre-emptive rant responses, like the Six ground rules for rails sucks articles, written all the way back in 2006. RubyInside even has a Troll of the month category that will [...]

  15. Stephen Says:

    Yeah, you’re right.

    …But rails sucks because it’s a hack job for n00bs. I get it, cut and paste. That only works with javascript, where the integrity of your server isn’t at stake. I get it enough to say that I’ll stick with any of the more wonderful server side scripting languages out there. RoR raises a mine field of red flags to real programmers.

    Check this out

    Web 2.0 is a pretentious concept anyways.

    I can’t stand this mindset of “as long as it looks cool (on my platform) it doesn’t matter what the code looks like”. Hack job programmers think that way.

  16. Coda Says:

    Stephen–

    1. Rails does not require or promote cut-n-paste programming any more than any other framework in any other language.

    2. Cut-n-paste Javascript doesn’t work. Nothing cut-n-paste does.

    3. Rails is not a scripting language. It’s a web framework. Ruby is a scripting language, and none of your complaints are about it.

    4. You didn’t describe any of the red flags Rails raises for “real programmers.”

    5. A security patch. Oh noes.

    6. Rails is not Web 2.0.

    7. You didn’t provide any evidence that Rails requires or promotes whatever mindset you’re talking about.

    There are a lot of really convincing critiques of Rails to be made, and you didn’t touch on a single one. Frankly, you don’t know what you’re talking about.

  17. Jim Says:

    I think the recent popularity of Ruby on Rails can best be described as a great marketing success. It is really hard to point to any particular aspect of Ruby on Rails and argue that it solves a problem in a completely new revolutionary way. We have seen a plethora of MVC frameworks for a number of languages in the last ten years. Similarly, scriptlets and templates have been around since the dawn of web 1.0, and I just don’t see any major differentiators in rails templating technology than say java JSP or PHP. As for built in relational mapping, it is neat, but by far not something new. In fact we have a lot more mature relational mapping technology from companies like Toplink (now oracle) and Sun with likely better implementation.

    So other than just sounding cool I don’t get all the fuss and the emotional attachment behind rails…

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>