- Mehmet Baris Kalkar
Definition of the word opinionated by merriam-webster is:
firmly or unduly adhering to one's own opinion or to preconceived notions
In software development related discussions however, this word is used together with languages, frameworks or tools and it has a more specific meaning.
An opinionated framework/language has an “intended” or “right” way of doing things. Python is considered opinionated because there is a “pythonic” way to solve problems. Spring boot, Django, Ruby on Rails and Nestjs are pretty good examples to opinionated web application frameworks. Because they have well accepted ways of implementing things. For some of the more common encountered issues, they even have default configurations and implementations.
This does not mean opinionated tools are not flexible. It means, if you use the language, library or the framework correctly, everything should be straightforward and reasonably simple. Or in other words, it should “just work” if you are not doing anything crazy.
We have similar frameworks in all languages and there is a good reason it. When we build production ready web applications, we need to think about a lot of common issues. These are not related to the business solution we want to create but they still take time to implement properly, even if we assume developers have the expertise.
- Request routing
- Error handling
- Request/Response Serialization/Deserialization
- Database access, possibly with an ORM tool
- Request filters
Most opinionated frameworks not only have solutions for all these issues, they even have sane defaults So we might not need to think about asynchronous logging or Serialization at all during development. Or when we are implementing authentication, we might use a lot of code from the framework instead of writing it ourselves.
Similar to how design patterns help the development process, having a shared set of rules and processes to implement functionality can help productivity and maintainability. This is especially helpful to prevent bike shedding around folder structure, naming things etc.
Working in multiple projects using the same framework makes switching between them easier and this is a huge boost in productivity if we can leverage it.
When building services without much experience, using a good framework can teach us about best practices and industry standards.
We have to follow a structure and it might not be ideal for our use case.
If we leave the golden/happy path things start to get difficult.
We might not need all the complexity or the default functionality provided.
Even sane defaults might be too magical if we are not aware of them. This is one of the pain points for Spring Boot from my experience.
Benefits certainly outweigh the cons in my opinion but the decision of using an opinionated vs non-opinionated framework depends a lot on the team size, complexity of the application, number of projects running in parallel and experience of the developers. In any case, understanding why these frameworks exist and the problems they solve is important before this decision.