8 ms·

Some HNers seem to hate Rails. I want to know why.

25 points by generalk 16y ago

timruffles 16y ago
I really like Rails - for all the CRUDish apps of the world there's nothing better: you'll avoid reinventing a lot of boring wheels. Perhaps the reason some HNers are Rails-phobic is that Rails is rightly designed to be precisely the opposite of tool you want for hacks: convention over configuration, config opaquely doing as much as possible for you, and development being as far as possible snapping together canonical bricks (Devise, WillPaginate et al). If it didn't get in your way for hacks with very different requirements to the apps Rails was designed for, it wouldn't be doing its job. Right tool for the job, as ever!
bensummers 16y ago
I moved away from Rails because the data model didn't fit my app. But I still use it for all the management applications. Here's a writeup I did for EngineYard about the move from Rails to JRuby and my own app 'framework': http://bens.me.uk/2010/jruby-in-practice http://bens.me.uk/2010/jruby-in-practice
- generalk 16y ago
  Fascinating. I'd love to hear about the data model mismatch -- having done mostly CRUD webapps, I'm not really in a position to see that.
  - bensummers 16y ago
    Well, the main problem is that the user data we store is multi-valued. So each attribute can have multiple values in the same 'record'. As you can imagine, Rails doesn't help much in this situation, as it assumes that each column in the databas table has just one value. http://www.oneis.co.uk/technology/object-store http://www.oneis.co.uk/technology/object-store Oh, and each application on a multi-tenant app server can have a completely different schema. Again, there's not much that Rails can do to help. Rails was good to get going, and it helped for the relational stuff in the app. But unsurprisingly, if you try and use it for something it's not designed to do, it's not going to work terribly well. This principle applies to everything.
davidw 16y ago
I think Rails is great, and it hasn't ruined any of my projects. Once in a while, however, the magic can be a bit tiresome - you have to know a lot of things. For instance that if you change the routes file, it may make a series of functions named in a certain way to appear in your views. Or just how to name everything in the right way to make Rails happy. Often times it's a time saver, but once in a while you kind of wonder if it has to be quite so magic. Also, sometimes those things are dynamically put together, so you can't grep for them in the source code.
- msie 16y ago
  you have to know a lot of things sometimes those things are dynamically put together, so you can't grep for them in the source code I completely agree. Also: the rails guides are helpful, but the generated api docs suck.
- jdelsman 16y ago
  As far as I'm concerned, that's quite a cop out. You can understand the magic if you go so far as to drudge through the Rails core code. It's really simple to do, as its all on GitHub. If they are "dynamically put together" (which I'm assuming you mean things like method_missing, etc.), you should increase your level of Ruby knowledge, as that will get you farther when reading the source code. http://github.com/rails/rails http://github.com/rails/rails
keefe 16y ago
>it's completely won me over, replacing almost every single place I'd use PHP which it should, php is terrible. It's OK for many purposes, but there aren't that many spectacular libraries for difficult things, lack of sophisticated IDE support, etc.
- jrockway 16y ago
  +1. I love it when PHP programmers start calling anything that's not PHP or Rails "blub". Oh, the irony.
- jacquesm 16y ago
  Some HN'ers seem to hate PHP, I want to know why :) I couldn't care less about a platform someone else uses that I don't use. Familiarity breeds contempt. So I think I'm qualified to rant on PHP because I wrote an awful lot of it over the years and am still maintaining one large PHP project that was written in the PHP2 days, so you can imagine what that's like (we're re-writing that at the moment). If you're happy with rails, more power to you. If you're happy with python, great! Whatever you use, if you're happy with, I'm happy for you. Meanwhile, live and let live. So, PHP may be 'terrible' for you, but it has made me more money than all the other programming languages that I know combined, in spite of all its shortcomings. Spectacular libraries for difficult things? Not on my wishlist. Lack of an IDE? I use vi(m). It's all just work, and work needs to be done. Use the tool that's best for you and move on, don't look back too much and kick at where you came from. And if you didn't 'come from there' you shouldn't be having an opinion on the subject anyway, then you're just parroting.
  - fragmede 16y ago
    PHP has a long documented list of shortcomings, but y'know what? Just like shell scripts, it is absolutely fantastic at small one-off but long-lived programs.
    - jacquesm 16y ago
      > it is absolutely fantastic at small one-off but long-lived programs. Like facebook? ;)
