Frameworks change fast, but core skills persist and pay off in every stack. Before you reach for that framework, whether it’s familiar or untested, consider the strengths of building your own solution first.
What’s so good about frameworks?
It’s difficult to discuss frameworks without properly defining them, but even that’s a tricky task. The term has been so widely used, in various contexts, that it can mean different things depending on context.
A framework is similar to a library, but higher up the stack. So, while a library consists of a set of functions that you may choose to call from your own program, a framework often works the other way round. A typical framework provides out-of-the-box functionality that you can hook into, configuring values to override defaults, and writing custom functions to alter standard behavior.
Frameworks are popular (the Laravel PHP framework even has its own “wrapped”!), and they can be great since they provide a form of code reuse. Using a framework can save time and help you focus by limiting your available options.
What problems may I create if I use a framework?
Despite their obvious benefits, there are some reasons you might choose to avoid using one.
Choosing a framework can be tricky
If you’re writing your own code, there’s nowhere to hide. If you’re picking a framework, on the other hand, how do you even know where to begin? This list from Wikipedia is apparently just the “notable” frameworks, but even that is pretty daunting.
A significant part of your initial planning should involve researching and evaluating candidate frameworks. If you’re working with others, this can occupy a lot of time as you find a framework everyone can agree upon.
The barrier to entry can be steep
When you start using a framework, you don’t bypass the learning curve altogether. You may save yourself some programming effort, but you’ll need to understand how the framework operates.
For example, if the framework provides hooks for you to add your own functionality, you’ll need to understand when they run and what data they make available to your own code.
A framework can limit the depth of understanding
Even if you take the time to understand the framework well, there’s a temptation to focus on the parts that solve your immediate problem. Are you really going to dive into each API method for a complete understanding of the codebase, and how much time is that going to take anyway?
Without a good understanding of the underlying code, you may find that the good times are fine, but the bad times are catastrophic. If things go wrong, if you need to expand in a certain direction, or if your requirements change, you can end up wasting a lot of time playing catch-up.
It can distract from the original problem
On the contrary, if you do decide to take the time to research the framework in depth, you need to remember that you’re still ultimately trying to solve a problem. A framework will usually be a more general tool than you actually need, because it has to serve many needs, for many different requirements.
You might find bugs beyond your control
As with any dependency, you’ll need to be careful to avoid bugs that may arise from updates. While you don’t have to apply every update, you’ll probably at least want to keep in sync with minor patches, but these can introduce bugs and other problems.
Each framework has a wide audience, so an issue that affects one project may not affect yours, and vice versa. If you’re using a framework in a particularly unusual way, or with heavy customization, you may be more susceptible to these kinds of problems.
A framework can be less efficient
Because a framework targets a broad sector of users, it won’t necessarily be optimized for your use. You might not see any effects of this initially. Still, the more your project develops, the more likely it is that you’ll have to address a particular behaviour or configuration that your framework doesn’t cater for.
Using bespoke software, you can optimize your code even if you have to make compromises in other areas, because such compromises are possible.
The framework may drift from its original scope
When you pick a framework, you’ve hopefully explored its features to decide whether it offers you more than the alternatives. Whatever problem you’re looking to solve, that framework should handle it, ideally in the best way possible.
But what happens tomorrow, when the framework decides it needs to go in a different direction? You either go with the flow, accepting any trade-offs that come with the new approach, or you spend further time either trying to adapt it to your needs or evaluating your options once more.
With a bespoke codebase, the direction is down to you and your needs only.
Frameworks come, and frameworks go
In the mid-2000s, Ruby on Rails was everywhere; it was such an important framework that it drove many companies and developers to adopt Ruby. These days, it only just sneaks into the top 20 most-used frameworks, according to the 2025 Stack Overflow survey:
This doesn’t mean it’s a bad framework, but frameworks are susceptible to hype, meaning what’s hot today won’t necessarily be tomorrow. Chasing the latest framework is not only time-consuming, but it can also affect your decision-making too.
Solving problems from scratch can be more enjoyable
A framework can be tempting, particularly when you’re just starting to learn a technology, but that can be the worst time to pick one up since you’re jumping in at the deep end and avoiding learning about fundamentals you may later need to rely on.
But, more than that, I don’t think you should dismiss the “fun” factor of coding. Unless you’re purely in it for the money, there’s probably something about programming that you enjoy: you’ve been hooked by its creativity, power, or the problem-solving challenges involved.
Don’t be afraid to code from scratch, unless the project absolutely demands it. If you’re working with others in a professional situation, you may need to go along with project requirements to use a framework. But, in all other situations, you have the option to experiment, learn, and have some fun!
So, should I use a framework or not?
Nobody can answer this question for you, but you should at least be aware of it. In other words, before reaching for a framework, ask yourself, “why am I using this framework?”
Maybe you have a deep understanding of one particular framework, you’ve worked with it for many years, and you know its ins and outs. While you may be able to mitigate many of the above issues, you may be subjecting yourself to the Maslow’s Hammer bias:
It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.
Of course, it is equally unwise to dismiss all frameworks without good reason. Take into account the context of your project and the experience of any contributors you’re working with. Keep up with the state of the industry so you know which frameworks are popular, which are timeless, and which may be tempting but, ultimately, counterproductive.
