Software frameworks make you more productive. They’ve handled all the boring, repeating stuff and leave you with the specifics of your application. Everybody knows you’re cool and really capable, but building on top of existing, solid, work and knowledge makes you more efficient. This is what all mammals do, by the way 🙂
Frameworks are not about a specific language. You’ll find numerous frameworks supporting several different or overlapping aspects of your everyday software projects and tasks in any language: Java, PHP, C#, Javascript (yes! javascript!), etc.
Framework, not library
It’s always good to repeat some key features of software frameworks which, by the way, distinguish them from libraries. Here’s a shameless copy from wikipedia:
- inversion of control – In a framework, unlike in libraries or normal user applications, the overall program’s flow of control is not dictated by the caller, but by the framework.
- default behavior – A framework has a default behavior. This default behavior must actually be some useful behavior and not a series of no-ops.
- extensibility – A framework can be extended by the user usually by selective overriding or specialized by user code to provide specific functionality.
- non-modifiable framework code – The framework code, in general, is not allowed to be modified, excepting extensibility. Users can extend the framework, but not modify its code.
Selection Criteria
It’s quite critical that you choose your framework wisely. Among different frameworks (for your favourite language) matching the tasks you want to accomplish and your philosophy about organizing code, you’ll probably find several differences. Below are some major criteria you should consider before choosing.
Invest some time
Got you. This is not a criterion. It’s a personal advice. Do not choose your framework in two hours. It’s the foundation on top of which you’ll be building your application for the weeks, months or years to come. Invest some time searching and discussing this. If you think this is the right portion of time to “save” to get your project started sooner, you’re just digging your own grave.
The penalty you’ll pay for having to switch to another framework in the middle of the project is too high to afford.
Features
Although different frameworks might target the same area of interest or bear similar principles, some might be feature-richer than others. Be careful to choose quality over quantity. Weight the rest of the criteria and then ask yourself: Do I really need all these features? Is there any expense I’ll pay for having them?
Performance
Some frameworks might lack some features because they trade them off for performance. It’s up to you (or your specific application) to decide how bad you need performance. Again, weigh things carefully. People tend to overestimate “the need for speed”. Remember that you spend money not only to the machines running your code but also to the developers writing it.
Documentation
The perfect framework comes with good documentation. Software frameworks aim at making you more productive, so if you have to waste half an hour for every few functions you want to utilize in your code, then your framework is pretty useless.
Documentation should come in two basic flavors completing each other:
- A reference manual: This is a (usually searchable) extensive list of classes and methods. If you know which methods you want to use but not remember the specifics, you need this to look up the details. Reference manuals are usually autogenerated from the framework’s code itself.
- Tutorials & books: Many framework authors are too lazy to write more than some inline comments that produce the reference manual. So think about a really powerful framework with hundreds of classes and methods virtually capable of anything, and yourself wondering: How do I combine all this stuff? This is where tutorials come in. You just can’t learn how to drive by looking at the specs and descriptions of every piece and instrument in your car.
Extensibility
Frameworks should by principle be extensible. If your framework restricts you to some default behaviour, then it’s only good for the use cases the author of the framework had in mind. To be honest, he didn’t really write a framework after all 🙂
Most of the time, extensibility means overriding the default behaviour. You’ll almost always need to change default behaviours in your framework.
The granularity of the extensibility is a good index for your framework. Chances are you’ll need to change little stuff here and there, and you should be able to do this quickly and easily.
Note: If you have to hack your framework to make it (look) extensible, you either don’t understand why you use a framework at all, or your framework is a mess.
Developer Community
Developer communities serve as both a reputation index and a contributing factor to frameworks. Good frameworks will eventually get a large enough community. It’s not really likely that too many people will start and keep using a bad framework.
The quality (or overall skills) of the community plays an important role, too, and it’s generally linked with the quality of the framework itself. Sloppy frameworks will attract sloppy developers.
Available plugins/extensions and their overlapping is also a good index. Good communities on good frameworks with a good understanding of code re-usability and extensibility contribute plugins/extensions, but only when they have too. A good extension is re-usable, and a well-trained community prefers to use a contributed re-usable extension rather than re-write their own.
Programming Style
Frameworks adopt a programming style (conventions, etc.) for their internals, which they implicitly enforce (to some extent) to their users/developers. You might find a framework’s programming style to suit you better. After all, a programming style is a matter of preference, as long as it is consistent.
Maturity and Stability
Nobody likes surprises in their framework. Your application depends on it, so there are two things you cannot afford:
- A buggy framework. You’ll have enough bugs of your own, the last thing you want to care about is the frameworks bugs as well
- A constantly changing API. Mature frameworks developed by serious programmers don’t break backward compatibility. At least not often enough, and without giving the framework users a reasonable amount of time to adopt their code. Even if your framework works flawlessly, you really don’t want to rewrite your code every now and then.
Activity and Maintenance
Frameworks are also projects themselves, supported by a development team. You need to make sure (or at least come up with reasonable indications) that these people will keep:
- Fixing bugs in the framework
- Extending the framework with new features
Zoo Coders 
Leave a comment