angrycoder 16y ago
I think the problem with MVC web frameworks in general is that it makes it makes the easy/boilerplate stuff really easy, but the hard stuff harder. Sure, if you doing a simple CRUD app that is only updating a single table it is fine. Beyond that, you waste so much time trying to figure out how the frameworks wants you to represent composite objects, and debugging the default model binders, then thinking you might have to write your own binder, then just saying screw it and reverting to Request.Form[] and parsing your own requests.
- generalk 16y ago
  This is exactly the kind of response that concerns me. I'm looking for concrete Rails-specific issues. I understand that, in theory, Rails may suffer from this issue. In practice I've never once seen it. I think Request.Form is an ASP.NET thing. I have no experience there, so I can't comment on it.
- joe_the_user 16y ago
  I absolutely agree that a complex, n-table, n-page site does not scale with MVC in general. Simplistically, [n-tables] X [n-pages] = n^2 controller methods for n controllers. So trying to make the controllers nice and OO just means each controllers complexity expands excessively. I would be really curious. What pattern do people think scales in this general situation?
  - generalk 16y ago
    In the simple case, Rails likes you to have seven controller methods and one controller per table. Realistically I usually end up throwing a few more methods on each controller. This is actually part of the reason I like Rails: it guides the developer towards what I consider to be better application design. I understand that a lot of folks don't agree, and that's cool for them, but I still like hearing why.
    - angrycoder 16y ago
      I can see that working if each of the 7 tables was their own individual entity, but I am talking about a composite object here. Normalized data. How do you manage a transaction across 7 different controller methods? I am not saying their isn't a nice way to do this, merely using this as an example of why people may not like Rails. It forces you to figure out the Rails way of doing things. And that may not always be the best way for you, especially if you are an experienced developer.
joe_the_user 16y ago
Every system I've seen that has some "magic" also has the potential for that magic to reverse itself and become something that seems to work against you. And when that happens, it's easy for the magic to become something you "hate". Rail and Ruby each a lot of this magic. No matter what you say, Twitter is relevant. No matter what Twitter says, Twitter is a Rails success story because Rails got a major, major site up and running fast. And naturally when the magic stopped working, everything about Rails just seemed to work them. It was what they needed until they grew into a site that wasn't well served by Rails. Imagine if I said, "San Francisco is a terrible place to start a business and what proves it is that we experienced wild success and then couldn't rent any more office space, had to split our headquarters and eventually moved to Omaha". How convincing is that?
hasenj 16y ago
Frameworks have limits, the same guys who loved rails had a previous experience with Django where they loved it then they hit a wall and started replacing all of its components. Of course Rails is 100x better than php. I suspect it exhibits the same characteristics of frameworks that make a lot of people turn against Django after some time. It is, after all, an opinionated framework. If people never hit a wall with it, I'd be a bit concerned; perhaps they're probably not trying hard to push their apps beyond limits of the framework.
xiongchiamiov 16y ago
When I first used Rails, I was frustrated by two main things: * Files everywhere! I like starting simple, and you generate all these folders with things I just don't want to deal with yet. * Lots of things were implicit, making it difficult for a newbie to the framework to understand the flow (How do we get from the controller to the template? was one, I think). Now, that was several years ago (a little over 3, now), and both Rails and I have changed. I've been waiting for Rails3 to give it another chance, but haven't found the right project yet. My current gripes with Rails are this: * DHH is a prick. * It's damned difficult to find a good Ruby feed that doesn't get polluted with Rails stuff. My first issue is, of course, not very valid, but I have to admit that it exists. For the second one, yes, I program in Ruby (and love it!), but I'm not using Rails. Even when I do web development in Ruby, it's with Sinatra. So, I don't want to see your frackin' "Ruby tips" that are actually Rails tips! </endrant>
almost 16y ago
Some people don't like Rails. This isn't a problem. It's not a personal insult to you or to your skills or to anyone else who likes or uses Rails. It's sometimes useful to discuss the limitations (in some subset of people's views) of software. I say this as someone who quite likes Rails but doesn't use it at the moment. It just so happens that the bit of web work I do at the moment tends to fit Django better. But don't worry, we don't need to hate each other :) I've flagged this article because I really can't see anything of worth coming out of it. Holy wars are very rarely that interesting.
- jacquesm 16y ago
  This is rather more topical than 'today is programmers day', and I still see that on the homepage at 190 points.
