[jrochkind1]

My biggest frustration with Rails at the moment is maintenance of my Rails apps.

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).

[JohnBooty]

I feel you on the treadmill pain!

  (The fact that some of the things Rails adds seem
  unfortunate to me (turbolinks, spring), can add to my
  frustration too).

For those reading this, just wanted to add that the Rails team puts a lot of effort into making things fairly modular. For example, disabling "turbolinks" is as easy as removing one single line from your .gemfile (the config file in which your gems are listed)

[cheshire137]

And remove `//= require turbolinks` from your application.js. And remove `"data-turbolinks-track" => true` from your stylesheet_link_tags and javascript_include_tags.

[amccloud]

Or rails new hello-world --skip-javascript

[jrochkind1]

But maybe you don't want to skip all javascript.

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.

[cpursley]

A friend of mine focuses on just this: Keeping Rails apps up to date and maintaining existing projects:

https://www.linkedin.com/in/alsnow

http://rails-uptodate.herokuapp.com/

[jrochkind1]

Does he enjoy that work? It sounds miserable to me.

[timruffles]

Sounds like teams might pay a lot to have someone else do it :)

[dasil003]

It's definitely a double-edged sword, but I don't think Rails could have staid relevant without being one of the most aggressive frameworks in terms of breaking backwards compatibility.

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.

[ufmace]

I don't really see on Rails being wrong for a one-off project. It should keep running just fine as long as you don't update anything. The only thing they'd be missing out on is security patches, but what language/framework doesn't have security patches that requires updating something? It usually isn't too important anyways, as long as the app isn't externally accessible.

[jrochkind1]

> The only thing they'd be missing out on is security patches, but what language/framework doesn't have security patches that requires updating something?

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!).

[ch4s3]

>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.

[jrochkind1]

Sure, you can do lots of things to try to maintain your old Rails apps, but none of them are easy and reliable, especially for those who aren't Rails experts (but may be developers).

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.

[sudhirj]

Holding Rails to a minor version is quite easy (just specify it in your Gemfile) and updating patch levels shouldn't break any of your code. And security updates are still being released for Rails 3 where applicable, although 4.1 and 4.0 have already come out since then.

[jrochkind1]

Updating patch levels _has_ broken my code, several times, over the past ~18 months. Sometimes it's acknolwedged as a regression and another patch is released fixing whatever went wrong; there has been at least one time that did not happen (I could find it if you really don't believe me).

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?

[jroesch]

I second this. I recently did a port from Ruby 1.8.7 to 2.1.2 for a large Rails app (approx. ~350kloc between test and app) and in the process I was forced to update lots of dependencies. In a few places so called "minor" patches had big effects. It became clear to me that when your app gets to a significant size juggling the interactions of constantly moving versions of your Gems, Ruby, and Rails causes things to become complicated quickly.

[rhizome]

If your Rails versions is too old (which can often mean only around 12 months old), there will be no security patch released

Rails 3.2 is over two and a half years old.

[rhizome]

What forms of software development don't involve maintenance and upgrades?

[jrochkind1]

It's a matter of degree. I have PHP apps which have run for years with minimal hands on them. All they need is an upgrade to PHP, which sometimes doesn't require touching the app source code at all, or sometimes requires relatively minimal (compared to my rails experience) updates to the source.

(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.)

[tim333]

I guess they all do to an extent although I've been mucking about with web2py partly because of their "We have not broken backward compatibility since version 1.0 in 2007, and we pledge not to break it in the future" stuff.