In defense of bloated frameworks

Sometimes I hear developers complaining about bloated frameworks, such as Spring, Django or Ruby on Rails. In this article, I want to explain why I think the arguments to support this thesis are (mostly) unjustified.

The arguments

The arguments are usually along the lines of:

• lots of unnecessary complexity (“We don’t need that anyway”)
• hard to learn all concepts (“What is all this?”)
• too opinionated (“I want to do it differently”)
• too heavy/slow (“Simple HTTP server library XYZ is so much faster than framework ABC! Just look at the benchmarks!”)

It is very tempting to just take e.g. a micro framework and get started quickly. Just add one library and write 3 lines of code - et voilà - you have a working HTTP endpoint.

The counter-arguments

I learned the following during my time working with established as well as micro frameworks:

• projects starting simple will usually grow in complexity and, and eventually, the project will implement its own, “in-house” framework - which is a worse, bug-ridden version of the bloated framework (think things like proper request parsing, dependency injection, testing, security, automatically generated documentation etc…)
• once the “in-house” framework is growing in size, you end up with a knowledge-sharing problem - new developers will have a hard time to learn your in-house conventions, as opposed to learning well-crafted and well-documented conventions of established frameworks
• opinionated frameworks and languages tend to perform well in bigger teams and are easier to hire for - there is no discussion about how to build things, if there’s a well-established path
• heavy and slow are (in my experience) often vastly overestimated factors - most times it is the code (or e.g. DB queries) that is slow, not the framework or language - and heavy is often not impactful in times of cheap disk space and network bandwidth

Takeaways

The key takeaways to sum up my opinion on the matter:

1. Focus on whatever is your core business. Do not waste your time on problems that are not strongly beneficial for your core business.
2. Do not re-invent the wheel. People have been solving a lot of problems already - make use of it.
3. Follow best practices. There are reasons why popular frameworks are structured like they are.

Summary

I will always try to go for established frameworks first, for the reasons stated above.

But, as usual, there are of course exceptions to this: There are edge cases where you need exceptional performance (e.g. raw HTTP throughput in high-traffic, low-latency scenarios) or when you need extremely dense build sizes (e.g. to distribute to IOT devices?). One should always consider carefully and use the right tool for the job.