- generalk 16y ago
  My intent wasn't a holy war. I've used Rails for over a year. I keep hearing people say that it's slow, or it doesn't scale well, or that after the first 80% of the application is finished it gets in your way. I haven't found that to be the case, but my experience is limited. So I'm looking for any cases where any of these things have actually happened. I want to know if these claims have any substance.
  - almost 16y ago
    Of course there are cases where Rails isn't the right solution, that's true of absolutely everything. It's probably fine for all your uses (and for mine too) though. You are not going to get a useful discussion of them with that blog post though. You use an antagonistic tone and target a group of people who largely only exist as a group in your head, that's not going to produce good stuff!
peteforde 16y ago
My two guesses: - more job opportunity at higher billing rates for Rails - it's easy to hate on smug people, unless you're on their team I'm perfectly happy with Rails, because we've now invoiced several million dollars on cool projects that we never would have worked on had we stuck to [in our case, .NET].
PhrosTT 16y ago
perhaps the theory is one day your site will blow up and you'll need to scale... or hire additional programmers. at which point these things are probably easier with a php app... there's a certain safety in choosing the more popular language.
BrandonM 16y ago
<rant> If I'm a good C programmer, if I grok Lisp, if I'm fluent in Python, if I can accomplish damn near any file munging task from a bash prompt, and if I have an understanding of component-based development, then I should be suitable for the vast majority of programming jobs. Yet something like 90% of job postings require X years of experience in Ruby, PHP, Java, or some Microsoft-specific language. Many of the interesting programming jobs have chosen to select for a language that I could learn in a couple hours, work with in a couple days, and use well in a couple weeks, but because I don't know it right now, I'm not hire-able. Background, intelligence, and work ethic be damned, you need Ruby and Rails experience to work here, because after all we have many applicants and someone is bound to fit all our criteria. And while we're on our soapbox, why-oh-why are good programmers so hard to find? Because you're not even trying. You have too much other crap to do, and you're just looking for a quick, safe reason to reject everyone else and have a couple people conveniently left over to choose from. And no, I don't know the ins and outs of b-trees anymore, but give me some time with Google and vim and I'll have a C solution ready to be tested. You know, the way real work is done. So yeah, I suppose I do find myself bitter that I'm expected to pick up a trendy language and platform (and recall every data structure I learned 4 years ago) to even have a chance on the job market. From the outside it just looks like a giant Ruby/Rails clique (or PHP/Cake, or Java/Spring, or whatever technology your company has happened to fall into). We're all forced to learn something that we don't actually need -- we can already get it done with similar effort in another way -- just for you to consider hiring us. And everyone has a slightly different stack that I have to go teach myself just to avoid looking like an idiot in the application process. And it's not just Rails and the languages I don't know (yet!). Even the Python job postings I find almost without fail require experience with Django or some other framework du jour. I mean geez, how long does it take to learn a freaking framework, especially with a bit of early guidance? Stop selecting for the wrong criteria! I'm not one of the ones typically "bashing" Rails, but I understand the frustration of being forced to learn a bunch of crap as part of an elaborate mating game of inefficient, badly-designed hiring practices. Just throw some work my way, give me the email of a knowledgeable employee who can answer occasional questions, start me out at a below-market rate, and evaluate my role and contributions in a month or two when I've had a chance to get acclimated. The filters that employers use are such bullshit, and then to make it worse they slap us in the face by claiming that it's impossible to find good programmers. </rant> What was the question again?
webginja 16y ago
To use Ruby effectively in the enterprise, one needs to look at JRuby - but if your going to go to the JVM why not use something better suited to the JVM and not a port of ruby?
kreek 16y ago
Some issues I think come from the early hype that it was the 'one framework to rule them all'. I personally love Rails but it is a bit heavy and shouldn't be used for smaller projects. But that's not Rails fault it was more a misunderstanding of Rails' sweet spot. For those smaller projects I now use Sinatra. That said when I first started using Rails, four years ago, it should have come with a warning sticker about deployment issues. A smaller VPS that could handle dozens of PHP apps could be only really handle one maybe two Rails apps. Litespeed, Passenger, JRuby, etc. have made these issues go away, but I can see how it might have left a bad impression of the framework. P.S. You think people hate Rails try being a Flash developer on here.
parfe 16y ago
I don't want to be surprised by a framework. http://dev.rubyonrails.org/ticket/10919 http://dev.rubyonrails.org/ticket/10919 The above bug report (while incredibly funny) was a symptom of what turned me off while learning rails. Why would tables be pluralized automatically? A model might change to a word I didn't even know is the correct plural. ( I didn't go any deeper than tutorials. ) Overall I prefer Django as nothing comes as a surprise, and the shortcomings aren't a huge bother for what I do.
- generalk 16y ago
  Why should be tables be pluralized automatically? Because that's frequently how you'd do it anyway. I deal in a lot of legacy data stores, and I have a lot of "set_table_name" calls. That said, Rails is opinionated, and not agreeing with those opinions seems like a perfectly valid reason to not like it.
- JangoSteve 16y ago
  It's beneficial to point out that ActiveRecord is no longer tied to the hip of Rails. In fact, in Rails 3, you now have ActiveModel which gives you all the "Active" goodness of model objects without connecting to a specific database at all. In other words, issues like this are no longer a problem in Rails, maybe just in certain modules you can install and use optionally in Rails.
jamesbritt 16y ago
I preferred Nitro over Rails when they both arrived in 2004. Nitro made it far easier to evolve an application from a single static HTML file to any degree of complexity (plus it was faster, thread safe, and more modular). Rails seemed better suited to a very specific genre of application. Great when you're building that app; less so when you needed to color outside the lines. Ramaze picked up where Nitro left. All software is opinionated; I prefer the opinions built into Ramaze. Whatever tool you pick, whatever language you use, make sure the opinions it embodies align with yours, or you'll find yourself frustrated way too often. But I really think the alleged hating on Rails has more to do with how some people perceive its more vocal proponents. Sadly, it all feels like being back in high school again. It's the "rock star" and "hero" nonsense that grates. People would do better to scope out the various languages and tools, learn to appreciate the good stuff, steal the better ideas for their own preferences, and ignore the personalities and drama. Code talks, bullshit walks.
jamie_ca 16y ago
I first experimented with Rails in the 0.7 days, and stuck with it until sometime in the early 2.x series. The general complaint you mention about "it got in my way and I had to abandon it" is basically at the top of my list. As Rails evolved, it picked up a _lot_ of cruft, and when things went subtlely wrong (or I was trying to track down a "magic" method) it was just a big pit of morass to dig through. About that time (nearly 3 years ago) I switched to Merb, the new kid on the block. That's had its own share of pain to deal with, and at work we're now figuring it'll be worth it to migrate back to Rails 3. The Rails/Merb "merger" has resulted in a lot of good architectural cleanup, and being able to live within the regular plugin ecosystem has a lot to say for it (namely, we won't need to maintain the dozen-odd forks for merb support anymore).
atldev 16y ago
I think this is a great question to ask. I feel the same way, and unless I missed it in the comments so far, I don't see any specific examples that would give me pause. I'm loving Rails so far, especially after being able to start from scratch and build a viable, working, commercial, revenue earning app in just a week. I'm sold, but scanning the horizon cautiously.
- nlz1 16y ago
  http://blog.leosoto.com/2008/12/on-really-disliking-monkeypatching.html http://blog.leosoto.com/2008/12/on-really-disliking-monkeypa...
Pewpewarrows 16y ago
I'm pretty sure the general direction of the comments weren't bashing on Rails specifically, just the idea that they thought the honeymoon wouldn't end (it always does). They went from a very heavy django background, where they saw the shortcomings of the framework (or every framework, really), dabbled in Rails for a day, loved its magic for trivial tasks (protip: most frameworks make trivial tasks easy and magical), and somehow concluded it was superior to django and that they had stumbled on a hidden gem (pun intended). Frameworks have limitations. You will always reach a point in your career working with them that you disagree with one or more design choices, and you will have to deal with a problem the developers never accounted for. Sometimes that problem is easy to solve using your existing framework, and sometimes the framework (in solving 95% of other use cases) makes handling and solving that problem a pain in the ass. It isn't unique to django, Rails, Zend, or whatever else you happen to be using. But pretending that the framework you just discovered is perfect is just silly. Take the language you enjoy working in, find a framework that suits your style and doesn't get in your way too often, and run with it. My apologies for still giving vague, sweeping statements, but I haven't worked deep enough with Rails for it to get in my way yet (I've only done a few simple proof-of-concept sites with it).
DanielRibeiro 16y ago
Avi Bryant answered this here (http://python.mirocommunity.org/video/1186/django-is-obsolete-but-so-is-e http://python.mirocommunity.org/video/1186/django-is-obsolet...), but on Django form. For the projects he mentions, sinatra is more than enough.
nlz1 16y ago
"7 reasons I switched back to PHP after 2 years on Rails" http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_swit...
jcapote 16y ago
There's a major python slant here. I don't know why, but it always feels that way to me as a regular reader here.

25 points by generalk 16y ago

I really like Rails - for all the CRUDish apps of the world there's nothing better: you'll avoid reinventing a lot of boring wheels. Perhaps the reason some HNers are Rails-phobic is that Rails is rightly designed to be precisely the opposite of tool you want for hacks: convention over configuration, config opaquely doing as much as possible for you, and development being as far as possible snapping together canonical bricks (Devise, WillPaginate et al). If it didn't get in your way for hacks with very different requirements to the apps Rails was designed for, it wouldn't be doing its job. Right tool for the job, as ever!

bensummers 16y ago

I moved away from Rails because the data model didn't fit my app. But I still use it for all the management applications. Here's a writeup I did for EngineYard about the move from Rails to JRuby and my own app 'framework': http://bens.me.uk/2010/jruby-in-practice http://bens.me.uk/2010/jruby-in-practice

generalk 16y ago
Fascinating. I'd love to hear about the data model mismatch -- having done mostly CRUD webapps, I'm not really in a position to see that.
- bensummers 16y ago
  Well, the main problem is that the user data we store is multi-valued. So each attribute can have multiple values in the same 'record'. As you can imagine, Rails doesn't help much in this situation, as it assumes that each column in the databas table has just one value. http://www.oneis.co.uk/technology/object-store http://www.oneis.co.uk/technology/object-store Oh, and each application on a multi-tenant app server can have a completely different schema. Again, there's not much that Rails can do to help. Rails was good to get going, and it helped for the relational stuff in the app. But unsurprisingly, if you try and use it for something it's not designed to do, it's not going to work terribly well. This principle applies to everything.

davidw 16y ago

I think Rails is great, and it hasn't ruined any of my projects. Once in a while, however, the magic can be a bit tiresome - you have to know a lot of things. For instance that if you change the routes file, it may make a series of functions named in a certain way to appear in your views. Or just how to name everything in the right way to make Rails happy. Often times it's a time saver, but once in a while you kind of wonder if it has to be quite so magic. Also, sometimes those things are dynamically put together, so you can't grep for them in the source code.

msie 16y ago
you have to know a lot of things sometimes those things are dynamically put together, so you can't grep for them in the source code I completely agree. Also: the rails guides are helpful, but the generated api docs suck.
jdelsman 16y ago
As far as I'm concerned, that's quite a cop out. You can understand the magic if you go so far as to drudge through the Rails core code. It's really simple to do, as its all on GitHub. If they are "dynamically put together" (which I'm assuming you mean things like method_missing, etc.), you should increase your level of Ruby knowledge, as that will get you farther when reading the source code. http://github.com/rails/rails http://github.com/rails/rails

keefe 16y ago

>it's completely won me over, replacing almost every single place I'd use PHP which it should, php is terrible. It's OK for many purposes, but there aren't that many spectacular libraries for difficult things, lack of sophisticated IDE support, etc.

jrockway 16y ago
+1. I love it when PHP programmers start calling anything that's not PHP or Rails "blub". Oh, the irony.
jacquesm 16y ago
Some HN'ers seem to hate PHP, I want to know why :) I couldn't care less about a platform someone else uses that I don't use. Familiarity breeds contempt. So I think I'm qualified to rant on PHP because I wrote an awful lot of it over the years and am still maintaining one large PHP project that was written in the PHP2 days, so you can imagine what that's like (we're re-writing that at the moment). If you're happy with rails, more power to you. If you're happy with python, great! Whatever you use, if you're happy with, I'm happy for you. Meanwhile, live and let live. So, PHP may be 'terrible' for you, but it has made me more money than all the other programming languages that I know combined, in spite of all its shortcomings. Spectacular libraries for difficult things? Not on my wishlist. Lack of an IDE? I use vi(m). It's all just work, and work needs to be done. Use the tool that's best for you and move on, don't look back too much and kick at where you came from. And if you didn't 'come from there' you shouldn't be having an opinion on the subject anyway, then you're just parroting.
- fragmede 16y ago
  PHP has a long documented list of shortcomings, but y'know what? Just like shell scripts, it is absolutely fantastic at small one-off but long-lived programs.
  - jacquesm 16y ago
    > it is absolutely fantastic at small one-off but long-lived programs. Like facebook? ;)

