When to Code it Yourself or Rely on Frameworks

Some frameworks are robust, capable, and variable. They can be the perfect solution for problems of all shapes and sizes. Others are bloated, clunky, and inefficient. Those can cause more problems than they fix and have the potential of increasing cost and time requirements.

The problem isn't that not enough companies build frameworks. The problem is too many companies never question whether or not they should.

Whether to build a web framework is a huge question, and the answer won't always be yes. When it is, companies should code frameworks and stop relying on pre-existing ones.

Let's examine how to determine when to use a framework or code it yourself.

The discussion about frameworks has changed

Whether to build a framework or use existing ones is a question that has been asked more often in the past decade. The main reason? The internet is expanding. What the world expects from companies, apps, and the web is growing exponentially. Companies are trying to capitalize on those expectations. They want to create bold and exciting new web applications and products that entice consumers.

If you and your company are heading into lands unknown, does it make sense to tie yourself to a framework? If the whole point is that you're asking questions that have never been answered, you might be limiting yourself if you opt for a pre-existing framework.

Frameworks have their time and place. But if you're trying to stay on the cutting edge technology-wise and in the marketplace, coding your frameworks offers you more control and flexibility.  

Frameworks exist for very, very good reasons

It's a bit inaccurate to suggest that a company could ask nothing but exciting, never-before-thought-of questions. Every company is going to share universal connectivity, network, email, and other issues. Frameworks exist for that exact reason: There are some problems we all face, regardless of scope or size. (Strangely comforting, isn't it?)

Framework enthusiasts don't love using frameworks for the sake of limiting solutions or creativity. People who love using frameworks do so because they know that most questions that could get asked have been asked before. The average technical problem has been solved many times by plenty of people before us.

If your company uses different microservices and your web framework exists to assist them, it could be intimidating and terrifying to suggest hand-coding a solution or every one of them. In those cases, you should use a framework. It can save time and reduce anxiety about coding Kills.

For example, Spring Actuator is a framework that produces out-of-the-box metrics and production endpoints. The very idea of hand-writing dependencies and functionality for even a small-sized business could bring some developers to tears. So, there's no truth in suggesting that you shouldn't use frameworks.

Sometimes frameworks DON'T exist for very, very good reasons

The side opposed to frameworks makes a pretty simple argument. Unless your company or product has the exact problem the framework was built to fix, using a framework is inefficient.

It's a question of how much time, energy, and money you'll lose because of that inefficiency. Learning a framework can be a challenge, and often frameworks come with functionalities you didn't ask for.

Frameworks aren't plug-and-play. While most of them aren't exactly a whole new language unto themselves, they are like dialects. They are different enough that you can't just jump in. For each framework, you have to learn how it works, why it does things the way it does them, and you need to train your staff. If you're spending time learning frameworks, wouldn't that time be better spent learning a framework you built?

Frameworks also come with things you might not have expected. A popular example is using a framework to build a bike because it came with a frame and wheel. Before you know it, it also includes brake pedals, steering column, and an engine.

The framework was for a car, but you needed a bicycle, and now you're un-building the car so that the framework works for your bicycle. What you get is probably a motorcycle, which is pretty cool, but not what you were going after. The time you spend customizing a framework or re-optimizing the bloat could be spent constructing your own — one that has precisely what you need.

There are no hard and fast rules about frameworks. If you don't need one, don't use a framework — especially if it complicates or slows down deployment of services. In today's marketplace, speed and reliability are crucial to success.

A unique framework isn't an always-solution, but it can be the best one

If you and your company are at the stage of wondering whether you should be building your framework, you should consider doing so. Not every framework is bloated, complicated, or restrictive. Enough are that it can be dangerous not to question their use.

The internet and what people expect to do with it keeps growing more complex. If your company intends to deliver services consistently, you need to consider building a framework. You shouldn't rely on answers someone else wrote for their problems.