What makes Rails a framework worth learning in 2017? originally appeared on Quora: the place to gain and share knowledge, empowering people to learn from others and better understand the world.
Answer by David Heinemeier Hansson, Creator of Ruby on Rails, Founder & CTO at Basecamp, on Quora:
The same reasons why it was a framework worth learning in 2004. The more things change, the more they stay the same. While we've seen a lot a progress in the JavaScript world, we've also seen a regression to the complexity-laden world that Rails offered refuge from in the early days.
Back then the complexity merchant of choice was J2EE, but the complaints are uncannily similar to those leveled against JavaScript today. That people spent hours, if not days, just setting up the skeletons. The basic build configurations. Assembling and cherry-picking from lots of little libraries and frameworks to put together their own snowflake house variety.
The core premise of Rails remains in many ways as controversial today as it was when it premiered. That by formalizing conventions, eliminating valueless choices, and offering a full-stack framework that provides great defaults for anyone who wants to create a complete application, we can make dramatic strides of productivity.
It's somewhat surprising to me that despite the astounding success of Rails, that there hasn't been more competition for this proposition. The vast majority of activity today is for yet another option on the a la carte menu. Yet another build system, yet another view library, yet another ORM. Very little activity in integrated solutions.
I guess the answer is that the foundational proposition of Rails continues to cut against the psychological grain of most programmers. That by reducing choices and accepting community conventions and answers to most of the basic questions in web development, you end up better off. Less unique, less tailored, but in ways that just don't matter anyway.
Anyway, that's the big ideological appeal of Rails. I've elaborated further on convention over configuration, the a la carte/omakase conflict, the appeal of integrated systems, and other core values of the Rails community in The Rails Doctrine.
After reading that, you'll probably have a pretty good idea as whether Rails is something for you or not. If you can't recognize any of the struggles outlined in that document, or you just don't like the solutions presented to those struggles, the particulars of Rails technology probably doesn't matter much. If that document resonates, or at least piques your interest, read on.
On top of these ideological choices, we've built an incredibly pragmatic and multi-paradigm web framework. When people hear "web framework", they sometimes think, "oh, that's just some stuff to generate HTML, right?". And in that definition, some might see it as though Rails competes against something like React. And I suppose it does, but in a very remote way that isn't very useful to thinking about whether Rails is right for you or not.
As I talked about above, Rails has an incredibly ambitious mission. In the full-stack goal lies a pursuit to deal with just about every piece of code needed to connect databases and no-sql stores to a business domain model written in Ruby to a set of controllers that expose that model via REST and then, yes, finally to HTML. But that last step is a small minority of the code and focus of Rails.
So if you think that client-side MVC, React, Angular, or whatever is The Future, then you're still squarely in the target audience for using Rails. Because the bits you use to design your HTML/JavaScript-based UI still needs to connect to a back-end domain model that saves stuff to the databases, computes things, enqueues jobs for later processing, sends out emails, triggers push notifications, and all the other stuff that real apps need to do.
And that's where the meat of Rails sits. In what happens once that POST or PUT or GET is triggered. Now, as I said, Rails is full-stack by default. So of course we also include answers for how to generate and update HTML. We have some phenomenally productive answers in Turbolinks and SJR, but even if that path doesn't appeal, everything that leads up to generating that JSON is still stuff we'll have in common.
Anyway. That's a very long pitch for two basic tenets of Rails appeal in 2017: 1) We have a unique ideological foundation that's still controversial today and offers the same benefits against the mainstream choices as it did thirteen years ago, 2) We have a pragmatic, full-stack answer that could be formulated based on that ideology that still offers amazing productivity from the second you run the rails new command.
Oh, and on top of all that, I've saved the cherry for last. You get to use Ruby, which, even in a world that has rediscovered the benefits of functional programming and immutability, remains the most extraordinarily beautiful and luxurious language I've yet to encounter. Just look at some code. I dare you not to fall in love.