ActiveSupport and Special-Interest Politics

rails methodology

Sun Jan 18 19:12:48 -0800 2009

Like many folks, my early experience with Ruby was largely entwined with Rails. ActiveSupport provies a lot of handy little helpers that are generally useful; and once I got used to having them, I found myself annoyed that they weren’t available in my pure Ruby programs. Like 3.days.ago, or string.blank?.

ActiveSupport continues to grow. Little features like memoization, a term for the pattern @cachedobj ||= computecachedobj; and the StringInquirer, which uses method missing to allow you to do string.something? in place of string == “something”.

ActiveSupport has a reputation for being big, slow, bloated, and filled with features that most people never use. More significantly: very little of it is is directly related to the task of creating database-backed CRUD web apps, which is what Rails is. ActiveSupport is more like a set of extensions to the Ruby language that the Rails developers happen to find useful, so they lump it in with their project.

This everything-and-the-kitchen-sink philosophy is part of what attracted me to Rails - who wasn’t excited about the built-in ajax autocomplete and in place editors when they first saw them? But the accumulation of so many little bells and whistles has given Rails a somewhat deserved reputation for being slow and bloated.

Bells and whistles are a lot like special-interest politics: everyone loves having their pet feature included in the default kit, but the accumulated cost of everyone’s little pet features together imposes an aggregate burden that leaves everyone at a net loss.

(Postscript: The Merb merger may change the ActiveSupport bloat situation somewhat, as this hints.)