I actually consider Rails in its 3.x+ versions to be a pre-selected combination of smaller libraries - because it really is. Don’t need mail? Remove actionmailer. Don’t need a database? Remove ActiveRecord. The benefit is that when you do need those tools, they are there, they work together, and you don’t have to choose.

That’s not always perfect or suitable for every use case, but it’s not a bad thing.

Agreed; those days are when I worked on Rails, and that was a lot of the things that made 3.x different from 2.x. I wrote a blog post about it that’s one of my most popular ever: https://words.steveklabnik.com/rails-has-two-default-stacks

This sentiment also was a major theme of my forward to The Rails Way.

I’ve been thinking about this stuff a lot in the context of Rust...

> I’ve been thinking about this stuff a lot in the context of Rust...

Do you mind extrapolating further, or will that be the topic of a future blog post?

For now, what I’ll say is that I’ve seen how Node never really got a rails, and how Rust has a zillion microframeworks but no Rails either, yet. Do we need one? What would it look like? That kind of thing.

> Node never really got a rails

I'm, admittedly, out of the loop when it comes to Node, but I do remember Sails looking promising when it was first announced. I recently suggested it to someone (who uses Node regularly) as a possible solution for a project we're working on and they'd never heard of it. So, between that reaction and the fact that I haven't heard of anyone else using it (or anything similar), I think you're right that a Railsy solution never took off.

Elixir is an interesting counterpoint, though. It seems like Phoenix was released and saw broad adoption very early on.

I'm wondering if this dichotomy is a result of where people are coming to these newer languages from: people writing Elixir probably aren't coming from the FE/JS world, but there's a very good chance people writing Node are. Prior to the somewhat recent proliferation of JS client app frameworks, using a smattering of libraries was a very common approach to solving problems. (It arguably still is, albeit at a different level of abstraction in React/Babel/Webpack land.)

Anyways, I'll be looking forward to reading the post you alluded to above, should it ever come together.

I really don't care for Rails' components. But I think you are right when you talk about this -- monolithic frameworks allow you to get all these decisions out of the way and simply get on with developing your project. How much benefit are you really getting out of spending the time comparison shopping a bunch of serialization libraries instead of just picking on and moving on? Unless serialization is somehow a core part of what your application does, the benefit is probably quite marginal.

The big value that Rails adds is that it eliminates valueless choices. Most of the time, which logging library, ORM, view templating language, whatever doesn't really make all that much difference in terms of effectiveness and essentially come down to aesthetics.

When working with a framework that doesn't make those decisions for you, you end up with two big downsides - you waste time and energy arguing over which of these low-value choices you want to take, and new developers take longer to come up to speed with your particular architecture, since they need to learn each of the choices and how they are integrated, whereas in Rails it's obvious where everything is and how it's configured if you're familiar with the framework.

Bloat is also over-emphasized, particularly for the backend. You'll load the gems in memory, sure, but they're a fairly small footprint on their own and it's not like Rails is calling the parts of the framework it's not using (save maybe middleware, although most of that is useful for most web applications).

A big benefit of how opinionated frameworks preempt debates about marginal issues is that it's an externally imposed decision, instead of one team member triumphing over the others.

It really helps team cohesion for DHH to tell you that you're using X instead of Y as opposed to the most domineering devs getting their way every time. In my mind this even compensates for some suboptimal choices Rails may make.

> You want an ORM? choose an ORM library. You want templates, choose a templating library. You want to send mails, choose a mailing library.

But I'd rather spend my time creating business value than researching ORMs, templating libraries and mailers. And since I've never not been able to accomplish something with the ones Rails includes by default, I've never seen the need to use something else.

And guess what? Let's say you have that file parser that runs faster in Go? Send that call from Rails to Lambda and bam! you don't have to worry about infrastructure either!

If you're building a CRUD app (most are), then any popular MVC (Rails/Django/Laravel/.NET MVC/etc) will likely do. If you're worried about "Twitter/Facebook/Google scale" when you're starting, then you're doing it wrong.

I'm surprised to hear that a person can efficiently create business value without knowing the ecosystem of the language they are using. Without a knowledge of what exists outside Rails, how do you know you're not wasting time and effort? (Not to ask how you're going to get your next job.)

> Without a knowledge of what exists outside Rails, how do you know you're not wasting time and effort? (Not to ask how you're going to get your next job.)

So now you need to factor in research time. Then, continual research time, every time a new library or version of a library comes out. And if your research turns up that, no, in fact, version X or new lib Y is not substantively better (by whatever metric you're looking at), do you count that research time as 'wasted'?

> how do you know you're not wasting time and effort?

You look at the results of what you're doing vs what expectations were, firstly. You can then, periodically, look at your efforts, and compare reports from others who are claiming to do the same thing, and ... occasionally... spend time determining if a different approach offers radically better returns on the effort/results you have now. Switching to XYZ may also involve huge amounts of refactoring, upgrade, migration, etc. How do you know all that effort won't be "wasted" if new platform XYZ is abandoned 18 months from now?

"efficiently" doesn't necessarily mean "at maximum efficiency". Also, "business value" is almost always intertwined with hitting particular date/time goals, which often trump technical metrics.

Rails ain’t exactly new. It works pretty well for most things. I think most Rails developers generally stay abreast of large developments in the ecosystem, but the days where you would see significant benefits from being aware of every little library that comes out are long gone.

Yes, I agree that knowledge of the ecosystem is important to efficiently create business value. If I don't know that Devise exists and I roll my own auth library, that's a waste of time.

That's different than if I don't know that Sequel exists and I blindly use ActiveRecord. They're both ORMs. They can both read and write data from a database. And guess what — ActiveRecord is better for the vast majority of situations and everyone in the Rails community knows it, so my research into Sequel would have been time wasted.

Rails helps you avoid wasting time on this kind of stuff and pre-packages stuff that most everyone needs and where the alternatives are not substantively different.

The improvement comes from someone else making all of those decision for you and as long as you completely ignore your design requirements and force your problems into the framework's mold then you're golden! You never actually need to think!

You also get a uniformity of understanding of your library and a support network.

Rails is tailored to a particular type of web application, and if your application strays far from this model it's probably not going to be a great fit. I don't think even the biggest Rails zealot would advocate building Google Maps in Rails.

The sweet spot that Rails covers, however, is a pretty common sort of web application - one in which you're primarily doing CRUD on different sorts of objects. If you treat every single application as a unique snowflake that needs a 100% bespoke collection of libraries to solve, you'll end up wasting a whole lot of time on architecture and library selection and not a lot of time on solving actual problems.

> I don't think even the biggest Rails zealot would advocate building Google Maps in Rails.

Rails excels at being the web layer in this situation. All the heavy lifting is done by the DB to spit back feature structures or do routing and native libraries to do image composition.

And indeed, openstreetmap.org is a Rails site (though key parts of the API have been rewritten in C++ for performance).

The world is filled with other people. IMO, the benefit you get from another person being able to immediately be productive in your codebase vastly outweighs any benefit you would get from hand picking an ORM, a mailer, a templating library, etc.

And, anyway, Rails is pretty modular; you can rip out and replace anything that isn’t to your taste.

Choosing is much harder than it seems, and much more resource consumming. Then you have to integrate them. And of course test, maintain, document and update said integration.

All people I worked with that had your philosophy didn't so that last part, and it had important consequences for the whole project duration.

but in ruby rails dominates all of these components massively