When NOT to use a framework [closed]

Question

Today, one can find a framework for just about any language, to suit just about any project. Most modern frameworks are fairly robust (generally speaking), with hour upon hour of testing, peer reviewed code, and great extensibility.

However, I think there is a downside to ANY framework in that programmers, as a community, may become so reliant upon their chosen frameworks that they no longer understand the underlying workings, or in the case of newer programmers, never learn the underlying workings to begin with. It is easy to become specialized to a degree that you are no longer a 'PHP programmer' (for example), but a "Drupal programmer", to the exclusion of anything else.

Who cares, right? We have the framework! We don't need to know how to "do it by hand"! Right?

The result of this loss of basic skills (sometimes to the extent that programmers who don't use frameworks are viewed as "outdated") is that it becomes common practice to use a framework where it is not required or appropriate. The features the framework facilitates wind up confused with what the base language is capable of. Developers start using frameworks to accomplish even the most basic of tasks, so that what once was considered a rudimentary process now involves large libraries with their own quirks, bugs, and dependencies. What was once accomplished in 20 lines is now accomplished by including a 20,000 line framework AND writing 20 lines to use the framework.

Conversely, one does not want to reinvent the wheel. If I'm writing code to accomplish some basic, common little task, I might feel like I am wasting my time when I know that framework XYZ offers all the features I am after, and a whole lot more. The "whole lot more" part still has me worried, but it doesn't seem that many even consider it anymore.

There has to be a good metric to determine when it is appropriate to use a framework. What do you consider the threshold to be, how do you decide when to use a framework, or, when not.

Answer 1

"There has to be a good metric to determine when it is appropriate to use a framework."

Not really. If there were good metrics for determining appropriate use of any technology, you wouldn't see language, editor, and methodology holy wars.

The groups I've worked with all do the same thing - make a guess at costs and benefits, choose the most productive route, and hope they're right. It's not terribly scientific - one part intuition, three parts experience, one part susceptibility to marketing, one part cunning, and five parts rank opinion.

Answer 2

Frameworks are just tools. I don't think it's a framework's fault if it is overused, rather that of the person overusing it. The old saying "if you have a hammer, everything looks like a nail" shows this way of thinking has been existing long before even computers.

Becoming too specialized can indeed turn into a problem in the long term - for a developer as well as for biological species. For long term survival, one has to carefully balance the effort to develop his/her skills in multiple areas.

To answer your specific question, I don't think there is a metric for this. I prefer using a framework when it simplifies problem solving. If using a framework helps me solve a problem with 2 lines of code instead of 20, I will obviously use it. But even if its 20 lines against 20, I might decide to use a framework if it gives me better abstractions, closer to the problem domain, making the code easier to understand and maintain.

Answer 3

I think that frameworks may be overused in some contexts, yes. A framework is just a tool, yes. A framework allows you to get something running very quickly, and as such is an excellent prototyping tool.

Somewhere along the line, when your application reaches some level of complexity, the restrictions inherent in a framework begin to stifle further growth, it seems to me. The trick is to recognize when you have encountered such a tipping point, and then to decide what you are going to do about it.

Answer 4

I tend to work most with web applications and even though I'm trying to be general, my answer might not apply to your area of programming.

I am also going to use "framework" synonymical with "library".

---

Before implementing a framework, one must consider a few things, here are a few general examples.

#1. Will the framework save time and effort?

The answer to this question is almost always yes. Frameworks tend to be built to solve specific problems, and solve them very well. For instance, frameworks such as EntityFramework can save you entirely from writing SQL-code. Which can be fantastic if your programming team is not fluent in SQL.

Frameworks are built to either, a) add a programmer-friendly interface to otherwise complex components or b) add abstraction to already well known (or established) components.

The latter (or even the former in some cases) can actually get in the way of development. This applies especially when you or your programming team is going to implement a new framework, in which they have never worked before.

This could potentially slow down your development process, which could potentially be costly.

#2 The scale of your application

It is said that "anything worth doing is worth overdoing", but usually that's not the case. There's probably no good reason to implement a super-sized framework if the point of your application is to print "potato".

When you are developing a application (be it web, desktop, mobile or any other conceivable type of application) — if you feel that the size of your framework "dwarves" your (maybe future) implementation of it, then this might be a big warning sign that your framework might just bloating your application. A good anecdote would be if you included jQuery, just to add a "loaded"-class to your body-tag when the document is ready. Doing that with just native JavaScript might be a tiny bit harder, but it doesn't bloat your application.

On the other hand if a framework does a lot of dirty work on the inside (i.e. database frameworks), then it might be viable to implement it, even if you only are "partially" using the framework. A good anecdote would be to not try to build your own ADO.NET or MongoDB-driver, just because you don't need to utilize the entire library.

Sometimes frameworks come open-source (and with 'do-whatever-you-want'-licenses). This opens up a new possibility where a programming team might only opt for parts of a framework.

This ultimately ties back to question #1 and #3.

#3 Impact.

Sometimes implementing a framework can directly impact the end user. This is especially true for web applications, since having big client-side frameworks might negatively affect the end-user's experience. Users with slower machines might experience slow rendering, performance issues with javascript or similar issues caused by sub-par machines. User with slow connections might experience slow (at least initial) loading times.

Even in other types applications, end-users might be negatively impacted by your application-dependencies. Frameworks at least always take up some disk space, and if you are developing a mobile app (or even a desktop app) this might be needed to be taken into consideration.

Server-side frameworks (even more web-specific) will most likely not affect your end-users, but it will affect your infrastructure. Some frameworks have dependencies themselves which might require you to restart your web server, either just the service or the server entirely.

Some frameworks might also be very resource-heavy.

This of course ties back to point #1 and #2.

---

It's all just a big "circle of considerations", and there is no real scientific method for deciding whether you should implement a framework or not.

Corbin March summarized it very well:

The groups I've worked with all do the same thing - make a guess at costs and benefits, choose the most productive route, and hope they're right. It's not terribly scientific - one part intuition, three parts experience, one part susceptibility to marketing, one part cunning, and five parts rank opinion.

It's also important not to be elitist. Frameworks are tools which are meant to be used. I know people of both extremes; on the one side you have the guy making life very hard for himself, on the other side you have the guy who builds slow, bloated applications.

All frameworks have use-cases, it's just a matter of implementing them for the right purposes.

Answer 5

Do the other developers know the framework?

If all developers know framework X, then given all other reasons for using the framework are viable, go for it! To me, it doesn't make any sense to enforce learning a specific framework when the majority of the development time will be spent learning the intricacies of the framework.

Regarding your statement on newer programmers not knowing the basics, you're a lot more compassionate than I am! Yes, it's a shame, but am I going to spend my time worrying about someone else's ineptitude? Nup. (Based on the assumption that these new members of the community aren't immediately working with you.)

Answer 6

I would use a framework if (and ONLY if) the following conditions hold true:

The framework seems likely to be supported for some time. I've had them go end-of-life on me before, and it's REALLY annoying. Especially when you're 9 months into your project, and switching isn't really an option anymore. And if the framework is ALREADY no longer supported, then think three times before you write something new using that framework. No matter how well you already know it.

The project actually matches the framework. As a pretty old example, have you seen the things that MFC was made to do? People did no end of strange things to make it work for types of apps where it just didn't make sense. Usually spending more time beating up on MFC than they would have spent just writing the app they wanted straight up.

The project team is capable of working within the framework. Some people don't or can't take the time to understand how an app should be written in a given framework, and instead they write things the way they usually do, instead of the way that the framework needs. This mis-match between code and framework usually ends up costing everyone lots of time and effort.