Taken from the Rails doctrine

One of the best features of Rails is it’s an opinionated framework.

Being opinionated is such a core part of the framework’s philosophy it appears as #3 in the Rails doctrine , where #2 is ‘convention over configuration’ — also a feature of an opinionated framework (we will tell you in advance how stuff is done instead of you having to write anything!)

The Rails doctrine explains why being opinionated is good : safety in numbers, better community support, higher overall quality. It basically means this- let’s not create 6 different gems to handle file attachments — each gem having it’s own community, syntax, philosophy and slightly different features. Instead, when we see a very common web development problem (and file attachments reoccurs in a huge number of projects), let’s bake it into the framework . That’s why Rails 5.2 will introduce ActiveStorage. And that’s why we have ActionCable. And ActiveRecord, and so many more.

I want to see a built in admin in Rails

I have yet to see a Rails project (or any other project for that matter) that didn’t need an admin dashboard at some point. If you have a database, if you’re keeping records — someone eventually will need an easy way to see and modify them.

I don’t want to have to choose an admin gem in a new Rails project or argue with some developer who actually really likes X over Y. I don’t want to have to memorize ActiveAdmin syntax, RailsAdmin, Administrate and what not. We all have much better things to do with our time.

Having a “choice” slows the developers down when switching projects, fragments the community, and causes us to waste energy by recreating and relearning the same thing over and over again. It’s overall really bad for productivity. It doesn’t have to happen if Rails just bakes an admin dashboard into the framework. It’s just an admin dashboard, can’t we come up with a good enough solution for most projects and bake it in? For those 5% of projects that really need their own unique snowflake admin, they can always opt out and use what they want.

The admin that comes with Django is frequently quoted as one of the highlights of the framework, and rightly so. It’s slick, easy to understand, modify, etc. I really loved it.

Authorization and authentication would be nice too

Another area where Django shines is authentication and authorization and the seamless way they work with the Django admin. As a newbie to Django I felt the experience of using them was almost effortless. I think Rails would be wise to bake these into the framework since virtually every project needs authentication and authorization. We are already fragmented between Cancan and CanCanCan (I hope I won’t live to see CanCanCanCan), and then there’s Pundit. And Rolify. And who knows what else. It’s just authorization, not rocket science. I’m sure we can agree on an approach that works for most people and bake it into the framework. The Django community did just that.

Sure, taking a stand will probably cause disagreement. Some people won’t like approach X over approach Y. But taking a stand and being opinionated is what Rails is really good at. Those developers that want more freedom don’t choose Rails anyway: they choose Sinatra, or Flask. Or Node. The rest of us are waiting for Rails to make web development easier by finding common solutions and best practices for common problems.