[jlgbecom]

RoR has a lot of advantages for rapid development and prototyping early on. I think over the course of the development cycle, the advantages even out with other frameworks. In other words, for the first 10% of your development, you'll get much more accomplished than if you decided to use pure Ruby (or even Django or Symfony).

However, this "magic" comes at a price, and at some point you will hit a wall, and if you're a very attentive programmer, you'll have been paying attention to what the magic has been accomplishing without you behind the scenes, and you'll be able to figure out a way around it without scrapping your code base. If you haven't done that, then you're going to pull your hair out in frustration.

To be honest, I'm not a huge fan of rails or other magic frameworks for anything other than prototyping, but ymmv, I definitely understand why people like it.

[texel]

I've heard these references to "hitting a wall" a few times now, and it's a bit perplexing. From what I gather, it means that you'll get to a point where you need to understand more about the underlying framework in order to accomplish a particular task. Isn't this a given in any environment? Perhaps in some other stacks, you need to get your hands way dirtier way earlier, so the learning curve is much more spread out. But I don't think I've ever run into an issue with Rails where I've thought "oh no, the framework can't do this... time to start over." It's just Ruby, the entire thing is well documented, and there's a very helpful community glad to answer just about any any question you might have (in my experience, anyway).

That isn't to say that Rails is a panacea, or even appropriate for projects of every shape and size. But if you're building an MVC web app, then it's really well thought out, allows you to be very productive, and in my dealings with it, those benefits don't go away, even as your application grows significantly in scope and complexity. YMMV etc etc...

[trustfundbaby]

> However, this "magic" comes at a price, and at some point you will hit a wall

Only that wall is at the end of a 50 mile runway. Don't let these sorts of pronouncements scare you ... by the time you get to this bogey man 'wall' you're going to be doing a million page views a day, dealing with replicated databases or just generally dealing with really big big problems. And even then you'll have a very supportive community of people who have had the same exact problem ... (example ... github coming up with Unicorn to help them server pages in a better way for them).

Long story short, for starting out and even a good ways into any application lifecycle. Rails is going to do you just fine.

[baddox]

What is the difference between Rails and Django in the first 10% of development? I'm pretty into Django right now, but haven't yet given Rails a shot other than reading a short book about it.

[liamk]

Although this has been just my experience, Rails' convention over configuration means that there is minimal configuration needed to get a new app up and running. I have found that Django needs more configuration (then again I'm a Django novice). So perhaps one spends a greater proportion of the first 10% just doing config with Django.

[japherwocky]

Mostly, python v. ruby; they're different flavors of a pretty similar Kool-Aid.