On The Desired Complexity of Rails

Posted by Brian in Rails (August 21st, 2011)

I attended Madison Ruby this weekend and got a healthy dose of knowledge from some very talented presenters. Some of the talks focused heavily on improving our practices, especially in Rails applications.

Jeff Casimir talked about making views nicer by introducing decorators. These are relatively simple to implement in a language like Ruby, but Jeff created a nice gem to make it even easier, called Draper.

Several talks mentioned using decent_exposure, a gem by Stephen Caudill, to keep instance variables out of views, as Rails does a somewhat nasty hack to get instance variables from controllers.

Then today, I saw another article talking about how Rails code could be made even more easy to maintain by leveraging Dependency Injection, a well-known, and very very useful technique.

On a few applications, I could have used a couple of these techniques to make the code easier to maintain later. And on one I did use a proxy instead of helpers in a complex view. But in the last six years of working on projects for clients, other consultancies, and even when I’ve mentored others, using these patterns would have been a huge jump in complexity for the majority of the projects.

When I decided to use Rails, it was because it was a productivity boost. When compared to Struts, Spring MVC, or other similar frameworks, Rails cuts a lot of corners in exchange for this productivity.

But seeing a number of respected thought leaders looking to bring this complexity to Rails makes me wonder…. is Rails (the community) growing up? Are we out of the “teenage kid that knows it all” phase? Are we done telling Java and C# programmers that they’re not “with it”?

Since it came on the scene, Rails, through decisions made by developers and the core committers, has evolved from something a PHP developer or Java developer would find easy to pick up to something that is much, much more complex. It’s no longer a framework for beginners, but rather a solid foundation and collection of “best practices” to build modern web applications. Rails is now being used to build bigger and more complex applications, and that complexity calls on us to revisit concepts like decorators, proxies, service objects, and dependency injection, the very “high ceremony” things that Rails developers were proud to avoid a few years ago.

While I don’t expect these kinds of things to make it into Rails itself, I do expect these concepts to gain traction. But I hope they only gain traction for the 5% of the situations where they’re needed, rather than for the sake of “well, so-and-so said it was good, so I’m doing it.” Using these tools to mediate complexity in applications adds a different kind of complexity, and that’s worth some thought, especially since, as I was told several times this weekend, there’s apparently a shortage of talented Rails developers these days.

Proper use of these object-oriented concepts in the right place will make our projects better. But it’s vital that we truly understand when we should apply these patterns so we can decide when the additional complexity is warranted, and where it’s overkill. As I was reminded this weekend, there is no “golden path” in Rails.

I encourage you to explore these things. And read Design Patterns in Ruby
while you’re at it, especially if these concepts are new to you.

2 Responses to ' On The Desired Complexity of Rails '

Subscribe to comments with RSS or TrackBack to ' On The Desired Complexity of Rails '.

  1. bryanl said,
    on August 22nd, 2011 at 10:53 am

    You’ve stumbled on the fine line of “should we make this easy to code, or should we be nice to future developers?” I could type paragraphs and paragraphs of reasons to keep things simple, but I’d just be wasting my time.

    Projects grow up. Projects get transferred to other developers. The time tested patterns that may bring with them a bit of complexity always seem to be the better solutions. The trick is to turn the complex pattern into a simple abstraction.

  2. Joe Fiorini said,
    on August 22nd, 2011 at 10:56 am

    Well said Brian. I too have seen a use for some of these more complex patterns in my projects. Let’s always remember that we’re using Ruby. For example, dependency injection is useful in some cases in Ruby, but any Ruby developer worth his salt should be able to think of a better way to configure an IoC container than a complex XML schema. As a more concrete example, when I’ve written presenters (similar to the decorators you mentioned) I make heavy use of Ruby’s Delegator class so I can completely wrap the model. IMO far more elegant than what I could do in a less dynamic language. Rails was built to make developers more productive. As we apply these patterns we should use that as our constraint to build better solutions than what we’ve had in the past.

Leave a reply

:mrgreen: :neutral: :twisted: :shock: :smile: :???: :cool: :evil: :grin: :oops: :razz: :roll: :wink: :cry: :eek: :lol: :mad: :sad: