A framework provides a mechanism to rapidly build certain types of applications. Frameworks exist for business software, web software, games and more. A toolset is a collection of simple and easy to use tools to help build software. How are these different and why does it matter?
A framework takes control. It controls the overall program flow and what it can do. You configure it or provide code for custom sections and it works. It’s intended to save time. They are built like most programs, at least how beginners program. Beginner programmers examine a problem and find common patterns. They build this then create sections that can be interchanged to handle the rest. This is normal and reflects a typical thought process.
A toolset is far simpler. Toolsets don’t take control, instead you use them however you want. They provide flexibility.
Between the two, which is the better approach? Frameworks ultimately fail for several good reasons. First, projects are never the same. Each project has their own set of requirements and they don’t always fit nicely inside of a framework. Inexperienced folk find something that mostly matches their requirements. They do the majority of their project easily but often get stuck on the rest. Sometimes the framework can be expanded to ensure a project will work. Framework developers add more features for this purpose. The framework becomes increasingly more complex. New developers have to learn this new framework before writing an application in it. This barrier to entry has to be balanced with any time savings. This is but one problem and not the most important.
Frameworks ultimately become overly complex as they age. As they grow more complex, it takes more work to program in them. They inevitably reach the point where it takes just as many lines of code to write an application in a framework as it would to write it in native code. This is the ultimate death blow for any framework because it no longer saves time. Additionally it runs far slower than native code because it has a large overhead.
The last problem with frameworks is that they eventually are abandoned by their creators. Imagine spending ten years developing an application only for your framework to be rendered useless. Many developers and companies fall into this trap.
So why do programmers use frameworks? Many reasons have been proposed but in reality it is because new programmers think that way. There are far too many unskilled programmers. Given time and effort, programmers transition to toolsets.
Skilled programmers examine problems differently. During planning they identify tools needed and start by building them. Tools eventually grow more complex then are used to create the final product. They build their tools atop other toolsets. Toolsets are quick to learn and use. They are simple and generally better debugged. They follow the natural flow of the technology rather than the arbitrary control of a framework. This gives the programmer more options when programming.
Despite all this, some programmers still insist on using frameworks. They claim that a framework ensures code is uniform and secure. They may feel that enforcing standards ensures code is better. Standards are commonly used and represent a framework for code. It has the same limits as all frameworks. Some frameworks handle things like security, but that only lasts until a programmer unintentionally makes a backdoor. If your programmers aren’t good enough to handle program security then you need better programmers. Code uniformity requires a bit more explanation.
Patterns exist in programs, such as MVC (Model View Controller), client-server and so on. Programmers naturally recognized these patterns and organized their code to fit within them. This is alright, but along the way they start forcing all code into these patterns. There will always be things that don’t fit into any pattern. Many programmers have a belief that following simple patterns makes code better. Unfortunately that is not the case. A bad programmer will find new and creative ways to mess up even the most well intentioned organization. A good programmer makes good code regardless of the pattern. Any arbitrary code organization can never improve the quality of code. A pattern is nothing but a framework after all.
In conclusion, frameworks are generally used by less skilled programmers. As skill grows, programmers transition to toolsets. In the end, flexibility and adaptability usually win.