
The last decade saw a flood of development frameworks. JavaScript sees a new framework almost every quarter. Some find this an exciting opportunity to learn and try out. Others feel frustrated that their knowledge is never up-to-date. Some want to use the latest framework in every project they execute. Others want to stick to the good old... Some have a phobia of frameworks, while others have a mania.
Obviously, neither extreme is good.
Frameworks can significantly reduce effort and the number of surprises we meet on the journey. At the same time, if not used properly, the same framework can cause several problems in application development.
Obviously, nothing good or bad about the framework. It is the way we use it that really makes the difference. With that disclaimer, and with due apologies to the developers who spend their sweat to create better and improved features for the rest of us, I feel some of those frameworks are doing more damage than help.
Let's settle it here. I don't mean to say that we do not need frameworks. I don't advocate using vanilla JavaScript for all your applications. Certainly don't propagate re-inventing the wheel.
However, I do recommend that we spend some time evaluating the problem at hand and think if a given framework will really solve the problem. Here is a list of patterns and anti-pattens that I use to identify a framework for an application at hand.
Parameters for choice
When choosing a framework, people tend to choose the framework based on what is most recent (looks good on a CV), or based on the cost of developers in the market. If you are working on an application with a reasonable size, either of these parameters will lead you to an incorrect decision. Most frameworks can be easily learned (to get workable knowledge) in less than a week. That is the least of the investments.
Instead, I prefer to use the below parameters to choose the framework.
Code size
Every framework demands a chunk of libraries that we include, along with some boilerplate code that goes into using the framework. Here, we must ask a question: What is the ratio of the size of the library, and the boilerplate, compared to the business logic that I am going to implement? Ideally, the boilerplate should be much smaller than the business logic.
If not, you are messing it up.
Problem direction
Every framework is made with a particular problem in mind. Unless you are working on a textbook assignment, your real-world application problem is different from the framework's problem. That means your problem is divided into three components - Configuring the framework as per the recommendation, adapting it to your requirement, and then adding more functionality that is missing in the framework.
When choosing a framework for your application, consider these three aspects of the effort. Are you wasting yourself configuring and adapting the framework to do something it was not meant for? Or is your framework too frail, leaving you with all the boilerplate code?
If we do not have a good balance between these three components of the effort, we can be sure we have messed up the architecture.
Community
This is the most important and acknowledged parameter. You cannot code without help from the community. How does the community respond to a question related to this framework?
If the framework is too new, with very knowledgeable users responding on StackOverflow, you must use it in the next Hackathon. However, it is too early to use it in a production application.
The production application should have your code, tested and validated by you, using a framework that is extensively tested by the world.
Simplification
Is the framework meant to simplify complex components of the language or a parent framework? Such frameworks could be good if they continue to provide the same power with a simple approach. If this simplification is at the cost of power, better think again.
Summary
There are hundreds of frameworks, all developed by brilliant minds, with great intentions. However, as an architect or a developer, it is your responsibility to choose the appropriate framework. Take some time to evaluate the choices available. Don't fall for the hype. Instead, measure it on specific parameters.
Comments