I'm not quite sure how to best name this, or even precisely what it is that I'm asking here because it's kinda vague and intuitive, but... I hope my explanation will make sense.
Over my years of programming carreer I've had the honor of working with many different frameworks. Some were homebrew, others were in public domain or even a paid product. And I've noticed a pattern: most frameworks deal excellently with the naive, basic use cases. The kind of things you write in simple examples (and, completely coincidentally I'm sure, also the documentation of said frameworks). They also deal moderately well with average real life use cases. But when you hit on something that lies off the beaten path, something that the core devs hadn't anticpated, all hell breaks loose. Suddenly you spend days if not weeks trying to figure out how to do what you need to do; delve through undocumented and/or reverse-engineered bowels, only to end up with an ugly hack that you hope nobody ever finds out about and which may or may not stop working with the next major release of the framework. It feels like a wrestling match, and I've been on this rodeo far more times than I would like.
As a result I've gained a dislike for large, all-encompassing frameworks that dictate Their Way in every little aspect of your program. Instead I prefer to put my programs together myself, using many unrelated external libraries which each focus narrowly on their own task, but do not put any limitations on how you use them - or if you use them at all. This gives me a lot more degrees of freedom and ugly hacks are rarely needed
However recently I've heard from several colleagues in unrelated conversations that they actually feel exactly opposite. They prefer the megaframeworks precisley because they enforce their structure and order upon your program, rather than allowing you to go whichever way you want. And I also do see the point in that. If you're a new developer to the project but you already know the framework, you'll have an easier time getting your bearings. Similarly, there will be an implicit agreement among all developers of a project about what goes where and how things are done. In contrast, the frameworkless programs do tend to get somewhat more messy when there are multiple people working on them, because each person does things their own way.
This discussion came up again recently about a fairly new project we're working on. I've started it in the "frameworkless" way, but a colleague feels that it would be better to move over to a certain large framework instead.
I'm quite confused and don't really know which would be objectively better. Should we rewrite the program in the large framework and stick to it, warts and all? And then say "no" when a requirement comes in that cannot be reasonably accomplished due to the limitations of said framework? Or should we stick with the hodgepodge of unrelated libraries and perhaps start writing our own "style and structur guide" to ensure code uniformity?
And then say "no" when a requirement comes in that cannot be reasonably accomplished due to the limitations of said framework?
-- In what universe would that be a valid option?