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?

  • 2
    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? Commented Jan 12, 2020 at 0:08
  • @RobertHarvey - EXACTLY!
    – Vilx-
    Commented Jan 12, 2020 at 1:29
  • "They prefer the megaframeworks precisley because they enforce their structure and order upon your program" - that's because they use them as a crutch and because it blinds them to the limits of their own design skills. Frameworks help you get started quickly, and that's OK - but if that project is going to live on and grow, then following The Way prescribed by the framework, and relying on the framework structure and conventions too much, couples you to the framework and its limitations - and to the whims of the framework authors. Commented Jan 12, 2020 at 17:48
  • @FilipMilovanović - This echoes my own sentiments, however there is also a good argument for their viewpoint, beyond it being a crutch. When there are multiple developers working on a single project, they need some common guidance, otherwise the project becomes a hodgepodge of different development mentalities. I've seen this happen too, and on my own "unopinionated" projects no less. And it's not that someone is stupid, but simply each person prefers their own way. A common framework is actually helpful in this case, to synchronize people.
    – Vilx-
    Commented Jan 12, 2020 at 17:53
  • BTW, you can say "no", or rather, discuss with the end users the utility of the requirement, the cost of implementing it, and negotiate it - sometimes requirements come in, and they aren't really well thought out, or seem like a "cool new feature" but do not provide much value to the end users, but are potentially a pain to implement (i.e., they are "costly"). Perfectly fine to rethink them or reject them - that's why you have things like iterations/sprints and backlog grooming. Commented Jan 12, 2020 at 17:53

4 Answers 4


I'm quite confused and don't really know which would be objectively better

That's because there is no "objectively better." "Better" depends on what your goals are. If your goals are to use an opinionated framework because it forces order and structure onto your code, that's what you do. If your goal is to re-invent everything yourself, but have precise control over every aspect of your code, and you have the time, energy and discipline to do that, then that's what you do.

I believe that your goal should be to hit a sweet spot of about 80 to 90 percent with your framework, and write the remaining 10 to 20 percent using custom code. Frameworks that won't allow this should be summarily discarded. There will always be a need for custom code.

As an example, Vue is a framework in which you can start out right away, very simply, with a sensible architecture and a single page. But Vue can also grow with you as your needs grow and your applications become more complex. Contrast that with Angular, which has a substantial learning curve, requires quite a bit of up-front knowledge to use effectively, and binds you to its architectural decisions from the start.

But neither one is better than the other. You choose the one that is the best fit for your specific needs.

Frameworks sometimes represent many person-years of effort, effort that you shouldn't repeat if you don't have to. Recently, I started a project that uses a Material Design library. That library probably has 2000 hours of programming labor invested into it, if not more. Had the library not existed, we probably would have just done without.

  • 1
    No, no, I don't mean reinventing wheels. When a library exists that does what you need - by all means, use it!
    – Vilx-
    Commented Jan 12, 2020 at 1:31

I know exactly what you mean and have experienced it myself. And even though 5-10 years ago I loved learning and using frameworks, I have ended up preferring the "frameworkless" approach (or at least sticking to "frameworks" that are not opinionated about structure).

The reason is, as you mentioned, the struggle to meet requirements. Unless I have extensive experience with a framework, I'm not aware of all the capabilities and limitations it has. Which means there's a good chance that some seemingly innocent requirement will eventually be revealed to be completely against the way the chosen framework operates. To make matters worse, this might be a teeny tiny requirement that is added way after significant work has been invested using the current framework.

Given those risks, I think the reasons people might still use opinionated frameworks are:

  • Because they are not aware of alternatives (e.g. libraries or less opinionated frameworks).
  • Because alternatives may be deemed not a good fit for other reasons (e.g. lack of extensive documentation).
  • Because going with a popular option is easier to hire people for.
  • Because frameworks take care of composing things -- and in some languages (e.g. object-oriented C-family languages) composing code can be a bit of a pain, so people happily delegate it even if they lose some control.

I don't see an objectively better option. But if you are not bound by the constraints I mentioned above, then I think you're making a good decision not choosing an opinionated framework.


You need to think in cost/value.

If a framework allows you to keep the development cost low most of the time and sometimes you'll have to hack things and have high development cost for some features it may be better than having moderately high development cost all the time due to having to develop things yourself.

Being able to introduce features quickly is good for a business. For features that take times you'll provide an estimate of the cost of development and the business will decide if it's worth it or not.

Developing is always about trade off, the choice of a framework too.

  • True, true. Although estimating said cost is rarely easy.
    – Vilx-
    Commented Jan 13, 2020 at 14:41

In a lot of instances, if a company just wrote their own code from the beginning, the need for a third party framework isn't needed because the company will have their own. Some will talk about the hours invested into outside frameworks and their testing but you and your company will invest in yourselves by creating your own.

Too many times people use frameworks out of need for something right now or just plain laziness. I understand the "right now" problem (and it is a problem) but much of the code needed to write your own software has probably already been written by your experienced software engineers. That's what your company paid for. And the bonus is you have the sources and engineers who understand how it all works together!

  • Or, if people get shuffled around a lot and there's no Glorious Leader to hold the steering wheel, you just end up with a hodgepodge.
    – Vilx-
    Commented Jan 13, 2020 at 14:39
  • @Vilx- That's what documentation is for. Just like frameworks can also lose significant personnel, it is the documentation that can hold things together. Even then, frameworks can fall apart or not keep up. Linux and the BSDs are--in a way--frameworks but they gain and lose people all the time.
    – Rob
    Commented Jan 13, 2020 at 19:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.