This is mostly bullshit. The guy is trying to do things in Rails the wrong way and complaining about it failing. He does have a few legitimate points, but I guess I'll go at it point by point, because it is fucking long:
-AR find works fine for me, in most cases, in those cases you can always fall back directly to SQL (has happened a total of two times for me). The guy very incorrectly states that the :group stuff will choke in Postgres. It does not. There is a separate driver for each database that will make the queries compliant with the specific DB.
-When using joins, you're supposed to use :include, or has_and_belongs_to_many. These are NOT read only, and work very very well. He's complaining that something he is doing the wrong way does not work. That is because he is doing it wrong, and it isn't SUPPOSED to work.
-I agree with his point about understanding Rails and the options hashes. At this point, I really wish that Ruby had named arguments, as the options workaround gets really annoying.
-I don't understand what he means by quality assurance. Rails has an incredibly large automated testing suite. I've been using Rails for two years and I've found one bug. I really just have no idea what he's trying to get at.
-On the last point, about the "big-picture", he is provably false. If you've written a Rails app and there is even ONE XSS injection opportunity, you've done it wrong. Spend two seconds in the API docs and you will find this function called "sanitize":: http://api.rubyonrails.org/classes/ActionView/Helpers/Saniti...
It helps if you read the fucking documentation before you criticize something.
the parent post is dead on. the guy who wrote the article does not know rails well enough to find accurate criticisms.
the complaint he makes about the options hashes would be solved if someone took the time to document all of the private methods, etc. I like a mix of code + documentations to figure out how something works. Most of the rails contributers prefer to just read the code, which is why no docs exist.
I'll throw my 2pesos in as well and concur here. Though I do feel the pain of traversing down the call stack to dig up where the magic is. Ruby for Rails has a great chapter on digging into Rails core code which helped me a lot.
A lot of this is really a rant, but I do agree with some of it:
"- Reading and, in general, understanding Rails is horribly difficult,
since it's no design and layers upon layers of magic. Very often you will
find 5-7 layers of functions delegating the work deeper and deeper in,
until you arrive to a completely undocumented internal function that in
turn splits the work to three other, unrelated internal functions. Given
that each of those 10 functions takes a hash called "options", each layer
altering it subtly, but none having the complete picture, and that 9
times out of 10 that hash is not documented on any level, figuring out
what your choices are is pure hell. It's made even more fun by the fact
that different parts of Rails are accessible at various points of
handling the request, and you can't just jump in and poke things from the
console, since it won't have 99% of the things that only magically spring
to life once a request is live. "
Methods do really nest pretty deeply sometimes. And since all of ruby's classes are open, people just add stuff by hacking things together. It's pretty much impossible sometimes knowing where a particular method is in the codebase.
amen, if you are coming at it with no other coding experience then I would think its a breaze. my main problem is when you start to dig you feel like alice in wonderland going down the rabit hole.
It's easy to piss on things after the fact. It is pretty common behavior in our field to try and make yourself look good by criticizing others' work. It's usually pretty easy to find things to pick on with the benefit of hindsight, but much harder to create something new.
Well, imagine this rant where "RoR" would be replaced by "java", wouldn't you imagine being the author of the pamphlet ?
I'm frightened by such an uniform behavior in the YC community. By dismissing any dissenting point of view you kill diversity. I remind you that the next fad you (and I) will be trying to catch will be created by a guy bothered by the current state of things. Bothered enough to act (and reunite the "Tipping point" conditions).
This guy attack RoR, he's attacked personally as trying to sound smart. Have you ever criticized anything ?
(my karma will follow the Dow Jones today I think ....)
Uhm... I actually wrote my programming language, Hecl, in Java. While there is a lot I don't like about Java, I still don't like the tone of these kinds of articles. I think after a while you can sniff them out - when they're really trying to point out some deficiencies, and when they're just going for a boost by putting stuff down.
At least that's my take on it. Slinging numbers like 100 and 0 is generally a sign of hyperbole.
I agree instead of bitching about Rails, the guy should be writing about why Weblocks is so great - with more detail than: "because they actually stopped and thought about the whole thing for a moment, and try things that will address the problem as a whole"
My problem is that I'm tired of all these articles proclaiming "Skub considered harmful"[1], "Why Skub sucks", "Skub on rails sucks!" or "Skub ruining CS degrees".
But it just goes round and round and round.
Someone says something bad about Skub then another 6 blog posts pop up defending it and how the author is a douche. Then it just burns through the blog-sphere like a wildfire before burning out. Ready to start again!
Yeah, I've a very good solution : stop upvoting those stories.
But, if you specifically didn't vote for it, it is on the frontpage, so the majority of the group here think this kind of story is worth the energy.
I don't think you could simply replace RoR with java (J2EE) in this particular post. But even if you could: you'd be right to cap on java.
Java makes programming difficult. Some people like that. Many don't.
Ruby makes programming easier. RoR makes doing webapps easier. This guy's premise, that there is no overarching philosophy to RoR, is incorrect, and shows unnecessary ignorance and anger. You have to wonder if he's just projecting.
There was a study done some time ago that showed that people who negatively review something appear to be more intelligent than those who positively review the same thing.
This is probably the case here even though I don't know who Maciej is or what Rails app he's actually written. I think you should use a tool you're reviewing for a project before making up your mind about it.
The study is discussed in a blog post here, http://bobsutton.typepad.com/my_weblog/2006/08/brilliant_but..., the original reference is Teresa Amabile, "Brilliant but Cruel: Perception of Negative Evaluators," Journal of Experimental Social Psychology, 19 (1983), 146-156.
Hating on the latest and greatest thing is a good way to get hits and links if you can't get them any other way. Many comedians have made careers of this by adding humor.
People like it when you appear to have no sacred cows and call out things which might otherwise be thought hip or something.
This guy is trying to apply rails as a solution to the wrong problem space. No wonder he finds it wanting. Typical.
Rails is not a solution for: "create the most well engineered product possible."
Rails is a solution for: "solve this business problem with these limited resourced in this limited time frame as inexpensively as possible. Oh and we're not sure exactly what the business problem is, we'll need to see a few prototypes before we are able to figure it out."
The amazing thing about rails is not how good it is. The amazing thing is how much better it is than most solutions in spite of how bad it is.
Rails is a success because it was created by someone who has a real understanding of economics, business value, and resource limitations. Not because it's a brilliant piece of engineering.
"There's no overarching design or scheme of things, it's just a bucket of tools with some glue poured in."
This premise is wrong, so I almost TLDR'd the post immediately. I decided to skim further, though:
"And to stress the first point again, Rails never concerns itself with the big-picture problem of 'writing webapps.' It only thinks as big as 'outputting HTML strings' and 'querying the DB for a list of things.'"
This is provably false. The average reader of the intro chapter of most Rails books could tell you that, for example, Rails enforces high-level application design patterns like Model-View-Controller, thus exposing his statement as factually untrue. The guy seems to have languages like PHP (or, charitably, Ruby) confused with the Rails framework. Nice try by the OP, but ultimately an unconvincing troll.
MVC, while a valuable application design principle, is not really tied to 'writing webapps.' The article mentions things like the stateless nature of HTTP requests, which are very much bound up in the idea of writing software accessible over the web. Something like Seaside (a Smalltalk framework for developing web apps) is much more aligned with the request-response cycle that is the web. It uses the continuations feature of Smalltalk to map that cycle into a natural language idiom. Neat.
Rails is certainly not the be-all and end-all of web design. Lately it seems to be the 'cool' thing to bash Rails, but I'm not sure that that's warranted either. It seems to be a backlash against all the hype that Rails has generated along the way.
Time will tell whether or not Rails will become a piece of timeless software or if it will simply fall to the wayside.
The Rails team has thought a lot about the stateless nature of HTTP requests, and they've pushed for a RESTful style of handling things (e.g., the REST architecture described in O'Reilly "RESTful Web Services" book). Seaside (and Weblocks) seem to focus on continuations, but I'm not convinced this is the way to go, particularly with richer Ajax and Flex clients.
Ezra Z has made Merb, a lighter and arguably cleaner version of core Rails (minus AR, etc), if you're bugged by Rails core code.
Oh definitely. I didn't mean to imply that the Rails team hasn't thought about things like REST. They are huge proponents of that design philosophy.
One of the big advantages of statelessness is that it scales wonderfully. REST aligns itself with HTTP very nicely. Continuations are a clever compromise between highly stateful applications and stateless HTTP.
Ajax and Flex turn your browser into a smart client of sorts, and I think that a RESTful service design can stand independent of any particular client. It allows for many different clients to interact with your service besides just your particular Ajax web page. In that sense continuations would be perfectly suitable in those situations where you need to keep track of state. RESTful services need to stand independent of a particular client front end.
Anyway, I think that those principles are complementary and should work well together. Ajax (or some other rich client technology) on the front end and REST on the back.
Hmm. I think I may try my hand at writing a small web framework in Lua... that's been kicking around in my head lately.
If you have a very simple app that maps well to CRUD, a REST approach might be all you need. In that case, things are quite simple and scalable on the server side.
If you are building an Ajax/Flex rich client, particularly one that can work offline, you'd want the state on the client-side. Then you could view the server in a very RESTful way while handling program flow in your client app. Under these circumstances, there's less of a win with continuations.
Among the advantages in imposing a RESTful architecture on your server, the most interesting to me is the way that your server becomes a bunch of resources on which you can do a very limited set of things (the HTTP verbs). It imposes an easily understood interface, which is nice if you (or others) write other apps to access your server.
Even if every point the author makes is true - there are still plenty of reasons why you should use rails in many cases. The first of which I'd argue is you can get shit done fast! For startup founders, this is essential. Make something. Put it in front of users as fast as possible. See what they like and dislike. Fix it. Repeat. Rails makes this super fast and easy. Once you get to the point where you really care about any of the things this guy mentions, hire a team to rewrite it. You'll need to at some point anyway...
Huh... that's harsh, and is coming from more knowledgeable Rails hacker than I am, I wasn't aware of this mess with :union and :group in AR, while I don't mind Rails' habit of passing around hashes of options.
The point I agree with him the most is that "different parts of Rails are accessible at different stages of processing the request". This one annoyed the hell out of me, it took me forever to solve the problem of adding your own custom configuration options and accessing them from anywhere in the app.
Have you tried some of the other ruby frameworks, like merb? Merb is not that different from rails, but seems to perform better and can be used with other ORM's than ActiveRecord as well.
When we started nearly two years ago, we had to quickly drop Windows and simultaneously learn Linux/bash, vim, Ruby, Rails, Apache, SVN plus million other things in a hostile and unknown land of old :-))) No, I have not heard of Merb back then, we compared RoR against PHP and went with Rails and so far it wasn't a bad ride. The key to NOT be disappointed is to do everything "Rails-way", i.e. treat DB as a dumb swamp where you keep your models. So far so good.
He is right in most of his critics.But, worse is better.
We computer science guys, and especially those with background in maths, always want to have frameworks reduced to orthogonal concepts that recombine in all possible ways to create very diverse outcome. This leads to algebraic-type formal systems that are very beautiful and powerful in their domains.
You can rarely model a real-world domain in such a minimalistic and mathematical way. Think about it: if it was easy and useful, the natural languages we used would benefit a lot from being unambiguous, minimalistic and mathematical. We have neither evolved to use such languages nor successfully created ones outside narrow artificial domains This, I think, is an important lesson for computer science.
Recently we have seen the rise of Perl, and later RoR. Why are they successful, despite having fuzzy concepts and leaking abstractions? I think this is because they try to mimic natural languages, and put the mathematical clarity aside.
Perl's author is a linguist and had consciously borrowed natural language characteristics:
http://www.wall.org/~larry/natural.html
DHH has emphasized a lot that he wants his DSLs to look like natural languages (don't have a reference right now). Perhaps this means something.
Come on, it has a pretty obvious design. So obvious in fact that Microsoft is copying it for "asp.net" v-next. There is a lot of magic to rails, but let's call it "configurable magic" since __it seems__ most of the magic can be overridden (i'm not a pro). But to say it doesn't have a design? Come on...
I am looking forward to the next release, this one ain't great. MS MVC should go further than rails and will no doubt scale without much hassle. I wish they would just do a standard release of ruby.net in visual studio. yeah there is Ironruby but not the same as a fully supported release like C sharp, vb.net and J sharp.
-AR find works fine for me, in most cases, in those cases you can always fall back directly to SQL (has happened a total of two times for me). The guy very incorrectly states that the :group stuff will choke in Postgres. It does not. There is a separate driver for each database that will make the queries compliant with the specific DB.
-When using joins, you're supposed to use :include, or has_and_belongs_to_many. These are NOT read only, and work very very well. He's complaining that something he is doing the wrong way does not work. That is because he is doing it wrong, and it isn't SUPPOSED to work.
-I agree with his point about understanding Rails and the options hashes. At this point, I really wish that Ruby had named arguments, as the options workaround gets really annoying.
-I don't understand what he means by quality assurance. Rails has an incredibly large automated testing suite. I've been using Rails for two years and I've found one bug. I really just have no idea what he's trying to get at.
-On the last point, about the "big-picture", he is provably false. If you've written a Rails app and there is even ONE XSS injection opportunity, you've done it wrong. Spend two seconds in the API docs and you will find this function called "sanitize":: http://api.rubyonrails.org/classes/ActionView/Helpers/Saniti...
It helps if you read the fucking documentation before you criticize something.