[berkes]

Ask yourself: Are you building a Rails, Django, Spring app, or are you building a coffee-comparison-app, a facebook-for-dogs or a inventory-management-system (or anything, really).

This alone implies that what matters is your domain. Not the framework. This is also an important point that many seniors in the industry keep repeating. Eric Evans wrote a giant book about it (DDD), Robert Martin named his company after it (and keeps bringing it up on any conference). Dave Farley keeps repeating it in his youtube channel and his books. And so on.

My take is that development speed does not come from quick scaffolding like `rails generate CreditCard` but from having a clean, well-maintainable, loosely coupled, well-tested CreditCard Service or Aggregate, or DomainBoundary or whatever. Rapid time to market is not achieved with `curl fancyframe.work/in.sh | sudo bash` or `pip install django`. Rapid time to market is achieved with an architecture that allows easy rewrites, fast pivots and rapid swapping of dependencies.

Frameworks often hamper such loosely coupling. They get in the way, in the long run. Sure, chances are >50% that what you are building now fill be replaced or have failed within years. But for the off-chance of having something that you'll be maintaining over years, decades even, be sure you have something that does not get in the way. Edit: and on that timescale, the time-wins that the framework initially gave you, are often neglecatable anyway.

> So my strategy is to keep frameworks like Spring, Hibernate, and Rails at arm’s length; behind architectural boundaries. I get most of the benefit from them that way; and I can take ruthless advantage of them.

>

> But I don’t let those frameworks get too close. I surrender none of my autonomy to them. I don’t allow the tendrils of their code to intermingle with the high level policy of my systems. They can touch my peripheral subsystems; but I keep them away from the core business logic. The high level policies of my systems shall never be touched by frameworks. - Robert C Martin https://blog.cleancoder.com/uncle-bob/2014/05/11/FrameworkBo...

[mattgreenrocks]

The discourse around how to build software is just terrible in general. This is sound advice and yet it's seen in many circles as tilting at windmills. Meanwhile, devs are happy to write off days/weeks with the makework of upgrading their apps to stay up-to-date with frameworks. Productivity is confused with a feeling of power.

I suspect some people value frameworks more highly because they perceive them as coming bundled with a community (e.g. support). This consideration outweighs the architectural damage done in their minds. I'm not disparaging this. But as devs mature and age, they gain confidence, and eventually realize that every project doesn't need to automatically start out with a framework.