In the world of big software projects, frameworks are common place. Frameworks attempt to make common activities easier to do. They promote code reuse and try to reduce the time it takes to write software. But what are you giving up when electing to use a framework? Let's take a look at a few of the disadvantages of using a framework and some things to consider when choosing a framework.
Downfalls
Architecture
In creating a framework, there are necessary architectural decisions to make in regards to how the framework will operate and how it will interact with other frameworks and libraries that may be used in conjunction with it. Because the framework is designed to solve specific problems, it may limit the architectural patterns you'll be able to use if you elect to use the given framework.
Design Patterns
Similar to architectural limitations, the framework designers also chose a certain set of design patterns to implement. In so doing, this will occasionally limit the design patterns you as a framework user can implement in your project. While in some cases this is rarely an issue, it quickly becomes a large obstacle if you encouter it. Trying to get a framework to use a design pattern it doesn't support is no easy task and often ends up with some ugly code.
Domain Specific Language
When learning a framework, some have added so much to the language they're based on that you're not really using that language anymore. The framework has become a Domain Specific Language on top of the underlying language. For example, when learning Angular, it could be argued that you're really learning Angular and you're not learning JavaScript or TypeScript. Similar things could be said for Spring or any number of other frameworks regardless of language choice.
Learning Curve
Another downfall is that the learning curve for the framework is often fairly steep. One reason for this is the topic we just discussed: they're often a Domain Specific Language. Another reason is that you might not be familiar with the problems the framework is trying to solve in the first place. If you don't know what problems you're solving, it can be hard to learn the solutions to them.
Playing Nice
One other issue that I've personally run into on a number of occasions is that frameworks don't tend to integrate well with parts of the system that aren't written in that framework. For example, if you have something outside of Angular that wants to execute a function within Angular, it's nearly impossible to do it. There are ways, but they're usually discouraged, hacky, and overly complicated. Similar things can be said for most other frameworks regardless of language or environment. Most frameworks have their "way" to do things and that "way" might not be easy to do from outside of the framework. This aspect doesn't affect new projects, but it can be a major issue when dealing with legacy systems.
Framework Considerations
So, with all these disadvantages, what's one to do? How do they choose a framework? Well, if you've decided that a framework really could clean up your project and make it easier to use, here are some questions to consider when evaluating your options:
- What problems are you trying to solve? Does the framework address those?
- What architectural constraints are you working with? Does the framework easily work within those?
- What design patters would you like to use to solve the problems you're anticipating in the system? Does the framework allow you to use those?
- Am I willing to accept the learning curve? Do I fully understand the impact that will have on the delivery team(s)?
Ideally you'll have done enough research, prototyping, or actual coding to know the issues your system has or will have. Once you have a good idea of the problems you're trying to solve, you can start narrowing your search for a framework that addresses those issues. Working the other way around can often lead to messy code bases that would have been better off if no framework were used at all.
Next time you're wanting to use a framework, keep in mind what you're giving up. Also be aware of the needs of your system before blindly choosing a framework. Your development teams will be much more efficient if the frameworks are carefully selected.
Comments
Post a Comment