I really enjoyed reading Piotr Solnica’s post “My time with Rails is up”—it helped crystallize a lot of thoughts I’ve been having about frameworks and design.
The first thing I need to make clear is that this is in no way a criticism of Piotr or his views. If I had had the same experiences as him, I’m sure I would feel the same way. My experiences have been pretty different, so some of my thoughts are too. From 2004-2010 I worked in Java web development, then from 2010 to earlier this year I worked in PHP. I made the jump to Ruby and to Rails from an ecosystem a lot like Piotr is describing: one with a plurality of frameworks, with libraries that work on their own and can be combined together.
I can’t speak to the challenges of maintaining someone else’s poorly-designed Rails code. All my full-time Rails experience has been with code built by my coworkers at Big Nerd Ranch—all amazing engineers. From them I’m learning how to apply good OO practices on top of Rails, in ways that don’t break Rails. Right now that’s enough for me to feel the programmer happiness Ruby and Rails are known for. Maybe someday it won’t be.
If the Rails core team is disparaging of other design philosophies then that’s unfortunate. I think they’re trying to making decisions in light of Rails’ design philosophy of ease of use—but there are ways to say “that proposal doesn’t fit this framework’s design goals” without saying “that’s a terrible idea.” At the same time, harsh words can go both ways. I’m not sure if OO design proponents in the Ruby world can be harsh, but I’ve certainly seen that they can be in the PHP world, where they conflict with Laravel, a newer framework with many similarities to Rails. It may be harder to sympathize with Rails’ core team since they dominate the Ruby ecosystem; it’s easier when the playing field is level.
The barriers to alternative frameworks and non-framework-based work in Ruby are also unfortunate. Maybe those barriers will come down someday; there certainly is the OO design subculture that could bring that about, if anyone could. But Rails’ momentum may be insurmountable. Ember shows that it’s possible to have a successful convention-based framework without dominating the language ecosystem. And I doubt it will be very frequent that a framework will take over an ecosystem to the degree Rails has; that seems like it may have been an accident of history. I could be wrong, though: the Elixir language is new enough in the public eye that the Phoenix framework might be able to reach critical mass.
We shouldn’t lose sight of the fact that there are some advantages to developers of a framework having a language monopoly. It’s easy to find documentation on what you want to do. You can assume everything works with Rails out of the box, instead of requiring an adapter or being totally incompatible. Ultimately someone needs to build the glue to make things fit together, and because library authors have to for Rails, app developers don’t. This is harder for library authors, as Piotr said, but it’s also easier for app developers.
There’s a middle-ground, too: a framework like Laravel that’s more configuration-based requires less glue because usage of it is more explicit. But that explicitness also means there’s more work for users of the library to do: setting up configuration files and explicitly subclassing or mixing in modules/traits. There are also whole categories of problems that can’t be addressed in a reusable way in an ecosystem like this, because of the combinatorial explosion of possible application configurations. It doesn’t seem to me like you can move away from convention without a significant tradeoff in ease of use. That doesn’t mean I think Rails is the best; it means there’s a tradeoff to consider.
It’s also unfortunate there isn’t an alternative language to move to with quite the same OO purity as Ruby, in my opinion. It may be that concurrency needs mean we’ll mostly all end up on functional languages soon anyway. But I didn’t really start understanding OO design until I got to Ruby, so I’m hoping to solidify that knowledge before I move on to embracing fully functional paradigms.
Piotr asks what will happen to Ruby if a competing framework makes Rails irrelevant, but this doesn’t seem very likely to me. In terms of a convention-based server-side framework, nobody even seems to be competing with it. Laravel is more configuration-based, and Phoenix prioritizes explicit over implicit. If you want a server-side convention framework, Rails is it. It could be argued that that’s because we’ve learned that convention-based is a bad idea, but Ember’s success would seem to counter that. I think it’s more likely that nobody is making new convention-based server-side frameworks because it’s a solved problem; you can’t compete with Rails on that front. And there are enough benefits to that approach, at least for small-to-medium applications, that I don’t see Rails going away anytime soon.