[adamkl]

Agree. There is a lot of value in the "easy, batteries included" solution which is why Rails gets so much love from the start-up community. The problem always seems to be that the same things that makes Rails easy to get started with (cough ActiveRecord cough) also make it easy to create foot-guns in the future (provided your start-up lasts long enough to get to that point).

Combining a Rails like framework that makes things easy with a language who's idioms prioritize simplicity seems like a great combination.

[dimitrios1]

I am going to butcher this, but my sense is this counter culture against the big heavy opinionated frameworks arose from that generation of programmers who in a sense "grew up" (career wise) on things like Rails. Like others have said, there eventually comes a time where you are fighting the framework more than the framework is providing value, and having learned the value of the abstractions and functionality through multiple applications, they then became able to pick and choose a finer subset for a particular problem or domain.

The best of both worlds, in my opinion, is a loosely coupled set of opinionated tools and libraries, but that also has a tool that provides a unifying interface into the "golden path" for using those together to provide some functionality.

[dgb23]

> The best of both worlds, in my opinion, is a loosely coupled set of opinionated tools and libraries, but that also has a tool that provides a unifying interface into the "golden path" for using those together to provide some functionality.

This is almost it. A few more things I think one wants:

- Do most of the coupling and plumbing yourself, IoC is evil when applied to things that do too much.

- Control the application state - see above.

- Be free to substitute any major part, be able to compose them freely.

- Re-use and extracting libraries from past work to be convenient, robust and affect past / maintenance-mode projects positively too.

- Be able to defer extracting libraries and generalizing up to the time you actually need to.

- Decouple code organization from artifact deployment.

- Be absolutely free in how you design and write domain logic and information processing - this is the brain of an application.

- Be absolutely free in how you design and write the UI - this is the body of an application.

- Have the tooling/utilities around code that fit your workflows and business needs.

I've come to the conclusion that full-stack frameworks in the style of Rails/Laravel/Django get in the way of some of the above and don't provide enough to make the above possible by themselves. I think the answer is not "use this framework" or even "build this framework".

It starts with your business/domain needs and builds from there - custom and simple. It builds up slowly and steadily like a garden that reflects your team's personality. It takes a careful, comprehensive, holistic approach. There are angles from version control, to project management to deployment that are all incorporated.

[adamkl]

Sounds like “create-react-app”. A bunch of libraries and configurations wrapped up in a “golden-path”.

Provides the “easy” for 95% of usecases and an “eject” button that unwraps everything and puts it under you control for the last 5%.

[dimitrios1]

Create react app was one example I had in mind, I think Redwoodjs is another one that recently popped up.

[ravi-delia]

> Combining a Rails like framework that makes things easy with a language who's idioms prioritize simplicity seems like a great combination.

I think that's what makes Phoenix and Elixir so nice to use. The primitives Phoenix uses aren't too far from the surface, and the default setup is fairly batteries included without ruling out future growth.

[slowmovintarget]

To quote Rich Hickey: "gem install hairball"

[adamkl]

I like that quote, but it's the Rails idioms and conventions that make hairballs, not the fact that it includes a bunch of batteries.

[capableweb]

Adopting any framework is quite literally adopting the framework's idioms and conventions so not sure how that is different.

[adamkl]

It was a general comment about frameworks. It’s possible to have a framework that includes all the “batteries” but has idioms and conventions that promote simplicity and maintenance.

Rails chose idioms and conventions that prioritize speed at the cost of complexity. The “included batteries” are not the problem.