We escaped from the complexity of Java and ended up with the complexity of Rails

(written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at: lawrence@krubner.com

For me, the correct way forward is Clojure, which allows its jars to compose in very elegant ways. But I think this is very well said:

Is it the complexity that Refinery brings to the table? Maybe. Refinery does what it does, but it is something of a beast. If you follow the rules closely, you’ll end up developing a Rails application with an excessive number of Engines, which is really just another way of saying that you’ll be fumbling through a messy file explosion. (What view is that engine in? Hold on, let me click through five levels of folders….) There are those of you who will shout “Sinatra, you should use Sinatra?” But that’s really not what I came to Rails for.

I know I have unrealistic expectations. I want it all, and I want it to be easy: I want straightforward defaults, but I also want customizations to be things I can understand. Take the intersection of Devise, Refinery, and Omniauth as an example. All three of these frameworks are first-class, don’t get me wrong. (I lied, Devise and Omniauth are first-class, and Refinery is an awful mess.) Making them work seamlessly together is an obtuse nightmare – a documentation desert littered with wreckage.

Frameworks that Eat Frameworks don’t like it when you Customize the Frameworks they Eat

The problem is really that once you start making use of Rails and all of the frameworks built atop of Rails you end up creating an opaque mess of customization. One framework, say Refinery depends on something like Devise. Customize anything and good luck upgrading.

Who really knows what happens during the login process? Oh, I know, we’ll use RubyMine to step through this unpredictable mess. I need to make a simple change to how routes work… oh look Routes have become incomprehensible because you now have 12 difference Refinery engines.

You’ll find yourself staring at incomprehensible mega-frameworks maintained by developers who are unapologetic about how little they care for writing documentation. You’ll also end up with the most common pattern from Hell: the single Rails application that runs an entire business.

In the year 2013 it is difficult to remember why Rails was such an explosive breath of fresh air, back when it burst onto the mainstage in 2004/2005. The essay that I think best captured the switch in popularity, from Java (and EJBs and Struts, etc) to Rails, was “The departure of the hyper-enthusiasts” by Bruce Eckel, written in December of 2005. He wrote:

“One of the basic tenets of the Python language has been that code should be simple and clear to express and to read, and Ruby has followed this idea, although not as far as Python has because of the inherited Perlisms. But for someone who has invested Herculean effort to use EJBs just to baby-sit a database, Rails must seem like the essence of simplicity. The understandable reaction for such a person is that everything they did in Java was a waste of time, and that Ruby is the one true path.”


The pushback against Ruby/Rails has been building for a long time. There’s always been jokes about Ruby being slow:


But there was a stretch from around 2005 to maybe 2008 where Rails seemed to defy criticism. It grew and grew, despite the criticism. I tried it for a project in 2006 and I became a fan. The easy use of 3rd party code, via gems, was much easier than anything I had known in Java or PHP.

I do not know a way to say when some of the criticism began to stick, but clearly things have changed. I have my own personal experience: once a fan of Ruby and now a fan of Clojure. And others have moved on — there was recently the conversation about multi-threaded Ruby apps, and it seemed to me all the smart people agreed that jRuby is the future of Ruby:


If I had to pick one moment when some of the criticism against Rails began to take hold, even among those who had once favored Rails, it was Zed Shaw’s insane rant:


Even though the tone is insane, he made some points that stuck in people’s heads, including mine. This was important to note:

“I believe, if I could point at one thing it’s the following statement on 2007-01-20 to me by David H. creator of Rails:

(15:11:12) DHH: before fastthread we had ~400 restarts/day

(15:11:22) DHH: now we have perhaps 10

(15:11:29) Zed S.: oh nice

(15:11:33) Zed S.: and that’s still fastcgi right?

Notice how it took me a few seconds to reply. This one single statement basically means that we all got duped. The main Rails application that DHH created required restarting ~400 times/day. That’s a production application that can’t stay up for more than 4 minutes on average.”

And even now, in 2013, when I have to set up a new server with Rails, even with Nginx and Unicorn and all the other systems to help me, I find Rails annoying to set up, especially compared to the simplicity of PHP running on Apache or a Clojure app bundled up with something like “lein uberjar”.