Is it better to use frameworks with strict structural requirements?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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!