The Rails Ecosystem is Healthier than Ever

ben profile image Ben Halpern ・1 min read

This is the first post in a new "flare tag" we're trying out: #healthydebate.

This tag is a place to create posts with the expectation of a debate. If you enjoy debating software topics or watching in on others debate, you might like this tag. I also hope it will encourage more disagreements to congregate in places where everyone has opted in with the understanding that this is a debate.

Of course, everyone must remain respectful. The code of conduct is important and always enforced throughout the whole site.

Have fun!

On to my topic: Rails is doing awesome!

The ecosystem around Rails remains incredibly strong, and the organizations involved will push the tech forward.

This announcement got me particularly excited:

GitHub being on the bleeding edge of Rails is HUGE. Shopify has been leading the way of late, and I feel like this new involvement will push things even further ahead. Rails has done a great job of staying conceptually aligned and avoiding feature creep and complexity creep.

Whether or not you like the Rails API, the ecosystem remains strong.

Ruby is a weird choice for sprawling web frameworks, it sure seems like a toy scripting language, but things have just worked with Rails. The humans involved have pushed things forward.

Rails remains one of the best choices and is only getting stronger. Feel free to debate me on this!

Others are welcome to take on this debate on my behalf. It's a community debate. I'm not sure how much I actually care to take part in the conversation. We shall see. πŸ˜‹

Happy coding!

Posted on by:

ben profile

Ben Halpern


A Canadian software developer who thinks he’s funny. He/Him.


markdown guide

What i love the most about Rails/Ruby is the top-notch quality of documentation.
I don't know how good your favorite language is, what i care first is documentation.
Because without good documentation, how good knowledge can be shared and improved ?


I've been doing Qt in the past and title of top notch documentation (in my personal opinion) is still with Qt.

With Rails you have to read up comments and issues on GitHub.it feels like documentation is a bit behind from actual usage...


I also feel like error messages have been really improving over time.


I said this thing by having little experience with "non-toy languages", what i see is non-existing or very bad quality of documentation. They said: Type is documentation. It's not an excuse for not having a good documentation to welcome and share knowledge among community. It made me sad.


it sure seems like a toy scripting language

Couldn't resist throwing in a little flame bait to get the discussion going? πŸ”₯

In all seriousness, I was briefly talking about this at the beginning of my talk at RubyConf Taiwan this year: it's an excellent time to be a Rails developer. The framework has matured over the years (who still remembers the Rails 1 and 2 days, Merb etc.), the hype has died down a bit and the remaining community seems tighter and more sensible and overall the framework is doing its best to stay relevant. As for the "it doesn't scale" trope, the next time someone tells me that I show them the Chrome developers tools and their horrible TTI caused by massive JS bundles πŸ™„ I mean sure, Ruby's not the fastest backend language one can find, but there's a lot more to an E2E web request that can be a potential cause of slowness.


I've always like Rails a lot but its always been a chore to configure and host it for a production environment with Apache/Other Webserver. Has this part been improved any lately?

Though maybe the answer is DigitalOcean:


I think it has improved a lot, but I agree that this is still not a strength.

Rails can also be a real pain to get setup in development if anything goes wrong especially outside of the Mac ecosystem.


What does dev.to use for its production setup? I've used Apache2 with the Passenger Apache module and RVM. I then use Capistrano to deploy new releases of the Rails app.

Works well once I figured out how to get it all working, but has me concerned it will be hard to re-create when I have to update the operating system down the line.

For what it's worth, I've had a positive developer experience with Linux.

We run on Heroku using Puma because several years ago I was pulling my hair out trying to get my Rails server working and found Heroku and got everything set up in about ten minutes.

Haven't looked back since. Others in the industry have caught up to Heroku in this regard, so I can't say I'm hooked for life, but I've defaulted to them ever since. So when this was a solo project I just went with what I knew.


I agree with Dave.
I use rbenv for Ruby version control on Linux where it has been a joy to learn Ruby/Rails.


πŸ˜„ A shout-out to ActiveStorage! Rest in peace paperclip, carrierwave and others πŸ’€


As much as I like ActiveStorage. it has its shortcomings too, i.e. no nested directories:


Some people seem to like Shrine a lot, but I didn't get a chance to try it out yet.


I still have problem understanding why no nested directories. It was a big "no" without explanation.


I love ActiveStorage too, I use it on my personal website and on all new projects at work.
But one major shortcoming I found, and something I hope will be addressed/changed in future versions, is that images cannot be cached by CDNs. I have CloudFront and CloudFlare caching static assets, but I had to exclude images because ActiveStorage generates 5 minutes-lived URLs from the backing service, and after 5 minutes if the cache tries to refresh itself it returns a 404 error.

As you can see in this issue on GitHub, it is a common concern.


