The pros and cons of using a framework
Time to go over the advantages and disadvantages to our favorite problem-solving tool! In this article, Nikola Kolev gives a general overview of libraries and frameworks and explores how to choose which structure is the best to use for you.
When facing a specific problem, programmers have three choices: to use a framework, to use a carefully chosen set of libraries, or to create their own solution. Creating a solution from scratch is not ideal, especially if the problem is from a well-known domain. The odds are good that a tool for that problem already exists and has been in circulation for years. Creating a custom solution is an expensive and time consuming task; it is only worth investing in if the problem is unique and otherwise unsolvable.
In this article we will be focusing instead on frameworks and libraries. Both of these options each have their own advantages and disadvantages, all of which must be taken into consideration when deciding between them.
Before we get started, it’s important to clarify what we mean when we speak about frameworks and libraries.
Frameworks are a kind of programming abstraction that holds together the user-written code. A software framework is a universal, reusable software environment that provides particular functionality as part of a larger software platform. This facilitates the development of software applications, products and solutions. Software frameworks may include support programs, compilers, code libraries, tool sets, and application programming interfaces (APIs) that bring together all the different components to enable development of a project or system. Frameworks are fairly similar to libraries and they’ve become a bit of a buzzword recently, but they do have some distinguishing features that separate them from normal libraries.
- Inversion of control: in a framework, the overall program’s flow of control is dictated by the framework and not the caller. This is the opposite of how libraries work, where the flow of control is dictated by the caller.
- Extensibility: a user can extend the framework – usually by selective overriding; or programmers can add specialized user code to provide specific functionality.
- Non-modifiable framework code: the framework code is not supposed to be modified, but it can accept user-implemented extensions. In other words, users can extend the framework, but they should not modify its code.
The framework itself provides a certain opinionated flow of control. What you have to do is provide implementations of the application business logic and the framework will call those, relieving you of thinking about database connections, transactions, data transportation protocols, etc. For all these the framework provides configuration endpoints but you will not have to explicitly instantiate the classes, pass the configuration, allocate/deallocate resources, etc.
Consider unit testing. Every project should have tests but it’s not an easy task to automate those – e.g. execute the tests, collect results, present those results, compare results between test runs, etc. The developers should not waste time on implementing such functionality. A unit testing framework should provide blanks spots where the developers can plug their tests and the framework will take care of the rest.
A unit testing framework is just one simple example of a framework. Usually a framework will take care of much more. Take for example the powerful Spring Framework. It contains a vast toolset for building large applications with transaction management, security, batch operations, etc. The list goes on and on. A framework could give a project a flying start – usually what is needed by the programmers is to provide a couple of configuration files (e.g. DB configuration) and start implementing business code directly.
In real life, libraries are places where you can access information for free. But as far as programming is concerned, a library is a collection of objects, functions, and methods (depending on the language) which can be reused and shared among multiple applications. A library performs specific, well-defined operations.
A library is usually created when a problem of a certain domain starts to be frequently encountered in programming. A common example are operations and data structures which are not built into the language – like reactive extensions, advanced collections, etc.
Essentially a library provides an API which your code will call. This means that your code is in control of invoking the functionality of the library. This is actually the key difference between a framework and a library. When using a library your code calls the library; when using a framework, the framework calls your code.
When making the decision between using frameworks or libraries to solve a seemingly intractable programming issue, you should take into a count a number of factors.
- Team expertise: a framework usually benefits teams with lower expertise, by providing them a rich set of functionality and more importantly an opinionated approach for development. This leads into less room for mistakes. That leads to more structured and readable code, which is often what less experienced teams struggle with. On the other hand, a framework has a steeper learning curve than a library. This means that even a team of experienced professionals might struggle with getting up to speed with a framework which utilizes unfamiliar concepts. A set of libraries might be a better choice in this case.
- Team size: a framework benefits smaller teams and tighter deadlines because it provides a lot of functionality out of the box. If all the programmers need is some configuration files for the database, a basic framework provides that and allows them to start hacking. Exposing a documented REST interface is just a matter of a few lines of code. This allows for the team to start producing business value almost from the get-go.
- Project size: frameworks tend to benefit smaller projects. A framework might be a constraint on bigger projects, as it is difficult to modify the flow of an application under the direct control of a framework. Extension points help, but as projects grow they tend to require more and more specific functionality which may not be supported. Therefore I would say that for small projects a framework is very beneficial, but for large ones those advantages go away.
- Security: a good rule of thumb is when choosing any external tool is to check how many and how severe security patches it has had – especially short-term security patches. If a tool has had a lot of those recently, chances are that it’s not stable enough security-wise.
- Community/commercial support: is there a lively community or a good commercial support around the framework/library which can help you solve issues quickly? If so, then it’s probably a decent choice for you and your team.
- Licensing: every external tool comes with a license which has to be taken into consideration according to company policies. Some companies are very restrictive regarding using open source software since they are usually provided without any guarantees and responsibility.
- Hype factor: this is also a very important consideration. Managers tend to prefer stable and proven tools because they are mature and proven in the real world. Unfortunately this usually means they are old and programmers don’t like old. It makes little sense to choose an old technology if you won’t be able to find anyone to work with it.
- Organization policy: maybe your team wanted to use that shiny and new Angular framework for their new project? Too bad, the organization has decided that all front end code is only written in React.
- Technology lock-in: there are frameworks which are tightly coupled to other frameworks or libraries, usually provided by the same company. Such ecosystems tend to be more stable and with better support. However, introducing other technologies into the stack is sometimes deliberately difficult. Also, such ecosystems tend to be slow to adopt new technologies and approaches. (Not to mention the expense!) In my opinion, technology lock-ins never work in the long term, but the reliability certainly has an appeal.
Luckily the choice between a framework and a library is not strictly either-or. A project usually ends up using a mix of libraries, frameworks and custom solutions and that’s perfectly fine. After all, software engineering is exactly that: an engineering discipline in which there are multiple paths to the end goal with different trade-offs.
In conclusion, it’s important to remember that frameworks give you speed and opinionated development practices, while libraries give you more control. Whatever is more important for your next project is up to you.