angrycoder 16y ago

I think the problem with MVC web frameworks in general is that it makes it makes the easy/boilerplate stuff really easy, but the hard stuff harder. Sure, if you doing a simple CRUD app that is only updating a single table it is fine. Beyond that, you waste so much time trying to figure out how the frameworks wants you to represent composite objects, and debugging the default model binders, then thinking you might have to write your own binder, then just saying screw it and reverting to Request.Form[] and parsing your own requests.

generalk 16y ago
This is exactly the kind of response that concerns me. I'm looking for concrete Rails-specific issues. I understand that, in theory, Rails may suffer from this issue. In practice I've never once seen it. I think Request.Form is an ASP.NET thing. I have no experience there, so I can't comment on it.
joe_the_user 16y ago
I absolutely agree that a complex, n-table, n-page site does not scale with MVC in general. Simplistically, [n-tables] X [n-pages] = n^2 controller methods for n controllers. So trying to make the controllers nice and OO just means each controllers complexity expands excessively. I would be really curious. What pattern do people think scales in this general situation?
- generalk 16y ago
  In the simple case, Rails likes you to have seven controller methods and one controller per table. Realistically I usually end up throwing a few more methods on each controller. This is actually part of the reason I like Rails: it guides the developer towards what I consider to be better application design. I understand that a lot of folks don't agree, and that's cool for them, but I still like hearing why.
  - angrycoder 16y ago
    I can see that working if each of the 7 tables was their own individual entity, but I am talking about a composite object here. Normalized data. How do you manage a transaction across 7 different controller methods? I am not saying their isn't a nice way to do this, merely using this as an example of why people may not like Rails. It forces you to figure out the Rails way of doing things. And that may not always be the best way for you, especially if you are an experienced developer.

