To use a framework or not?

Posted on March 6, 2012


In some cases I am a very fierce opponent of frameworks. Especially when these frameworks do not solve a real problem. Below I give a short reason why.

Structure versus re-usable software libraries

To keep things simple I will divide frameworks into two types:

  1. Structural frameworks: advocating a specific way of working. PureMVC is one of them. Swiz and Spring are two others.
  2. Software libraries: solving a specific problem in such a way that you can re-use it in other projects, saving time in the process. BlazeDS is such a framework, as is Flex and 3D libraries like PaperVision and Away3D.

The magical glow: the main assumptions associated to structural frameworks

Structural Frameworks carry a magical glow around them of solving some structural issues with the maintainability of the code itself.

The main assumption with Structural Frameworks is that “because they force a specific way of working, the project is easier to maintain”. The naive assumption with Structural Frameworks seems to be that:

  1. Standards: Everyone who uses that framework automatically uses the same approaches and implementations.
  2. Maintainability and understandability: Because “everyone uses the same framework and thus uses the same approach” anyone who will take over a project will be able to understand what was done where by their predecessors.

What is wrong with these assumptions?

There are several things wrong with these assumptions on structural frameworks:

  1. Crappy programmers remain crappy programmers, producing messy code – Introducing a Structural Framework will not create better programmers or better code. (Education does and will, but I will come back on that later.) Crappy programmers simply will try and enforce the same crappy patterns they have always been using on the new framework, creating an even bigger mess than they would have without that Structural Framework.
  2. Good code is created by refactoring, structure and strategic thinking – You do not need a Structural Framework to create good code. Instead, start by reading two essential books: “Clean Code” and “Refactoring” and apply the principles relentlessly in everything you do.
  3. Each and every framework is hampered by the original scope – A framework starts as a local solution in one or more projects. Repeating patterns and specific coding principles are abstracted, cleaned up and made re-usable for other projects. These projects and the people creating the frameworks have a very specific scope and a very specific way of thinking. These principles and that scope will work awesomely for any project that is similar, but will fail greatly for any other project.
  4. Each Structural Framework has a learning curve – To understand a Structural Framework, you have to understand the ideas behind them. Inversion of Control and Dependency Injection? First learn what Inversion of Control and Dependency Injection beholds. MVC? First learn what the MVC Pattern is and is not. Applied Design Patterns (like the Facade and Proxy in PureMVC)?
  5. Each Structural Framework has a limited life span – Because it is popular now, does not mean it will be used five years from now. Most frameworks reach an “end of life” in five years. Simply because new insights and newer frameworks arise and programming languages continue to evolve, incorporating specific principles and providing better solutions based on more recent insights.
  6. Structural Frameworks can be worse than legacy code and legacy languages – Worse than the switch of (in the case of Flash) ActionScript 2 to ActionScript 3 is the additional layer of abstraction that is bound to one specific implementation of a specific set of design patterns (your Behavioral Framework). As your code is wired according to a specific Framework with a specific use of a specific (limited) set of Design Patterns, finding out what the fuck is going on where, is not only being forced to understand which Design Patterns and Design Principles are used, but also how they are applied in that Framework.

Re-usable software libraries

Re-usable software libraries have a simpler premise. They handle specific processes in specific ways. Like Structural Frameworks, they have a limited life-span due to progressive development.

Like Structural Frameworks, Software Libraries will – at a certain point – be obsolete and replaced by other and newer versions.

Unlike Structural Frameworks, Software Libraries do not have this magical glow around them of solving all your problems of maintainability. In most cases, a Software Library is used for practical reasons, to solve practical issues.

Some examples of Software Libraries are listed below:

  1. Connecting to a data-source: Like databases, web services, files and file systems.
  2. Building user interfaces: using a specific structure and approach, like the Flex MXML language and HTML or GUI components created for specific uses.
  3. Converting something from A to B (and back): For instance: bitmaps to JPG and PNG, SVG to vector drawings in Flash, and so on.
  4. Adding missing functionalities: like Zipping and Unzipping data, conversions from bitmap-data to JPG and PNG, generating PDF documents from content within flahs, and so on.
  5. Rendering specific things: like GUI elements, 3D objects, maps.