Yeah I faced the same issue with no success :(
How did you work around it?
Seems like ActiveStorage was planned for files rather than for images :/

Well... I didn't ahah
We're just avoiding caching images, inefficient but at least it works. I hope they'll fix it soon


dev.to is still on carrierwave 😱

Promise we'll get to 5.2 soon!


Carrierwave is still much better than ActiveStorage in some circumstance. You don't need two extra queries to get assets of an object, f.e.


It's fairly popular in other parts of Europe though. I had multiple Rails jobs in Austria, and know of quite a few companies that use(d) it. Germany generally has a healthy Rails scene and so do Italy and Spain. There also were conferences in Northern Europe (Nordic Ruby in Sweden and Frozen Rails in Finland), though I'm not sure that's still a thing (Frozen Rails was actually the first Rails conference I attended), I've been seeing more and more Elixir/Phoenix job offers from around there lately.

Ruby and Rails also are doing good here in Asia: India has several local Ruby conferences (e.g. Deccan RubyConf in Pune and Garden City RubyConf in Bangalore) and the big RubyConf India. Taiwan has a regular RubyConf (one of my absolute favorites) that's been going on for several years. RubyConf Malaysia is happening for the 3rd time (I think) this year. Singapore has RedDot Ruby, though they skipped this year for some reason. Last year the first RubyConf in Indonesia happened and the Philippines had 2 or 3 so far, and hopefully we'll finally see the first RubyConf Thailand in 2019 :)

The reason I'm going into this much detail is to point out that Ruby/Rails are certainly not dead, there are actually still new communities forming and conferences springing up, e.g. Kenya just recently had their first RubyConf too.


Wait, you're not going to break up Dev.to into microservices anytime soon?


Why would they, I see no real benefits in turning this website into microservices.

It is a rather small-focused platform, with a small team developing it and no real concerns in terms of scalability.


I was being facetious. There is nothing wrong with monolithic apps.

We worked with a few consultancies leading up to the open source announcement, mostly for a security audit.

I recall one convo where I was describing the system and I said "it's a Rails monolith", and their immediate automatic response was "so you'll want help breaking it up into microservices".

I was like "What, no! I love our majestic monolith". We do use a handful of external services (ours and SaaS), and none of it makes our process simpler. If anything we want to pull more stuff into the core codebase over time.

There are a lot of valid architectures, and monolith is absolutely one of them.

It is amusing to me because a microservice architecture is just a monolith broken up into smaller apps. For a startup, it makes no sense to put the extra planning and context switching onto the team just to have a more trendy setup. As DHH said, embrace the majestic monolith!

a microservice architecture is just a monolith broken up into smaller apps.

I think that's more a result of people doing microservices because it's "cool" and ending up with what I call a "distributed monolith". That said, I totally agree, a majority of web apps don't need a micoservice architecture, especially not to start with.

To be fair, I do see the benefits of microservices in the right scenario.
They allow for small, independent teams to focus on simple, testable and disposable bits of a greater application and this can help reduce time-to-market and embrace continous delivery when building complex and intricated systems.

I worked on a not-quite-microservices-but-still-service-oriented project and it was fun, bits of the application can go online without worrying about the others (we used message queues to decouple them). But it surely was complex to handle and maintain compared to a monolithic application.

Which is why a said "a majority of web apps don't need a micoservice architecture", not "no web app needs a microservice architecture". πŸ˜‰ But that need emerges as a system grows and shouldn't be assumed from the get-go. Nothing is stopping you from using a message queue to decouple parts of your monolith, which gives you most of the same benefits without any of the incidental complexity.


Even though I am pretty anti big framework, a part of me wants to live in that kind of ecosystem for the fun of it, loads of people cant be that wrong huh

The last biggish framework I used was a while ago when ASP MVC came out

Do you have any recommended reading material for someone who's been programming a long time but not done a lot of ruby and basically no rails?


Back when I did this sort of thing, it was the Hartl book that was always recommended.


I'm a frontend dev who just started building with Rails. I haven't had this much fun since I learned React.

I love how quickly you can scaffold apps. The community is also very welcoming.


Fairly common here, especially among web companies that sprang up between 2008 and 2015 or so. I think it's definitely fading as a popular starter choice. Node, Go and Elixir definitely took a huge bite out of its popularity.

Ah, I see. The link you posted is to a file, the actual documentation for the module it defines is here:


Have you see the guides btw? Do you think they are bad too?


@tux0r I take you for a Rails non-believer.


I'm a toy scripting language non-believer.


What about for scripts? Do you have a preferred way to do quick little algorithms?

I would say Python, but I don't want to read the replies ... :-)

Quick little algorithms are - when I have the choice - usually implemented in C or Lisp, depending on their complexity.


Is your implication that Ruby is a toy scripting language?