joe_the_user 16y ago

Every system I've seen that has some "magic" also has the potential for that magic to reverse itself and become something that seems to work against you. And when that happens, it's easy for the magic to become something you "hate". Rail and Ruby each a lot of this magic. No matter what you say, Twitter is relevant. No matter what Twitter says, Twitter is a Rails success story because Rails got a major, major site up and running fast. And naturally when the magic stopped working, everything about Rails just seemed to work them. It was what they needed until they grew into a site that wasn't well served by Rails. Imagine if I said, "San Francisco is a terrible place to start a business and what proves it is that we experienced wild success and then couldn't rent any more office space, had to split our headquarters and eventually moved to Omaha". How convincing is that?

hasenj 16y ago

Frameworks have limits, the same guys who loved rails had a previous experience with Django where they loved it then they hit a wall and started replacing all of its components. Of course Rails is 100x better than php. I suspect it exhibits the same characteristics of frameworks that make a lot of people turn against Django after some time. It is, after all, an opinionated framework. If people never hit a wall with it, I'd be a bit concerned; perhaps they're probably not trying hard to push their apps beyond limits of the framework.

xiongchiamiov 16y ago

When I first used Rails, I was frustrated by two main things: * Files everywhere! I like starting simple, and you generate all these folders with things I just don't want to deal with yet. * Lots of things were implicit, making it difficult for a newbie to the framework to understand the flow (How do we get from the controller to the template? was one, I think). Now, that was several years ago (a little over 3, now), and both Rails and I have changed. I've been waiting for Rails3 to give it another chance, but haven't found the right project yet. My current gripes with Rails are this: * DHH is a prick. * It's damned difficult to find a good Ruby feed that doesn't get polluted with Rails stuff. My first issue is, of course, not very valid, but I have to admit that it exists. For the second one, yes, I program in Ruby (and love it!), but I'm not using Rails. Even when I do web development in Ruby, it's with Sinatra. So, I don't want to see your frackin' "Ruby tips" that are actually Rails tips! </endrant>

almost 16y ago

Some people don't like Rails. This isn't a problem. It's not a personal insult to you or to your skills or to anyone else who likes or uses Rails. It's sometimes useful to discuss the limitations (in some subset of people's views) of software. I say this as someone who quite likes Rails but doesn't use it at the moment. It just so happens that the bit of web work I do at the moment tends to fit Django better. But don't worry, we don't need to hate each other :) I've flagged this article because I really can't see anything of worth coming out of it. Holy wars are very rarely that interesting.