Some libraries dictate how your project will be built. For instance: when they generate your GUI via specific rules and formats. Replacing these libraries means that you will have to redo your project. Some use a specific approach to do their work, for instance: using Dependency Injection to handle specific processes.

Still, in most cases, you decide how you build your code and how this code will work with other elements in your application.

Drawbacks from libraries

Especially where they help you build entire applications, Libraries can have serious repercussions when functionalties and interactions you need to implement are not supported by that framework. This risk is biggest with libraries that render things people need to interact with. Simple things like show and hide elements based on specific parameters and business rules can already lead to complications.

And what if a library is not finished yet? Contains nasty bugs? Or does not support your specific needs?

Do it yourself? Costs and benefits

In some cases, the best solution is to build something yourself. Consider these factors:

  1. Existing libraries and frameworks do not suffice: You tested and tried several solutions and neither suffice as your needs exceed what each of these frameworks can offer.
  2. Adapting an existing framework only complicates things: You find that your workarounds are becoming a project on their own
  3. You can do it better and simpler: Whatever is provided simply is too complicated and elaborate for your needs.
  4. You only use a minor part of the existing framework: Where you might have started optimistically, you end up using only two or three minor elements of that framework.
  5. The existing library/framework adds too much weight for what it does: The library adds a significant amount of kilobytes to your compiled code and really only deals with something minor.
  6. Nobody in your project, including you, knows how to use the existing framework (and it does not really solves a problem): When you use an existing library or framework nobody knows or understand, you introduce a risk of failure in the project.

In each of these cases, the costs might be much more than the benefits.

When you want to build something yourself, consider the following:

  1. Can you build something better in the same time? – Each framework has a learning curve. If you can build an alternative solution in the same time it takes to understand something you do not feel good about, do it. Sometimes your own solutions are better for your own needs and sometimes what you need is not mainstream this year,
  2. How ambitious is your self-made framework? – If it is very ambitious and solves a problem already covered by existing frameworks, you might want to reconsider, unless you already have tried the alternatives and they sucked in your opinion for your specific needs.
  3. Does it make sense? – In some (and sometimes even most) cases, a specific framework is considered to be “the standard”. Even if you think your specific solution is better, the project, politics and other factors dictate something you might not have chosen to begin with. Anything else you will introduce will basically hamper the process and be ejected and rejected somewhere along the line.


As stated, I am not a fan of Structural Frameworks. I find that the offered solutions sometimes are worse than the problem: forcing you in one specific direction and one specific set of Patterns. Until now, a proper use of Design Patterns and Design Principles has been priven much more effective in my work than any Structural Framework.

An additional factor in my – let’s call it “hesitation” – is the aforementioned relatively short lifespan of any framework. What is hot tomorrow is old news two years from now.

On the other hand, some, if not most principles used in Structural Frameworks can be very educational and beneficial for your own growth as a programmer. Understanding Inversion of Control and Dependency Injection, MVC and other patterns and principles can boost your own effectivity and quality of coding.

But one thing you can not sell to me. It is what I call “the magical glow” of Structural Patterns. Rainbow pony magic-land storytales. Using Structural Patterns will not improve the quality of your code, nor will it make your project easier to maintain in the future. It might force you to work better and use Patterns more consciously. But that is something you should be doing already anyway.

The only things that do improve your code and make your projects easier to maintain are: education, knowledge, experience, deliberate and focused sessions of refactoring, clear project structures and clean code principles.

Building your own Code Libraries is something that will happen when you start building with a wider vision than just this one project. Whatever you do can be re-used and improved and if you do it well, each next project benefits from the one before. When you centralize all your smart solutions, your own Code Library with all kinds of smart tricks will automatically come into existence.

Using the Libraries from others has several benefits and pitfalls. One is that you can save time by using the work already done by others. The other is that – when you do not test these Libraries for your specific needs – they can get you stuck on critical moments in your projects. Even leading to complete redesign of your code because you had to extract all coding you did for one framework, to be able to implement another.

Posted in: FrameWork