3 ms·

Yes. Rails has by now certainly crossed into boring software territory – arguably a [positive thing](http://mcfunley.com/choose-boring-technology http://mcfunle

by 1as 9y ago

Yes. Rails has by now certainly crossed into boring software territory – arguably a [positive thing](http://mcfunley.com/choose-boring-technology http://mcfunley.com/choose-boring-technology) anyway – but it remains an excellent choice coming into 2018: - Out of the box, Rails has close to unbeatable developer ergonomics, tooling, stability, and ease of use - Lots of high quality, large companies use it (GitHub, Shopify, Airbnb, Square, Twitch) and have by now figured out how to scale it, often sharing and open sourcing their efforts, e.g. https://github.com/Shopify/identity_cache https://github.com/Shopify/identity_cache - If your product front end is simple, Turbolinks can be an excellent choice (find me a faster, more bug free product than Basecamp) - If you prefer to use a more modern JavaScript solution on the front end like Ember or React, Rails API is a perfect fit - The Ruby ecosystem and community are both very high quality

foodstances 9y ago
Boring yet still very volatile. I wonder if or when Rails will settle down and stop changing everything between major releases causing all documentation to be out of date, gems to break, developer habits to break, etc. Not to mention all of the related tooling like Bundler which seems to spit out new and uninteresting warnings and errors every time I update it. It would be great to be able to write an application using a framework and not have to constantly change the application just to get long-term updates to the framework like bug fixes, security patches, compatibility with new versions of Ruby, etc. Basically Rails-LTS but not from a 3rd-party (and embraced by the ecosystem).
- jeffnappi 9y ago
  Volatile in comparison to what exactly?
  - true_religion 9y ago
    In comparison to Python, where things just work for years without being touched. Upgrading can get you a better api or performance for a specific workload but rarely will it be necessary.
  - gkya 9y ago
    Django. I'm not doing software these days but still following the news etc., and it seems to me that the general knowledge of the tool is still operable since very early releases. I'm not very familiar with Rails itself but when an environment changes very quickly it's both a big distraction and a great inconvenience. I've last worked with django around January 2014, today when I look at a Django app it's the same beast but a bit better. I was also interested in node in its first days, then about 0.12 I lost my interest. Each time I look at it it's a new thing. If Rails is more like node than Django, that's a problem for a beginner, as they'd rather spend time learning fundamentals of web dev rather than learning a breaking change every month.
    - actsasbuffoon 9y ago
      The upgrades have progressively become much less painful. Rails 1 to 2 was a big deal, as the change introduced the RESTful API. Rails 3 was slightly less violent, but the asset pipeline was still a pretty big deal. Rails 4 had a lot of API cleanup/simplification. A lot of meta programming magic was removed in favor of simpler code, which resulted in some rewriting of existing code. Rails 5 was the easiest upgrade yet. ActionCable was the big change, but it’s an addition to Rails, not a replacement for some existing tech. As a result, it doesn’t disturb much existing code.
      - jeffnappi 9y ago
        This has been my experience. I've been working on a large Rails project that started on Rails 4 beta in ~2014. Since then it's been incredibly stable and the upgrade paths have been quite simple from 4.0 to 4.1, then 4.2 and now we're on 5.0 with a few minor updates left before moving to 5.1. Everything would have worked fine if we didn't keep things up to date, but just about everything in the software world needs to be continuously updated due to security updates/patches, etc.
- jeffnappi 9y ago
  We just recently upgraded our large Rails app from Rails 5.0 to Rails 5.1. I wanted to come back to this discussion because I'm actually astonished how easy it was to upgrade. Our project has 1,156 Ruby files consisting of 55,396 lines of actual code (per cloc, rspec and app code). Want to guess how many lines had to be updated to upgrade to Rails 5.1? 24 or 0.04%. Rails is quite stable.
jamesmp98 9y ago
I don't think people understand that boring tech is where most of the jobs are

by 1as 9y ago

foodstances 9y ago

Boring yet still very volatile. I wonder if or when Rails will settle down and stop changing everything between major releases causing all documentation to be out of date, gems to break, developer habits to break, etc. Not to mention all of the related tooling like Bundler which seems to spit out new and uninteresting warnings and errors every time I update it. It would be great to be able to write an application using a framework and not have to constantly change the application just to get long-term updates to the framework like bug fixes, security patches, compatibility with new versions of Ruby, etc. Basically Rails-LTS but not from a 3rd-party (and embraced by the ecosystem).

jeffnappi 9y ago
Volatile in comparison to what exactly?
- true_religion 9y ago
  In comparison to Python, where things just work for years without being touched. Upgrading can get you a better api or performance for a specific workload but rarely will it be necessary.
- gkya 9y ago
  Django. I'm not doing software these days but still following the news etc., and it seems to me that the general knowledge of the tool is still operable since very early releases. I'm not very familiar with Rails itself but when an environment changes very quickly it's both a big distraction and a great inconvenience. I've last worked with django around January 2014, today when I look at a Django app it's the same beast but a bit better. I was also interested in node in its first days, then about 0.12 I lost my interest. Each time I look at it it's a new thing. If Rails is more like node than Django, that's a problem for a beginner, as they'd rather spend time learning fundamentals of web dev rather than learning a breaking change every month.
  - actsasbuffoon 9y ago
    The upgrades have progressively become much less painful. Rails 1 to 2 was a big deal, as the change introduced the RESTful API. Rails 3 was slightly less violent, but the asset pipeline was still a pretty big deal. Rails 4 had a lot of API cleanup/simplification. A lot of meta programming magic was removed in favor of simpler code, which resulted in some rewriting of existing code. Rails 5 was the easiest upgrade yet. ActionCable was the big change, but it’s an addition to Rails, not a replacement for some existing tech. As a result, it doesn’t disturb much existing code.
    - jeffnappi 9y ago
      This has been my experience. I've been working on a large Rails project that started on Rails 4 beta in ~2014. Since then it's been incredibly stable and the upgrade paths have been quite simple from 4.0 to 4.1, then 4.2 and now we're on 5.0 with a few minor updates left before moving to 5.1. Everything would have worked fine if we didn't keep things up to date, but just about everything in the software world needs to be continuously updated due to security updates/patches, etc.
jeffnappi 9y ago
We just recently upgraded our large Rails app from Rails 5.0 to Rails 5.1. I wanted to come back to this discussion because I'm actually astonished how easy it was to upgrade. Our project has 1,156 Ruby files consisting of 55,396 lines of actual code (per cloc, rspec and app code). Want to guess how many lines had to be updated to upgrade to Rails 5.1? 24 or 0.04%. Rails is quite stable.

jamesmp98 9y ago

I don't think people understand that boring tech is where most of the jobs are