It's a bummer this article starts out with a quote about Rails providing a bad OOP learning environment and then talks about the framework itself never touching on the learning of OOP again.<p>--<p><pre><code> "it's lead Rails developers to build huge,
monolithic models that are hard to test,
and violate SRP."
</code></pre>
...Sounds like you need to structure your code better.<p><pre><code> "Have you ever seen a 200 line long
controller method? I have."
</code></pre>
... What on earth are you talking about? This has nothing to do with rails. Structure your code better.<p><pre><code> "The whole idea of logic in templates
leads to all kinds of problems."
</code></pre>
...Then don't put logic in your templates. Use helpers or logic-less templates.<p><pre><code> "MVC has served the web well...
...But I think we're reaching its
limits"
</code></pre>
...If the type of web app you want to make isn't best constructed with an mvc framework, don't use mvc. But honestly, I can't think of anyway to more blissfully implement a RESTfull webapp than with respond_to and resourceful routes.<p><pre><code> "This post is light on examples.
I want this to be the starting point
of a discussion"
</code></pre>
...This exact discussion has been raging for years. Your only chance at gaining ground is through examples.<p>--<p>This brings me to: When is this post from? I feel like it's 5 years old and I've slightly been had.
> The real issue is that changing these things would require some really serious changes. It'd involve re-architecting large portions of things that people classically identify with Rails, and I'm not sure that Rails wants to or can do that.<p>Remember Merb? Remember Rails 2.x -> 3.x? These were not small changes, and the community negotiated them successfully.<p>What I'm saying is, don't get discouraged. The fact that we, as a community, can be openly critical of our tools is the only way to move them forward. Yes, there are a lot of blind followers who will defend anything Rails, but I've noticed that the core contributors are far more open minded about discussing the warts.<p>This doesn't mean they'll agree with everything you've said though. Theoretically pure scripting languages are under-represented in the general community? Why is that? I think the simplest answer is that they're beyond the grasp of most programmers. Digressing further, it begs the question of "what problem do you want to solve?" That is ultimately what any discussion will revolve around. Where will the balance between purity and accessibility land? Fortunately, I think there's progress being made there.
Overly alarmist headline, although there are some good points of discussion in there, especially for Rails newbies. The article left a bad taste because it didn't elaborate on well-known solutions for the problems cited.<p>For instance, the sole problem mentioned with ActionController is the use of instance variables to communicate state to the view templates. The popular decent_exposure gem [1] eliminates this problem by giving you a declarative way to program to the controller's stated interface. It completely eliminates the need for using instance variables in your controller code.<p>[1] <a href="https://github.com/voxdolo/decent_exposure" rel="nofollow">https://github.com/voxdolo/decent_exposure</a>
"It took me two and a half years to realize that Ruby classes in the models folder don't have to inherit from ActiveRecord::Base. That is a problem."<p>Wow! Maybe you're the problem...<p>"ActionController relies on instance variables to pass information from the controller to the view. Have you ever seen a 200 line long controller method? I have."<p>Well I haven't, I've actually seen it in Django. Nothing forces you to write 200 lines controller methods.<p>"The whole idea of logic in templates leads to all kinds of problems."<p>Again, nothing forces to write a lot of logic in the views, you could write the minimum necessary.
The only way to stop putting too much logic in your views is to switch a logic-less templating system. I'm convinced that willpower, coding standards, code reviews, etc would never be enough to stop it.<p>Here's a decent implementation of mustache for Rails: <a href="https://github.com/goodmike/mustache_rails3" rel="nofollow">https://github.com/goodmike/mustache_rails3</a><p>app/views becomes .rb files which act as a sort of presenters.<p>app/templates is where your actual mustache templates go.<p>There's a lot of benefits to this and a huge one is being able to reuse templates on the client-side.
If you're interested in "view models", then check out Draper:<p><a href="https://github.com/jcasimir/draper" rel="nofollow">https://github.com/jcasimir/draper</a><p>It provides exactly that, and it was a huge "a-ha!" for me when I started using it. Suddenly, things that felt icky to do in a helper (because they were tightly coupled to a model) or in the model (because they rightly belonged in a view helper) had a place to live. My templates are nearly fully devoid of twisting logic now.<p>Based on my experience, I think that Rails is missing the decorator/view-model piece, and would benefit from it as a core addition, but one of the great things about Rails is that it's easily extensible. Drop the gem in your gemfile, start using decorators, and go home happy.
From the article:<p><pre><code> "I've written a lot of crappy code, and most of it is due to following Rails 'best practices.'"
</code></pre>
Funny how the author purposes to be following 'best practices' yet is doing things such as writing 200-line methods full of if statements, putting logic in views, etc. It seems the authors woes stem directly from a lack of 'best practice' knowledge, not only of Rails but also of Ruby itself.<p>There will never be a framework that can completely stop developers from shooting themselves in the foot. Education is the key.<p>(I'll admit this comment could be much more helpful in as much as stating what the best practices are which would solve or prevent these problems but I would be repeating ground covered by better teachers than I. The truth is out there, seek and ye shall find, etc, etc!)
Same here. I think those discussions are useful because, as you, I think Rails is really nice, but it does hurt my domain driven design optic. I think many people are searching various way to overcome the ActiveRecord "problem" (/design decision). I saw a presentation by Corey Haines on this recently, and it did gave me some food for thought : <a href="http://blog.8thcolor.com/2011/11/arrrrcamp-fast-rails-tests/" rel="nofollow">http://blog.8thcolor.com/2011/11/arrrrcamp-fast-rails-tests/</a>.<p>I'm currently working on a new Rails project, and I'm delegating more and more responsibility to model objects that does -not- extends ActiveRecord. Works for me, for now.
I've had many of the same thoughts about Rails over the years. I think the view model idea is definitely worth exploring... it would certainly rid models of a bunch of view-related stuff that doesn't manage to end up in helpers.<p>One piece of coupling that really bugs me is doing stuff like link_to(@foo) that will autogenerate a URL based on the class name of the model. To me, this is way worse than the table names and makes the routes highly coupled with the underlying class naming structure. Way too much magic...
"The differences between Django's idea of 'views' and Rails' idea of 'views' are interesting here."<p>Yep. Actually, Django's MVC implementation is commonly called MTV (afaik it's not an official term) because the 'views' are in fact controllers.