Is an application framework an anti-pattern?

Question

I've recently implemented a couple of similar-sized web applications, one of which used a "framework" and one of which I coded myself but used a set of existing (mostly open source) libraries to provide certain common functionality that I would otherwise have used a framework for.

I noticed the following:

• The framework-based app was certainly quicker to set up - it effectively worked "out of the box". However over time, and as more functionality was added, it started to become increasingly complex to maintain. As soon as I needed something that didn't "fit" the framework then I found myself forced to resort to some ugly workarounds.
• The library-based app required more code at the start to bring in and integrate the necessary libraries, i.e. it was necessary to write a reasonable amount of glue code at the beginning. But it turned out easier to extend and re-factor over time, because there weren't any constraints posed by the need to fit within the framework design.

From this personal experience I got the impression that the use of a framework might be considered an anti-pattern for long term application maintainability.

Is this really the case?

Answer 1

I think it's highly subjective. In my opinion application frameworks indeed are an anti-pattern, especially for larger, more complex projects. I think there are two reasons to it.

The biggest problem I see with frameworks is that by using a framework you give up control. JB Nizet writes "nobody forces you to use the framework for every part of the application", and that's great when it's the case, but unfortunately it usually isn't. Usually the framework has the control, you have your callbacks or derived classes, and when you want to do something extraordinary you can't.

This gets worse because, in general, it's very difficult to design a framework well. The worse the framework the more limiting it is and the more it gets on the way of the framework user. A lot of frameworks I've seen have some fundamental limitations that end up restricting the final application one way or the other. I wouldn't say only the framework creators are to blame, it's just a very difficult, if not impossible, task to try to create a framework that doesn't restrict the framework users.

Frameworks aren't all bad, though. If your project fits well to the framework and it won't grow beyond it, the framework does speed up the development. Small frameworks within an application tend to simplify things as well when they only take care of one problem domain, with usually no risk of getting too much in the way. But in the end frameworks, on one hand, add complexity you probably won't need, and on the other hand, couple the interface with the engine, restricting the framework users.

Answer 2

No, it's not the case. There are good frameworks and bad frameworks, and there are frameworks suited for the app you're developing and frameworks not suited for this app. You just have to pick the best tool for the job. Not anticipating the complexity of the application is not necessarily the framework's fault. It might be yours, because you just didn't choose the appropriate framework for the task.

Whatever the chosen framework is, nobody forces you to use it for each and every part of the application. If the framework eases the development of 90% of the app, and make it too complex for the 10% left, then just don't use the framework for these 10%.

Answer 3

I don't think the pattern/anti-pattern terminology is very useful - it says about as much as the adjectives "good" and "bad". But I do think that most frameworks have serious downsides.

First, let's define what a framework is:

• A framework provides callbacks or a similar mechanism that you can hook up to your own code. The majority of your own code runs within these callbacks.

If a framework was a person, it's motto might be "Don't call us, we'll call you."

By definition then, you're forced to write your code in a style that fits the framework, rather than in a style that fits the application. Unless these two styles align, there's already an obvious problem.

A framework may initially be designed with a specific problem in mind, and many frameworks are quite successful at solving that problem. However, once the initial problem has been solved, most frameworks tend to keep on growing, encompassing more and more functionality that is only vaguely related to the original problem.

It's not uncommon to see a web framework that can also do security, resize your images, provide inversion of control or interact with your database. The framework has lost its focus, and tries to be everything to everybody. It's now neither convenient nor efficient, and probably bug ridden and incomplete due to that lack of focus.

And then you're better off with a library that does one thing, and does it well.