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...
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.
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.
That’s not always perfect or suitable for every use case, but it’s not a bad thing.