Have you ever been in the situation where you are ready to start a new project but are overwhelmed by the framework options to choose from? How do you know which one to pick? Which will be the quickest to get up and running? Which one is the best to pick long term? Are there any costs associated? Grails? Spring Boot? Angular? .NET?
Many developers find themselves wondering the same things. Unfortunately, there is no one-size-fits-all answer; the right framework for you will depend on many different factors that you need to consider before making your decision. By taking the time to research your options ahead of time and taking into account the following ten considerations, hopefully the answer will become clear and you will end up with a well designed, easy to maintain, and cost-effective solution.
Make sure you consider the following ten items when you are trying to decide on which development framework to use:
1. How new is the development framework?
Determining how new the framework is may give you a good idea of how much longer the framework will be around. A newer framework may be around for a good while if it ends up being a successful framework. But too new and it will be harder to find support when you have issues, and there may be items that haven’t been tested sufficiently. Conversely, make sure the framework hasn’t been around so long that it is stagnant or close to it. You don’t want to be in a situation where a year after you finish development, the framework stops providing updates and security patches. Your best bet is to find a middle ground. Look for a framework that has been around long enough to be tested, but not so old that you’re concerned it’s at the end of its life.
2. Is it open source?
A framework that is open source generally means that while there is no “formal” support, there are more people helping to maintain the code. More people to maintain the code means there is less chance of it becoming stagnant as long as enough people are using it. Be sure to consider the velocity of contributions to the framework, though. If the open source framework doesn’t have many recent commits, the framework is in danger of being stagnant.
3. Licensing considerations
One major consideration will most likely be licensing. Is the framework free to use? If it isn’t, is the licensing cost worth any savings you might have down the road, either in development time or maintenance time? You should also consider any development tool you may need to or wish to use with the framework and if there are any costs associated with that. If you want to use .NET, the framework itself is free, but unless you want to use the express version, developing in Visual Studio.NET will add to your costs. Some frameworks and development tools may also charge you for support.
4. Available documentation
The more popular a framework is, the more likely you are to find good documentation available for your use. Good documentation can save you a lot of time both in the setup time and when you run into issues during development. Make sure you spend some time seeing how easy it is to find solutions to potential issues.
5. Ease of startup and learning curve
Make sure you consider the ease of startup for a framework and the learning curve of it. Maybe you want to use a newer framework that seems really cool that you’re been hearing about, but there isn’t much documentation for starting up a project or it is more involved. Same question for the learning curve. Does it take a while to pick it up? Is it very different from other frameworks? Or is it similar enough to something that you have used before where it shouldn’t be an issue? The cost of and time taken on projects can exponentially increase based on these factors.
6. Experience of your current staff
This consideration may be less of an issue if you are hiring a consultant (like Zirous!) to develop your project. But you may also want to consider your current staff if they’ll be involved in any maintenance in the future. What frameworks has your current staff already used? Development will obviously be faster with frameworks that have previously been used, but you also need to make sure you go back to consideration #1.
Even if development time will be sped up by picking a framework that has been used before, if you pick a framework that is toward its end of life, the benefit you get from using a known framework will be lost. If you are leaning toward a new framework that your staff hasn’t worked with before, how quickly do they pick up new technologies? Do they already have foundational technologies for the framework you are looking at? For example, if your staff has used Struts before – a Java-based framework – trying out Spring Boot won’t be as big of a jump as choosing Laravel, which is PHP-based.
7. Can the server side and presentation side be separated out?
This consideration is more for advanced developers as separating out the server side and presentation side fully requires more finesse and skill. However, there are many benefits. One benefit is the ability for developers to work on separate pieces individually. This also makes it easier to switch out technologies down the road if needed. Maybe your server side code is still working well but a better option comes along for the presentation side. You can rewrite the presentation layer without having to make changes to the server side and don’t have to rewrite the entire application.
8. Unit testing
Unit testing can save you a headache down the road by catching issues before you notice them causing problems. If a framework already has built-in unit testing, this can save you some time. Take some time to research how easy it is to build custom unit tests if you think you are going to take advantage of unit testing.
9. Are there any known security issues?
This may sound like a no brainer, but you would be surprised how easily this can slip by. Maybe you’re researching options using older information or articles, and a solution that would have been preferred two years ago has been found out to have issues. Take the time to research this beforehand so you don’t get blindsided later.
10. Future maintainability
When you look at a project over its entire lifetime, the percentage of time spent on maintenance (fixing existing issues, preventative maintenance, optimizing code) is typically 60-80%. This is a huge chunk of time compared to the initial development. The more people who use framework, the more unit testing there is, the better the documentation is, the number of staff members who know the framework, the simpler this will be. Your project maintenance will most likely continue for years and years after the initial development completes.
As you can see, there are many areas you should consider before selecting a development framework to use. For different people and businesses, each consideration may hold different weight. A framework that is the best option for one person may not be the best option for another. Taking the time to research before you make your decision can save you on not only cost but in time of development. If you’re unsure where to begin or are stuck mid-process, a professional like Zirous can be a huge help.