Hacker News Reader

Comment by matt4077 | Hacker News Reader

> - Rails went on to release subsequent versions, each of which advocated doing a near rewrite of working code and obsoleted/broke many of the libraries in the ecosystem.

That's simply wrong. I've maintained a moderately-sized Rails app since 3.x, and updating never took more than an hour or so, even for the major version changes.

It's also deeply unfair to the Rails team. Your timeline should include, as the first entry:

- Rails 1.0 is released, showing the web development community how to structure a project, delivering us from XML, and banishing config.backup.inc.php3 from our nightmares.

Rails came about in a world of SQL embedded in html, or (almost worse) the idiotic idea of "templating languages" that were poorly designed re-implementations of php ("but this time it's just for templates!"). Testing meant clicking through your application, and javascript was exclusively used for replacing the deprecated <marquee>.

View on HN

Rails was a massive innovation [1] because making a CRUD webapp in other contemporary mainstream environments, like Struts, ASP, PHP4, or fresh PHP5, was either unnecessarily repetitive, or filled with having to tinker with external config files that bootstrapped the frameworks and taught the stack how to map the incoming http requests to transactions in your database.

Sinatra was something else entirely; it was a REST router DSL. The two are not, and never were directly comparable, except in the sense that they came up as good answers when someone asked "How do I make a web-exposed application with Ruby?". It's unfortunate how often they're compared, when they were both revolutionary in their respective categories, and both went on to inspire many other frameworks in other languages that borrowed their ideas.

[1] https://news.ycombinator.com/item?id=12763681

Before I heard about rails (pre 1.0) I had been doing some stuff in PHP that was quite similar to Rails simply as my preferred convention. So when I saw Rails the thing I was most impressed by was Ruby, a very nice (aesthetically) language.

It took me longer to realize that I would prefer not to use ActiveSupport or to allow any of the monkey patching and metaprogramming-because-i-can that became en vogue in the Rails community for a while.

I think that if DHH had known about REST sooner, Rails controller layer would have been identical to Sinatra.

The convention for building controller classes in Rails involves several more layers of indirection than Sinatra... the routes.rb file becomes a lookup table for classes whose names all fit a pattern that the programmer should not have to be aware of. The flexibility of the router is still nothing beyond what Sinatra accomplishes with its matching DSL.

This is a great comment, but I feel like you might have missed out on all of the fun of upgrading Rails 2 => 3, which was especially painful. Some large applications are still stuck on 2.x and pay third parties for support because the changes were so large. They were mostly for the better of course, but there's a good chance the parent comment experienced this pain, and this is what they're referencing.

And that was pretty much it. Neither 3 -> 4 nor 4 -> were nearly as painful.

Both of my Rails apps were on 2.3 for this reason for 5+ years, though the new owners might have migrated. When I specced it out for one it would have been 2+ weeks of solid work.

I realized after 3.x came out that committing to a large framework and associated ecosystem comes with a significant cost/tax that is often not worth it (but sometimes is).

I had a Rails 0.9 app that I'd carefully upgraded to Rails 2.3 (and then done security backports for) running for just over 10 years. Decommissioned it last month. The Rails 3 upgrade was certainly one step too far for that app :)

> moderately-sized Rails app

How many models? How many gems that hook into the framework?

> Rails came about in a world of SQL embedded in html

Great point. Rails deserves tremendous credit for showing people the light in many ways.

AOLServer did that many years before Rails happened, but many developers weren't paying attention.

Scripted in Tcl. Would be happy if we had this instead of JS today.

We updated from Rails 3 to 4 ~1 month and a half ago. Our Gemfile has 138 lines and we have ~70 models. We updated everything and did a full regression testing to fix all the new bugs within a sprint (2 weeks) while also working on a bunch of other tasks.

This just means you had it easy. You don't feel the pain of teams that started on Rails earlier and have more complex apps.

I've seen a Rails application that started on Rails 1 upgraded all the way to Rails 4, and soon will go to Rails 5.

It has close to 400 models, 500K+ LOC (not including gems), almost 30 obsolete "plugins" that must be internally maintained and kept working with new versions of Rails.

The upgrade from 2 to 3 took nearly a year on this project and that was with 2 people. The upgrade from 3 to 4 was roughly 6 months.

> The upgrade from 2 to 3 took nearly a year on this project and that was with 2 people. The upgrade from 3 to 4 was roughly 6 months.

That is typical in my experience for a non-trivial app.

Yeah; I've upgraded multiple complex Rails applications so this is not something that surprises me in the least these days. It's just people in here saying they have "moderately complex" apps that they upgraded in 2 weeks.

I would say those are likely not very complex applications they are upgrading.

That's about what another developer and I took to move a similar app from 3.2 to 4.2. We should move it again to 5.1 as soon as the customer agrees to invest in it.

I think the biggest step was between versions 2 and 3, when Gemfile appeared. Then the asset pipeline (3.1?).

All considered, the time saved because of following reasonable conventions trumps the time spent upgrading. I'll be updating a Django app from 1.8 to 1.10 soon, I'll be able to compare it with upgrading Rails.

My first experience with Rails was inheriting a rails 2.3 application. It was never ported to 3.x, and limped along for a good 4 years in maintenance mode before being replaced by a Java app.

But sure, upgrading apps from 3.x up through current is pretty trivial.

Reply on news.ycombinator.com