(The fact that some of the things Rails adds seem
unfortunate to me (turbolinks, spring), can add to my
frustration too).
But rails devs heard our pain, and next version of Rails will let you skip turbolinks specifically too (not sure exactly which version it's slated for, and now I can't find the Github issue where I learned about it).
The modularity is nice... although the tradeoff is, ironically, code complexity to support that modularity.
Regardless, every new feature is additional code complexity in Rails, additional dependencies that may break with that feature and need to be upgraded (or that may require that features since it's now default, even though you need to turn it off), and treadmill time upgrading your apps or engines to work with the feature _or_ to disable it.
The way I see it is that Rails is usually the wrong choice for a one-off project that a client expects you to deliver and be able to run indefinitely with no maintenance, but it's a great choice for a prototype or something that will see continual maintenance and enhancement.
My biggest frustration is just the general slowness of Ruby once you get to a non-trivial app size.
Right, the key issue is: Can I apply a security-only patch, fairly confident that it won't introduce any regressions or break anything else in my app?
With Rails, the answer is hardly ever 'yes'. If your Rails versions is too old (which can often mean only around 12 months old), there will be no security patch released -- you've got to upgrade to a new version to get a security patch, with all the treadmill time that entails. If there is a security patch release, it is often bundled with other changes that come with risk of regression (and often deliver on that risk).
I agree it's a "double edged sword"/trade-off to Rails quickly evolving nature. But the pain is very real for many of us.
I would definitely hesitate to deliver a Rails app to a customer that did not have sufficient in-house technical expertise to maintain it. I would not have nearly the same hesitation with a PHP app or an html/javascript-static-only app, even though all of them can need security patching (although the html/js only one probably only has security holes that effect the client!).
If it touches a server and a database then it has a broad attack surface, at least Rails covers a lot of the basics for SQL injection, XSS, and url manipulation.
And, you can patch a Rails app yourself in a lot of cases or go grab a gem that implements the fix for your legacy version. With Github still living on Rails 2, theres a lot of unofficial support out there.
Clearly, finding unofficial patches on github and applying is entering the realm of "this thing sure is painful to maintain", isn't it? Especially if you have multiple apps (at different legacy Rails versions) to maintain, and/or you are an enterprise that hired a contractor to deliver an app but has no in-house Rails expertise.
Yes, yes, then you might say "Well, then don't do that, keep your apps up to date, don't take on Rails apps without in-house expertise." Exactly, right. So we agree.
Yes, bugs happen, in-retrospect-wrong decisions happen. This is life. And this is part of what makes maintaining a handful of Rails apps developed under different Rails versions a pretty labor intensive thing, even with no new features.
Rails maintenance policy is summarized in the OP we are discussing. Rails 4.2.0 is now in beta. Once it is released, support policy is no more security fixes for 4.0. Rails 4.0.x was the latest Rails release until April 8 2014 when Rails 4.1.0 was released. So if you developed an app against the latest Rails minor version in March 2014, within 6 months your app is on a version that doesn't even get security updates, and needs to be upgraded. Yes, it's probably not that hard to upgrade it in this case.
And, yes, when you have a handful or more of legacy apps, and upgrades happen every ~6 months, you spend a non-trivial amount of time on the treadmill. This is my only point. I am not a Rails hater. I use Rails daily. I know of nothing better. There are all sorts of reasons that lead to maintaning Rails apps being such a time-suck, and none of them are that Rails devs are mean or moronic. But it is astonishing to me that Rails inspires a level of 'fanboy'itude that has people insisting that in fact it's not hard at all to maintain legacy Rails apps. Have you done it? With more than one app at a time? With more than 5 apps at a time?
Rails 3.2 is over two and a half years old.
(I still do not choose to write my apps in PHP. Also these PHP apps did not use a Rails-like framework. If I were to do a big app in PHP again, I'd want a Rails-like framework. And indeed I wonder how much that would increase my maintenance costs.)
Rails versions come out quickly, and old versions stop being supported. And it's become a non-trivial part of my time running the treadmill of keeping all my Rails apps up to date, along with compatible dependencies.
I realize this kind of goes with the program. Rails all-volunteer development manages to produce a reasonably powerful and non-buggy product that for the most part is constantly getting better; the cost of this is quick evolution and a maintenance burden for users.
I don't think I'd like the tradeoff better choosing a less mature/powerful/robust framework, but it is increasingly frustrating.
(The fact that some of the things Rails adds seem unfortunate to me (turbolinks, spring), can add to my frustration too).