What is a framework ?
Frameworks provide a boilerplate or base wire frame to build applications on.
They take care of redundant basic tasks so that sophisticated applications can be written on top of it in simple manner. Frameworks are generally generic add-on on top of a programming language. They don’t function by themselves, code needs to be written that utilizes that frameworks feature to give the framework life.
Example : Python can be used to do anything computing. But Django framework on python is used to build web-apps and web services.
You can build an application without using any framework but a framework provides you most commonly used functionalities out of the box so that you don’t have to spend time re inventing the wheel unless you are solving a very unique use case.
Why should I use a framework ?
- Frameworks are designed on the basic principles of programming — abstraction and re-usability. Most commonly used functionalities for an application are bundled together and made available for developers to build on.
- Popular frameworks are often maintained and evangelized by tech giants. For example — React is maintained by Facebook, .NET is maintained by Microsoft.
This helps because such frameworks are —
1. Battle tested for scale.
2. Feature rich and should be able to support most common use cases. - Usually there is an open source community which supports and contributes to a framework. This has a lot of advantages —
1. You get new features and bug fixes for FREE.
2. Time to market for your product goes down significantly since you now how to just take care of your own business logic.
Which framework should I pick ?
More often than not there are multiple frameworks available to achieve the same goal. In such cases how do you decide which one to pick.
These points apply to any open source technology (product/platform/library/package) you want to use in your application and not just frameworks.
- Make a check list of your use cases and integration points. Go through the official documentation of the framework and see if it satisfies all of your use cases. For the ones it does not, see how easy it is to build those functionalities on your own or extend the framework to do the same.
- Go to the open source repository of the framework and see when was the last release. You should always pick a framework which has a consistent release schedule and is actively being worked upon. Using a dormant framework could be counter productive with no community support in case you hit a blocker in the framework.
- Go through the list of open issues corresponding to the framework to get an idea of the stability, activity and bugs in the framework.
- Check the documentation for the framework. Always pick a framework which has ample documentation.
- Know the long-term costs of your technology decision. Be aware of ongoing licensing fees, developer program memberships, specialized hosting, etc.
- Always go through the list of existing products where the framework is being used. This will help you get an idea of the quality and production readiness of the framework.
- Consider the expertise and experience of your team members before picking a framework. It is always better to use a framework that some of your team members are experienced with rather than using a completely new framework (considering it ticks all the other boxes).
- Pick frameworks with lower learning curve.
- Check if the framework satisfies your scaling needs at least 3–4 years down the line.
Pitfalls
- Always make sure that you have a upgrade path for the framework you are using within your product. A lot of times companies fork a certain version of the framework and never upgrade their version of the software as new releases come in. This means that you would never be able to get in new features and more importantly bug fixes that come in the later releases.
- Be aware of tight coupling with the framework. In some cases it might not be possible to avoid the coupling, but design to avoid tight coupling with frameworks as much as possible.
- Keep it lightweight ! Sometimes a framework might come in with a lot of features that you really don’t need to satisfy your use cases. More features could mean more overhead in terms of deployment cost, learning curve or resource consumption. In such cases do your analysis and pick a more light weight framework.
- Pick a stable version of the software.
