Frameworks are one of the hugest anti-patterns in software development. They're hard to learn. They limit your creativity. They increase your project's complexity and dependencies. They go out of business and get abandoned. You have to maintain and upgrade your code to match the latest framework versions for no good reason. You have to search for help and ask others for advice when you're stuck. And you probably only need a small percentage of features that the framework offers anyway. They just don't make much sense.

You should prefer core-language solutions to small abstractions to small helper libraries to general libraries to frameworks. Software should be developed using least amount of complexity, dependencies, effort and using fundamental tools that have been and will be here for the next 20 years. Frameworks are at the far end of software complexity spectrum and you want to avoid them as much as possible. You should be fighting complexity and not embracing it. I don't use frameworks and I encourage you not to use them as well.

In fact, one of the rules for writing software at Browserling is to avoid frameworks at all costs. There must be a tremendous reason to use a framework. So far we've used 0 frameworks and just a few libraries to get things done. I've yet to see someone come up with a good reason to use a framework. Simplicity is the law at Browserling. I've taught my employees well to never choose a framework solution and to try to find the simplest solution starting from the core language and core tools and going up.

Let's go over the reasons why you shouldn't be using frameworks in more details.

Frameworks are hard to learn and this knowledge is generally useless

Frameworks take a lot of time to learn. Instead of learning fundamental tools, core computer science concepts, and programming techniques, you spend time learning something specific and generally useless. Just because someone invented a framework and many people use it doesn't mean you need to learn or use it. People give in peer pressure too easily. "Everyone's using FrameworkA/FrameworkB, I must be using it as well."

No, you shouldn't.

You should be thinking, how do I avoid using this framework? How many actual features or core concepts do I need from this framework? Can I implement these features in a hundred lines of code and be done with it and never depend on this framework? Who are the authors of this framework? Do these guys have a track record of maintaining their code or did they just put it together in a weekend and released it?

Don't learn useless frameworks that have no value.

Frameworks limit your scope of creativity

Frameworks limit the scope of your creativity. Frameworks put you in a box you can't escape. Frameworks make you dumb. Whenever you're faced with a problem you can't just invent a solution; you're limited by what the framework lets you do. You have to seek experts, waste your time and energy to find a solution to a problem you shouldn't have had in the first place if you hadn't used a framework.

You can't let framework authors control what you can or can't do. You should be in total control over your product.

Frameworks increase your project's complexity and dependencies

Complexity and dependencies are bad. You should keep both your project's complexity and dependencies at minimum. If no one controls complexity and dependencies, and no one enforces how software is written, then one dependency leads to another, and soon your project ends up using 25 different frameworks and 5 different programming languages. There should be strict rules what you can and can't use in your project, and someone has to make that call.

Without rules you might save time at the beginning and sound cool using all the latest frameworks, but now your software is so complex that no one understands how or why it works. It's also become unmaintainable. You may not notice it in the first few months as things are moving along quickly, but as your project progresses, your team's productivity will drop because of all the complexity and dependencies. You'll need more people to maintain it, and more people with specific knowledge to maintain it. If your lead developers leave, you're dead.

You should be fighting complexity and not embracing it. Every added framework, and even library, makes your project more difficult to maintain. Avoid unnecessary frameworks and libraries from day one.

Frameworks go out of business and get abandoned

Frameworks go out of business and new frameworks appear. You have to learn the new frameworks again. It takes a lot of effort, energy and resources. You just spent all that time earlier learning the old framework and now it's out of business. All the skills you accumulated are now useless.

Everyone's hyped about the new frameworks and you don't want to be left out, but in fact you shouldn't even care what they are. Core fundamental tools already let you do everything that these frameworks do and you'll just waste your time learning something that doesn't solve anything new. The more marketing and buzz a framework has, the less you should trust it.

Even worse, framework authors sometimes just abandon their projects or they quit the projects and delete their entire projects. Your entire build now fails because of one author.

Use fundamental core concepts, solid tools and programming techniques that are here for the next 20 years, rather than frameworks and useless libraries. You don't need them.

Frameworks evolve and you have to spend time upgrading your framework versions and other dependencies.

If you wait too long between updates, frameworks have changed dramatically, and you have to spend days adjusting your code and learning the new interfaces. You don't need all the extra functionality the framework developers added. Most likely you don't need anything at all from the new version.

Framework developers can't stop evolving their projects for no good reason. Often software is just done. It does what it's supposed to do and doesn't need any changes ever again. You don't need the latest version of every software. Some of the best software was written 10 or 20 years ago. Use it!

Upgrading versions for no reason is another huge anti-pattern. If software works at version X, then it should stay at version X and should never be touched unless absolutely necessary.

Ask how happy your developers and system administrators are when you have to upgrade from Framework v1.4.3 to Framework v2.0.0. It's the worst time of their lives.

You have to ask others for help

When something goes wrong with the framework or you get stuck, you can't just come up with a solution because you're limited by what the framework lets you do. You have to ask for expert help, wait until someone helps you or pay an expert framework consultant.

If you keep your dependencies to bare minimum, then you're the expert and you can quickly get things done and come up with the solutions without ever asking for anyone's help or advice.

You probably only need just a few of framework's features

I've seen this again and again - someone starts their project with a bunch of full blown frameworks when they only need a few features from each. At this point they have already destroyed their project. "Which frameworks shall we use?" is the wrong question to start you new project with. Start your project with an empty file and use programming and a few helper libraries and core tools to get it going.

Use frameworks only when absolutely necessary

I'm not saying that there isn't a use-case where framework would be good but it should be an absolute exception. The only areas that come to mind where frameworks make sense are mathematically complex areas of computing such as sound processing, image processing, and machine learning, where it would take many months to write the code that does the job. And even then you should try to avoid them.

Friends don't let friends use frameworks

Until next time!