Each time I start a new project I find myself looking at the latest batch of frameworks. Lately those are web frameworks, such as CakePHP, RubyOnRails, perhaps JQuery, or any other of the thousands which seem to exist. Usually I end up using none of them. Mostly they are too complex, too bulky, and too restrictive. Some projects confuse rapid application development (RAD) with a framework, sometimes a content manager is called a framework, and a significant number are simply junk.
From my experience I’ve put together these rules for framework development. Developers following these rules will find they produce top-notch frameworks which have a long life. Others not following rules might manage to produce a fad, one which will result in user ire and likely wane in popularity.
Not designed, but evolved
I have never met anybody who was capable of producing solid requirements for a framework in advance. Even the best intentioned designer loses sight of their users and ends up specifying features which simply aren’t needed, or don’t work correctly. Like any major project the framework must evolve with a set of users, or at least several projects. Use cases, and use driven development must be the primary motivator for the framework.
Most frameworks unfortunately seem to come from an isolated world. They tend to be feature laden but always miss the feature you need most. Equally common are needed features which just don’t have an appropriate interface or are overly complex to use. Frameworks, unlike libraries, have an unlimited set of possible features and use. Only through using the framework in multiple projects can a good solution be reached.
Highly flexible
A good framework lets you completely ignore it and do something on your own. Furthermore it must not be an all-or-nothing approach. Framework components must be usable and adaptable outside the original intentions of their developer. If the user wishes to render one page differently then it should be possible. If the user wishes to load a JSON object instead of XML at one point, then it should be possible. The framework shouldn’t anticipate all uses, rather it should be arranged as adaptable and extendible.
There are lots of so called frameworks suitable only for a very narrow range of applications. In bad frameworks the users will find themselves fighting with limitations and needing to do magic tricks to get what they want. A good framework allows graceful integration with custom components and can be used as needed, when needed.
Frameworks are not applications
Regardless of how many features have been packed into the thing, regardless of how much utility it appears to have on its own, and regardless of how easy it is to setup, a framework is not an application. This puts the framework in its place as merely being a tool to build an application. As such it is the framework which must contort to the wishes of the application, not vice versa.
The most common violators tend to be rapid business application development tools and content management systems. One is reasonably good at managing business objects and pumping out forms, while the other is good at organizing a bunch of documents. The moment you try to add in something custom however you’re out of luck, since they aren’t actually frameworks, but highly customizable applications.
Completely modular
The user of a framework should never be stuck using something they don’t like. While the default setup may be a robust system, a solid framework is but a skeleton combining many modules. This should include all aspects of the framework, from data handling, to security, to content management. If the user doesn’t like the template system they should be able to substitute a new one.
Further to having replaceable parts, those parts should all be usable directly. A user should be able to directly hook into any module as they see fit without needing to jump through framework hoops. This also means those modules may not make assumptions about other framework parts: a classic spaghetti framework. In its truest form the original framework is actually nothing more than a good suggestion for how to use all the modules.
Must work in their target language
There is nothing worse than a framework ported from one language to another. Users of these languages will get uneasy with the foreign feel of the framework. If the language offers iterators, then lists from the framework should use those iterators. If the language has objects, then the framework must use objects. If there are exceptions, I’d equally expect the framework to use them for error reporting.
This also means that the framework as a whole must be usable directly in the language. While external preprocessors or compilers may be used for the components, the construction of the application as a whole must be done in the language. Without this the user of the framework will not gain full use of their language knowledge and will feel artificially constrained.
This further means the framework must work in the true version of the language. It may not require custom compiler extensions, non-standard extension modules, or patches to the VM. It may also not install run-time hooks which alter the normal behaviour of the code. All of this nonsense just leads to difficult to track bugs that no team feels responsible to fix.
They need not be complete
Not every framework needs to be able to build end-user applications from scratch. If every framework properly followed the rules of being flexible and modular it shouldn’t be a problem to combine several together. They should essentially work like libraries in this regard. If you wish to develop a great security system, then just do that. Rather than adding more and more application modules, just develop the appropriate adaptors and get it working with another framework.
As a general rule the more complete a framework the weaker each component of that framework is. It is simply illogical to think that a single team is the best at everything. The distribution may include a complete system, but it must comprise several other libraries and partial frameworks. All of which of course can be replaced with something else.
Conclusion
Too many frameworks are bulky pieces of crap. They fail to address the needs of their primary users and are unable to accommodate secondary desires. But people love frameworks and rapid application development, so they become popular. Despite this you’ll still find the vasy majority of apps just don’t use the most popular frameworks. You’ll also find a few major projects which used the framework and now have their own branch, or have completely given up on it.
A framework should be simple and easy to use. It must save the users time rather than create headaches. If all of the above rules are adhered to you’ll find your next framework will become a great tool. You’ll have no trouble adapting it to your own future projects and accommodating the wishes of outside users.