jacquesm 16y ago
This is rather more topical than 'today is programmers day', and I still see that on the homepage at 190 points.
generalk 16y ago
My intent wasn't a holy war. I've used Rails for over a year. I keep hearing people say that it's slow, or it doesn't scale well, or that after the first 80% of the application is finished it gets in your way. I haven't found that to be the case, but my experience is limited. So I'm looking for any cases where any of these things have actually happened. I want to know if these claims have any substance.
- almost 16y ago
  Of course there are cases where Rails isn't the right solution, that's true of absolutely everything. It's probably fine for all your uses (and for mine too) though. You are not going to get a useful discussion of them with that blog post though. You use an antagonistic tone and target a group of people who largely only exist as a group in your head, that's not going to produce good stuff!

peteforde 16y ago

My two guesses: - more job opportunity at higher billing rates for Rails - it's easy to hate on smug people, unless you're on their team I'm perfectly happy with Rails, because we've now invoiced several million dollars on cool projects that we never would have worked on had we stuck to [in our case, .NET].

PhrosTT 16y ago

perhaps the theory is one day your site will blow up and you'll need to scale... or hire additional programmers. at which point these things are probably easier with a php app... there's a certain safety in choosing the more popular language.

BrandonM 16y ago

<rant> If I'm a good C programmer, if I grok Lisp, if I'm fluent in Python, if I can accomplish damn near any file munging task from a bash prompt, and if I have an understanding of component-based development, then I should be suitable for the vast majority of programming jobs. Yet something like 90% of job postings require X years of experience in Ruby, PHP, Java, or some Microsoft-specific language. Many of the interesting programming jobs have chosen to select for a language that I could learn in a couple hours, work with in a couple days, and use well in a couple weeks, but because I don't know it right now, I'm not hire-able. Background, intelligence, and work ethic be damned, you need Ruby and Rails experience to work here, because after all we have many applicants and someone is bound to fit all our criteria. And while we're on our soapbox, why-oh-why are good programmers so hard to find? Because you're not even trying. You have too much other crap to do, and you're just looking for a quick, safe reason to reject everyone else and have a couple people conveniently left over to choose from. And no, I don't know the ins and outs of b-trees anymore, but give me some time with Google and vim and I'll have a C solution ready to be tested. You know, the way real work is done. So yeah, I suppose I do find myself bitter that I'm expected to pick up a trendy language and platform (and recall every data structure I learned 4 years ago) to even have a chance on the job market. From the outside it just looks like a giant Ruby/Rails clique (or PHP/Cake, or Java/Spring, or whatever technology your company has happened to fall into). We're all forced to learn something that we don't actually need -- we can already get it done with similar effort in another way -- just for you to consider hiring us. And everyone has a slightly different stack that I have to go teach myself just to avoid looking like an idiot in the application process. And it's not just Rails and the languages I don't know (yet!). Even the Python job postings I find almost without fail require experience with Django or some other framework du jour. I mean geez, how long does it take to learn a freaking framework, especially with a bit of early guidance? Stop selecting for the wrong criteria! I'm not one of the ones typically "bashing" Rails, but I understand the frustration of being forced to learn a bunch of crap as part of an elaborate mating game of inefficient, badly-designed hiring practices. Just throw some work my way, give me the email of a knowledgeable employee who can answer occasional questions, start me out at a below-market rate, and evaluate my role and contributions in a month or two when I've had a chance to get acclimated. The filters that employers use are such bullshit, and then to make it worse they slap us in the face by claiming that it's impossible to find good programmers. </rant> What was the question again?

webginja 16y ago

To use Ruby effectively in the enterprise, one needs to look at JRuby - but if your going to go to the JVM why not use something better suited to the JVM and not a port of ruby?

kreek 16y ago

Some issues I think come from the early hype that it was the 'one framework to rule them all'. I personally love Rails but it is a bit heavy and shouldn't be used for smaller projects. But that's not Rails fault it was more a misunderstanding of Rails' sweet spot. For those smaller projects I now use Sinatra. That said when I first started using Rails, four years ago, it should have come with a warning sticker about deployment issues. A smaller VPS that could handle dozens of PHP apps could be only really handle one maybe two Rails apps. Litespeed, Passenger, JRuby, etc. have made these issues go away, but I can see how it might have left a bad impression of the framework. P.S. You think people hate Rails try being a Flash developer on here.

parfe 16y ago