Here are a few points regarding what makes an ecosystem healthy:

  1. Maturity - Rails is a very old framework (first version almost 10 years old) and as such, is mature. It is possible for a software to be feature-complete and just release bug fixes. The "cons" of maturity are that newer developers will feel that the technology is boring because of wide-spread acceptance in enterprise and smaller shops.

  2. Availability of libraries - It is difficult for a core framework/library to solve every single problem in a particular niche. As such, it needs a plethora of libraries(gems in case of Ruby) which depend on it and solve ancillary user needs. For example, in web development, a framework can provide routing, templates, caching but leave out ORM or DB access or authentication to other libraries. These libraries help a framework stay relevant. Rails has a plethora of gems which solve a wide variety of problems.

  3. Assumptions - A framework or library is created with some core assumptions which are heavily based on problems of that time. Rails solved a very real problem of the time of quick prototyping and easy iterative development. As times change, the pressing problems of developers change as well. An existing framework may have to reinvent itself or risk being replaced by newer technologies which solve the problem better.

  4. Inertia - A framework has to maintain a balancing act in terms of making changes. Breaking changes displease existing users while no changes lead to code smells due to old mistakes never being fixed. Add too many features and the learning curve and discoverability is affected.


This is pretty amazing. Both GitHub and Shopify are huge, billion dollar companies running on the original apps made over a decade ago. And they now both on the latest Rails, helping to push the framework forward [1]

I can't wait for y'all to see what we upstream now that we're in a position to give back and improve Rails. My keynote; Rails 6.0: Scalable by Default [2] at RailsConf was just a small portion of our plans for Rails. [3]

There are also work from Discourse on Rails performance, Ruby is getting a Method JIT. [4] and working on more pref work. TruffleRuby is close to 1.0 and it is available on all ruby manager [5]. The Open Source build is now also available on macOS as well.

There are lots more, and all of them were years in making, It took a year for Github to get to latest Rails release.

For the past few years, many have been writing off Ruby Rails, Ruby is comparatively expensive to scale ( and it still is ) , we expected other frameworks to catch up in terms of productivity, and will spell doom to Ruby Rails. Not only has such framework yet to appear, Ruby Rails continues to improve on all front.

I say the best days of Ruby Rails is yet to come.

[1] twitter.com/dhh/status/10305284762...
[2] speakerdeck.com/eileencodes/railsc...
[3] twitter.com/eileencodes/status/103...
[4] twitter.com/k0kubun/status/9601125...
[5] github.com/oracle/truffleruby/blob...


I've been doing Rails for a while, but until Rails 5 it felt like a burden. I always preferred sinatra/roda over Rails. Tried playing around with other frameworks...

But somehow after working more with Rails 5. It became my default option for a framework. Eco-system became mature enough to have good choice in gems, that satisfy my picky standards. I hardly have 'I'll write a simpler version of this gem in couple of days' moments and I feel like I have more time to do meaningful work.


Every major Rails release felt like a significant improvement (though the migration from 2 to 3 was no fun), but with 5 everything really started to feel a bit more "grown up" :) There are still some parts I don't particularly enjoy, but they are easy enough to ignore.


I think to embrace Rails one needs to embrace the "manifesto". I was learning Ruby and Rails a few years back and decided to give up just because it was too magical and its convention was very "dictatorial" to me. I went straight back to Python.

As I've grown more as a developer and had a few more languages in my toolbelt, coming back to Ruby and Rails wasn't so bad. Things started to make more sense and fall into places. (Symbols make sense to me now that I've known Clojure. Lack of parentheses aren't a stranger any more now that I've known Ocaml) I think Ruby (and Rails as a derivative) is a great attempt of an expressive language that's not too mind-bending (as in many functional ones) and yet very simple and even human-friendly.

Reading up the Rails Doctrine by DHH is a pretty good way to befriend Rails. Rails is really pleasing if one can start thinking less about perfection and idealism in a tool and more about shipping.


I mostly agree, although since I started on Rails 5 my perspective doesn't go back very far.

I'm a little concerned with the pace of adoption of HTTP/2 features. Rails just got early hints for pushing assets, despite discussions about H2 and Rails going back to at least 2014. A quick search reveals zero info about whether the Rack/Rails ecosystem supports header compression. The most popular deployment option, Heroku, doesn't support H2. This concerns a feature that reached all major browsers over three years ago.

Webpack support has been great for modern frontend tooling, though the shiny new Webpack 4 was released months ago and support via the Webpacker gem is still in prerelease.

So yeah, working with Rails is awesome, and constantly getting better. That's why these few exceptions stick out to me, because they represent little pockets of stagnation in an ecosystem that consistently makes my work better and easier. These are pretty luxurious complaints to have, all things considered.


The most popular deployment option, Heroku, doesn't support HTTP/2.

A lot of Rails apps are deployed on Heroku, I feel like if they started supporting it there would be more interest by the Rails community to go "HTTP/2 first"


I'm currently working on a company project with Rails 5.2. We're still on much older version of Rails for the majority of the main product so I can clearly appreciate the progress.
In particular I love how they managed to make Rails 5 much more modular and enabling only the things that you really intend to use keeps the resulting application much lighter to run and work on.


Hi @ben , through this DHH tweet

I came across this recent post Upgrading GitHub from Rails 3.2 to 5.2

It might help :-)


I think a major part of Rails' popularity in US/Canada is because it started in the States. I read an interesting article once about Ruby + Rails in US vs Europe. Wish I could find it...


Interesting. Can you point out what you found lacking and which documentation you preferred? Thanks!