6 Things to Consider when Choosing a Framework
You’ve decided that it makes sense to use a framework when writing your next new application, and chances are that if you’re already familiar with a specific framework, then you’ll probably be leaning towards using that one when you start. But are you sure it’s really the most appropriate for the task at hand?
In the name of due-diligence, here are some of questions that you should ask yourself before settling on a particular framework to make sure you’re not programming “against the grain” and also to make sure it will be able to meet your needs now and in the long-term.
What do I need from the framework?
Familiarity is important, but functionality is more so. Therefore, consider what functionality you really need from the framework. It doesn’t make sense to use a full-stack framework if you only need routing capabilities, for example. Once you’ve identified what your situation requires, you can begin to intelligently compare the offerings of the myriad of available frameworks, whittling down your choices making it easier to choose a final candidate.
Do I expect the framework to help manage consistency?
It can be difficult to maintain proper communication in a large team of developers, especially if the team is distributed. Individuals will have their own preferences when it comes to formatting code, naming objects, etc. and may re-implement code that is already available in elsewhere in the codebase. Frameworks can help in this regard, but be mindful of depending on it too much to maintain consistency. A framework is not a replacement for coding standards, code reviews, and other internal control policies.
Is good documentation available?
I’m sure we’ve all experienced how difficult it is to understand code we’ve written, set aside for six months, and then come back to. Even though we wrote it, it seems as if we’re reading it for the first time. With a framework, you’re always reading and working with someone else’s code. Choosing a framework with a history of providing good documentation and training will make understanding the code and using the framework to its fullest potential much easier.
Is the framework actively developed, and does it have an active user base?
It’s time consuming to write code that isn’t tightly-coupled with the underlying framework, thus it’s all too common for a framework to become an integral part of an application. So if the framework you rely on ends up fizzling out, you’ll be faced with two choices: stay with the framework and take on its maintenance yourself, or re-write your code to use a new framework. Neither are very enticing propositions! It’s imperative to make sure you don’t get stuck with a ticking time bomb, so take the time to research the history and community of a framework while you’re still in the planning stages so you can avoid this pit fall.
Does the framework work in what I run in production?
What business factors are influencing my decision?
If you’re a small business and want to impress a particularly large business during your negotiations, you may be forced to choose a framework that their development shop prefers. Such a scenario plays into the choice to use a particular framework all too often (I’ve actually seen a PHP application that uses not one but three different frameworks precisely because of this reason). The subsequent consequences can be good or bad, and it may be something you have no control over, but it’s something worth bearing in mind.
Not every application needs to be written using a framework. But if you’ve decided that yours does, then it’s beneficial to compare your needs against the features and benefits of the various framework offerings. It may be a framework you’re already familiar with, or it may be a new one, but only through objective analysis can you be certain it’s truly the best fit.