Third-party frameworks and libraries are (and will probably continue to be) a topic for heated debate. Some developers spend more time researching and evaluating a potential framework than they do developing stuff with it, some developers reach for new libraries as soon as they run into a problem. This article takes a look at some pros and cons of using third-party libraries and frameworks.
Framework vs Library
First off, let’s start with a few words on what constitutes a framework or a library. The Internet is full of different definitions, some of them argue that the application of the Inversion of Control Principle is the main difference between the two, while some argue that a library is a collection of task-specific methods and a framework is a broad, ill-defined term that could be equal to a library, be a collection of libraries or something much more involved. For this article, the only thing we need to agree on is that both a library and a framework are collections of methods with the purpose of speeding up development and abstracting away common or complex calculations.
Let’s start by looking at what advantages a framework / library can bring to our project if used correctly.
If you’re doing a quick proof of concept and want to show that your idea is feasible rather than build a production grade application, a framework might be able get you up and running faster than if you were to write all the code yourself. If you manage to get others onboard and secure funding to take the idea to market, you can decide whether you’d like to keep the dependency or whether you’d like to develop your own, custom made solution.
A framework could come in handy if an application requires a huge amount of work just to lay the invisible foundation for anything tangible. Let’s say that you’re developing an application that displays a lot of different data using graphs. It may take developers quite some time to develop the code that display the different graphs, so you may choose to use a third-party framework to reduce the time it takes to show anything at all.
This can be a competence and/or financial resources call as well. When implementing a service that relies on maps to display information to users, it probably makes much more sense to use an established maps SDK than to hire an entire department to create your own maps.
Tested And Refined Code
This one is only true in an ideal world, because the truth is that far from all libraries and frameworks that are available are updated / iterated on / supported in a timely manner. If a library has a steady user base and has been around for some time, chances are that it has been refined a couple of times. Bugs will have been reported, and a lot of them have hopefully been ironed out in recent versions. This is ultimately a judgement call, and it is one that should not be taken lightly when choosing whether or not to go with a framework.
The cons of using any frameworks or libraries can pretty much be summarized using a single word: Risk.
All external dependencies come at the cost of taking risks, and this is something that should be thoroughly considered before choosing whether or not to go with a framework for a production grade application.
Lack Of Support
We touched briefly on this is the advantages section, but from the perspective of using tested and matured code. On the other end of the spectrum, we find frameworks and libraries that are abandoned by their authors, and therefore don’t receive proper updates when languages evolve and weaknesses are found. You could end up building your application around a framework that will ultimately keep you from properly maintaining it, and that could cost you a ton of hours to replace it at a later time.
Major API Changes
Since you don’t control the framework, you also don’t control the changes that are made to the API. You may end up in a situation where you need to migrate to a newer language version (especially true in the Swift world, where I reside most of the time). The authors of the framework may think that the breakpoint between the two language versions is a perfect time to make some bigger, breaking changes to the API, and you will end up having to repair your interactions with the framework on top of the migration. Not fun!
Whenever you’re using a framework, your application will add on the size of that dependency, even though you may only use a fraction of the functionality. This is even more important for developers who have a tendency to reach for libraries and frameworks whenever they feel a bit lazy or don’t want to spend a little bit of time thinking about how to solve a problem.
So, Do You Really Need That Framework?
This is ultimately a judgement call (of course), and it varies between situations.
However, I personally feel like a lot of developers reach for libraries way too fast, before they’ve actually considered if they really need it.
To me, the best way of deciding is to start out in the “I don’t need this dependency” camp, and try to convince myself that it will actually be worth it in the end. This can be done by pointing to savings in time and/or costs, or the fact that I may not have the competence to create and/or maintain the functionality.
Note that “may not have the competence” should not be viewed as an easy out by saying “I can’t think of a way to do this right now, I’m gonna use that framework”. There’s a difference between skills I can learn with a few Google searches, and skills that require deep knowledge of a topic, knowledge that takes months or years of studies to acquire. Don’t let laziness make these decisions for you.