Frameworks: More Crux Than Cure

Notice: The goal of this post is not to bash specific frameworks1, except “Apache Wicket” (that thing is awful). The author’s intent is to point out how developers are becoming more and more reliant on frameworks, which is limiting growth and understanding of what is happening behind the scenes. In addition to curbing developer growth, some frameworks can eventually become a hindrance when custom functionality is needed.

The newest framework came out; it is so simple to get that “Hello World” example running. Only twelve lines of code and its working! Awesome, except your production application is slightly more complicated than “Hello World”. Now, what? Well, you might be thinking to yourself, “Obviously, there is a learning curve for frameworks”. I understand that (also don’t worry I can’t read minds), but my response would be, I think time spent learning frameworks would be better suited for understanding the problem and trying to solve it within your specific application

I understand why people love frameworks. They eliminate trivial code while allowing for rapid initial development. I also know that understanding how things work from the ground up is a much more powerful tool than plopping a framework down and trusting it will work for your application.

Frameworks Don’t Make the Dream Work

Developing towards a framework is an easy way to limit your usefulness in the technological world. If you do not feel like writing boilerplate code for a certain aspect of your application, perhaps consider using a library. Libraries can be used to help support an application without steering the way a developer writes code and can be swapped for something newer if its usefulness diminishes.

Okay, okay, so you (and your team) are smitten with a set of features a certain geometrical framework offers or maybe you love how simple starting an application is with a resilient metallic coil startup framework (not proud of that thinly veiled reference). A few weeks go by and so far, so good, until its decided you need a new security measure implemented. No big deal, you can just add a hook that will perform the secure operation. Hmm, looks like the framework wraps the interaction you need to customize and there is no entry point for extending functionality.

So now that you’re yelling at me, because I just created a trivial example to support my argument. Well, let’s try an alternative approach. You successfully added application specific code that adds functionality, piggybacking on the framework you chose. Cut to two months later, you hire a developer and they need to upgrade said security feature. First, they must learn the framework. Next, they will learn your application. Finally, they come to the specific fix you wrote that fits with your framework. Now, that’s a lot less trivial example in my experience.

Frameworks, Frameworks, Frameworks2

In the humblest of ways, I am willing to admit there are frameworks that do provide value. They are minimalistic in their approach and provide simple avenues for customization. The problem with frameworks starts when they try to tackle too much, handling more than they set out to do and quickly losing sight of the goal they were trying to tackle in the first place. I think trying to find which ones are suitable and which ones are disasters waiting to happen is an extremely difficult task. Hence, why I always advise heeding caution before fully committing to a framework, sometimes vanilla is better (honestly, vanilla ice cream is underrated).

I will close with two points:

1. I think developers should learn to write application code, not framework code, and
2. Beware of committing to a framework too early.

1Flame suit engaged

2Blame SEO