[mattgreenrocks]

The paradox of frameworks: if you couldn’t write it yourself, then using it is a big risk if you hit a bug. But if you could write it yourself, you may not want to, as you have a better idea of what you want.

Personally, I only like frameworks that don’t fight me tooth and nail to encapsulate them into adapter layers (hexagonal architecture) when the time comes. There aren’t many of them. Some of them feel almost narcissistic in how much they want to assert themselves within your code.

The domain model is the most important thing. The framework is a detail that is not important.

Edit: forgot to mention, there’s a whole other argument here about how frameworks are not architectures. I suspect this is a big draw for many teams. But a commoditized architecture won’t serve you well over the long term.

[mtberatwork]

If you hit a bug with a popular, open-source framework, the odds are great that others have as well and it will get escalated and solved quickly. The same can't be said for closed-source, proprietary frameworks. Also, writing it entirely yourself always leads to re-inventing the wheel over and over again. Furthermore, I have yet to see any proprietary framework that wasn't in some shape or form a poor knockoff of something already existing in the open-source world.

[wtetzner]

But you don’t write your own framework, you write a program. Not trying to make something too generic can keep things much simpler.