Is it fair to accuse Rails of “magic”?

Question

When I first started looking into Rails and Django I was steered away from Rails by Django developers who felt that Rails was a black box which uses an excess of "magic" (leaky abstractions). Upon exploring Rails further I wonder whether this is an uninformed assumption based on not knowing how to achieve customization in Rails without the use of scaffolding. Scaffolding by itself can seem to hide a lot but once you understand how to create a project without it, Rails seems to be as highly customizable as Django. Is this a misunderstanding on my part or on the part of Rails' 'magic' critics?

Answer 1

Rails makes extensive use of Ruby's metaprogramming facilities to do a lot of the grunt work for you, but there's no magic—in the end it's all just code and can be understood given enough time and effort.

Scaffolding was always intended just as a way of getting up and running with performing CRUD operations on your models quickly. The intention was always that scaffolding should be replaced with your real production code.

Answer 2

I wouldn't take a Pythonista's recommendation about Rails any more than I would a Rubyist's opinion on Django, not unless they could demonstrate a reasonable level of understanding of both platforms, at least, and there are precious few who can.

The frameworks have (to my limited understanding on the Django side) similar architectures but grew differently and take advantage of the strengths of the different languages.

I'd agree that Rails has a fair amount of "magic", and the convention-over-configuration thing is a large part of the framework. I can see how that might be off-putting to a Python expert, and that's probably fair - one of Ruby's relative strengths is the meta-programming capabilities that make the magic happen. Perhaps because of that, it generally seems that monkey-patching in Python is seen as suspicious, whereas in Ruby it's commonplace. Not a better-worse thing, just different.

I honestly think you can have a great time developing on either platform. I'd suggest spending two or three days building a simple app on each and go with the one you liked the best. I'd be interested to see feedback on which you chose and why.

Answer 3

What do you think Merb is? It's the flag of Rails developers rebelling against too much magic in Rails.

Rails 3 is an attempt to cut down on the magic, pull in many parts of Merb, and clean things up.

Now is there really too much magic? Maybe, but remember this. Rails is basically a collection of DSLs (Domain Specific Languages) which come together as a framework for web development. That's why it's so clean, it's a language for routes, for templates, or ORM, etc. To make clean DSLs you have to extend Ruby, which requires well, some magic, or metaprogramming.

Django doesn't do that, it wouldn't be the Python way. It's not better or worse, only distinctly different.

Now you asked, is there too much magic in Rails?

Remember Arthur C Clark's Third law of prediction : Any sufficiently advanced technology is indistinguishable from magic.

So perhaps that developer friend of yours was just saying that Rails is too advanced technology for them to feel comfortable using.

For me I can read the Rails' source and figure out what's going on. Sure it's complicated in places, but I've always been able to walk through the source, read the very extensive unit tests, and know how it works. The kernel is also crazy complicated but we don't refuse to use it on those grounds, do we?

Answer 4

您可能会发现花一些时间阅读这个问题的变体的答案是有用的（例如，我在这里解释了我对它的看法）。

Answer 5

I don't see how rails can be viewed as a black box. You have the source. Some of the ruby is a bit tricky and the metaprogramming can make things hard to track down but it all there for you to see. Plus the scaffolding criticism doesn't make sense unless they are talking about the old scaffolds rather than the generated scaffolds which just create very basic code templates that are right there to see.

I'm guessing the djangoist wasn't uninformed but that they really meant something else like that rails uses too much tricky ruby and stomps on a few things it shouldn't by monkeypatching ruby classes. That's a case that could be made.

Of course they really shouldn't badmouth rails because I am pretty sure that Djangos eat babies in Australia.

Answer 6

I think the concept of "fair" is wrong here. It's all a matter of taste. I'm horrified that rails monkey patches the build-in typesof ruby (resulting in things like "5.days"). I consider this magic. Some rubyist might consider it solid engineering.

I think it's objective to say rails does a lot of non obvious things to your language runtime. If you consider this good or bad is up to you.