[PikachuEXE]

I agree Rails only does a great job on structuring when project is started

But any large enough project needs rules for placing files/classes

I don't see how Rails failed in that way

I do agree there are some "magical" stuff like hooks that can be easily abused and introduce bad coding habits/patterns

Wish I can turn them off per class (not for the whole app since they are still sometimes useful)

[JohnBooty]

Yeah. MVC is not always the right tool for the job, but it's generally fine and IMO rarely a terrible fit.

I don't see how that's a Rails-specific problem.

Before Rails, working in the wild and wooly world of Microsoft web dev (with occasional PHP thrown in) I saw some real horrorshow web apps. People hacking together their own confusing and misthought architectures. And those horrorshows were rule and not the exception.

The standardized structure of Rails apps is such a breath of fresh air. It's so nice to step into a Rails codebase and basically know where most things are most of the time.

Admittedly it's also nice to step away from Rails for smaller, simpler apps.

[joelbluminator]

What do u use outside Rails and how was your experience? It's a bit embarrassing I only did Rails with Ruby.

[JohnBooty]

Before Rails I did a lot of work where there was no framework comparable to Rails, in ASP "Classic" and then ASP.NET.

Generally each web app had its own organizational structure. Everything was still "page-based" so your site's file structure would mirror the actual URLs: the code for your product page would be "/product.asp" and your shopping cart page would be "/cart.asp" or whatever. Those files had intermingled markup and code extremely similar to ERB files in Rails.

Conscientious developers of that era would of course extract as much functionality as possible into shared include files. Even in those savage days we tried to separate logic and presentation whenever possible. Early PHP dev worked much the same way.

Needless to say this generally lead to spaghetti code. You certainly could make very maintainable ASP/PHP sites, with a lot of effort -- just like you can find some very maintainable and well-structured shell scripts. But, even so, each "well-structured" ASP/PHP site would have its own structure and it was quite a learning curve jumping into a new one, if you ever had to look at somebody else's code.

Early ASP.NET apps used an even more bizarre set of Microsoft constructs. Code-behind files, etc. Yuck.

Later came ASP.NET MVC which was quite good IMO. It borrowed liberally from Rails which was a good thing.

In Ruby land I developed with both Sinatra and Rails. Sinatra is great and a lot of fun, but you are totally on your own w.r.t. structuring your app. Once your Sinatra app grows past a certain complexity, you will generally just find yourself reimplementing large parts of Rails and encountering the same problems w.r.t. structuring your app.

Rails and MVC are not perfect -- many say other variations like MVVM/MVP/etc are better. Perhaps so. I've certainly had pain points with Rails (too much "magic", high RAM usage) but as far as structuring my applications.... no.