Frameworks vs. Libraries

I got thinking about Rob Aston’s article Look ma, no frameworks and the viceral, zealous reactions it provoked. I suppose that the people defending frameworks have not had the same horrifying experiences with them as I have. [And I will be honest, those are really the only two non-Microsoft frameworks I have worked with. But if I had to chose between working with another “enterprise” framework and slamming nails in my ears, I would take the nails.]

Granted not all frameworks are as enterprisy as the two piles of cow feces I got to work with, and one should not paint a broad brush, but nonetheless I have to agree with Rob. Now maybe some of those people disagreeing have worked with really lean productive frameworks (assuming lean productive frameworks exist). On the other hand I suspect some of them are responsible for creating these monstrosities and feel the need to defend them. If you are one of those people, please leave your company name in the comments so I can make sure I never ever work there.

Things really got out of control when he went off on Angular. I still think that is one of the most hilarious pieces of tech writing I have ever read. It was like reading an Old Man Murray review. The reactions on the other hand were like reading creationist comments on an episode of SciShow.

But as I said, I got thinking about the argument. And I realized that the framework vs. library dispute is a bit of a rehash of inheritance over composition. Anyone who has used a giant framework, or pretty much any framework, will have to admit that you are deriving your application from it. In fact, frameworks often make heavy use of class-level inheritance. Take ASP.NET MVC for example, you cannot get started without first inheriting from System.Web.Mvc.Controller.

As with classes, I do not see why we would not all be in general agreement to favour composing our applications with libraries over inheriting from frameworks. All the same reasons hold true. Some of the problems with frameworks are:

1. They are very rigid and impose a certain way of doing things. If you go off the beaten path, you will be stung. (WCF I am looking at you)
2. They often abstract the wrong things or at the wrong times.
3. Lock in. Oh my, the lock in. They tend to be an all or nothing proposition. As someone who has tried to migrate functionality out/off of a framework I can attest to the fact that it is nearly impossible. To the point re-writing the application can take less time.
4. Further to #3 they can be a maintenance headache. Often functionality is buried in them, strewn across various layers.
5. There are times where doing things with the framework is more work than without (Hey WCF! You again.)

What it comes down to is that with composition of libraries, you are a puppeteer controlling an assortment of marionettes. You are free to move them as you please, decorate them, or cut their strings if you so choose. Conversely, frameworks are the puppeteers and you are the puppet. (I wonder if that is why the same framework advocates seem to be in love with Dependency Injection? They adore inverting control?)

Maybe I am jaded by my recent experiences but it seems to me there is a really strong tendency lately for people to reach for the most complicated solution first. The sudden rampant use of DI, repositories and service layers is burying tons of simple applications under a morass of abstraction and convolution. I am not sure what happened to KISS and YAGNI, but they seemed to have died somewhere along the way.

One thing I assume is true, the people writing these monstrosities must never stick around long enough to maintain them, or I am sure they would stop. Actually, come to think of it, what these people really need to do is maintain an app built with someone else’s custom framework. Then they would see the light.