I don't want to be surprised by a framework. http://dev.rubyonrails.org/ticket/10919 http://dev.rubyonrails.org/ticket/10919 The above bug report (while incredibly funny) was a symptom of what turned me off while learning rails. Why would tables be pluralized automatically? A model might change to a word I didn't even know is the correct plural. ( I didn't go any deeper than tutorials. ) Overall I prefer Django as nothing comes as a surprise, and the shortcomings aren't a huge bother for what I do.

generalk 16y ago
Why should be tables be pluralized automatically? Because that's frequently how you'd do it anyway. I deal in a lot of legacy data stores, and I have a lot of "set_table_name" calls. That said, Rails is opinionated, and not agreeing with those opinions seems like a perfectly valid reason to not like it.
JangoSteve 16y ago
It's beneficial to point out that ActiveRecord is no longer tied to the hip of Rails. In fact, in Rails 3, you now have ActiveModel which gives you all the "Active" goodness of model objects without connecting to a specific database at all. In other words, issues like this are no longer a problem in Rails, maybe just in certain modules you can install and use optionally in Rails.

jamesbritt 16y ago

I preferred Nitro over Rails when they both arrived in 2004. Nitro made it far easier to evolve an application from a single static HTML file to any degree of complexity (plus it was faster, thread safe, and more modular). Rails seemed better suited to a very specific genre of application. Great when you're building that app; less so when you needed to color outside the lines. Ramaze picked up where Nitro left. All software is opinionated; I prefer the opinions built into Ramaze. Whatever tool you pick, whatever language you use, make sure the opinions it embodies align with yours, or you'll find yourself frustrated way too often. But I really think the alleged hating on Rails has more to do with how some people perceive its more vocal proponents. Sadly, it all feels like being back in high school again. It's the "rock star" and "hero" nonsense that grates. People would do better to scope out the various languages and tools, learn to appreciate the good stuff, steal the better ideas for their own preferences, and ignore the personalities and drama. Code talks, bullshit walks.

jamie_ca 16y ago

I first experimented with Rails in the 0.7 days, and stuck with it until sometime in the early 2.x series. The general complaint you mention about "it got in my way and I had to abandon it" is basically at the top of my list. As Rails evolved, it picked up a _lot_ of cruft, and when things went subtlely wrong (or I was trying to track down a "magic" method) it was just a big pit of morass to dig through. About that time (nearly 3 years ago) I switched to Merb, the new kid on the block. That's had its own share of pain to deal with, and at work we're now figuring it'll be worth it to migrate back to Rails 3. The Rails/Merb "merger" has resulted in a lot of good architectural cleanup, and being able to live within the regular plugin ecosystem has a lot to say for it (namely, we won't need to maintain the dozen-odd forks for merb support anymore).

atldev 16y ago

I think this is a great question to ask. I feel the same way, and unless I missed it in the comments so far, I don't see any specific examples that would give me pause. I'm loving Rails so far, especially after being able to start from scratch and build a viable, working, commercial, revenue earning app in just a week. I'm sold, but scanning the horizon cautiously.

nlz1 16y ago
http://blog.leosoto.com/2008/12/on-really-disliking-monkeypatching.html http://blog.leosoto.com/2008/12/on-really-disliking-monkeypa...

Pewpewarrows 16y ago

I'm pretty sure the general direction of the comments weren't bashing on Rails specifically, just the idea that they thought the honeymoon wouldn't end (it always does). They went from a very heavy django background, where they saw the shortcomings of the framework (or every framework, really), dabbled in Rails for a day, loved its magic for trivial tasks (protip: most frameworks make trivial tasks easy and magical), and somehow concluded it was superior to django and that they had stumbled on a hidden gem (pun intended). Frameworks have limitations. You will always reach a point in your career working with them that you disagree with one or more design choices, and you will have to deal with a problem the developers never accounted for. Sometimes that problem is easy to solve using your existing framework, and sometimes the framework (in solving 95% of other use cases) makes handling and solving that problem a pain in the ass. It isn't unique to django, Rails, Zend, or whatever else you happen to be using. But pretending that the framework you just discovered is perfect is just silly. Take the language you enjoy working in, find a framework that suits your style and doesn't get in your way too often, and run with it. My apologies for still giving vague, sweeping statements, but I haven't worked deep enough with Rails for it to get in my way yet (I've only done a few simple proof-of-concept sites with it).

DanielRibeiro 16y ago

Avi Bryant answered this here (http://python.mirocommunity.org/video/1186/django-is-obsolete-but-so-is-e http://python.mirocommunity.org/video/1186/django-is-obsolet...), but on Django form. For the projects he mentions, sinatra is more than enough.

nlz1 16y ago

"7 reasons I switched back to PHP after 2 years on Rails" http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_swit...

jcapote 16y ago

There's a major python slant here. I don't know why, but it always feels that way to me as a regular reader here.