I will give a counter point.
I love well-designed opinionated frameworks. Whenever I want to do something simple, I agree that a framework may be overkill. A micro-framework is nice for those scenarios though.
However, whenever I build a project that will be maintained or extended by many people, opinionated frameworks give me the advantage that they force you to do things in a particular way.
Django is a perfect example. If all I am doing is two or four pages that just return static HTML, then why would I pick that at all? A new django project creates a specific file structure: urls.py, models.py, settings.py, views.py, middleware.py, etc. If I get a new Django developer that is not familiar with the project, I can pretty much drop him in and he will not what is going on quickly. I don't need to explain what a viewset is because chances are that the dev has used Djano Rest Framework before. Whatever changes are made, will follow the same patterns, so maintainability overhead is reduced.
When you add a project that is built from scratch without using a framework that has strong stances on how files should be organized, all bets are off. You have to spend a lot of time trying to wrap your head around the custom abstractions that have been built - and it is hard to argue that some of that will translate to a different job.
Yes, of course when you want to do something else that forces the opinionated framework to do things that it was not designed to do, it is a true pain - but you have to ask yourself if for that particular case it makes sense to use that framework at all (most likely not).
Frameworks also evolve. I use to curse constantly when I had to touch a Backbone JS project in the past, but now, I can jump and look at a React project that uses Redux and get to make changes right away without paying high cognitive cost. It may not be perfect, but it gives me structure and pre-defined patterns to worry about solving the actual problem I want to attack - and not waste time trying to create yet another leaky abstraction. My two cents.
> When you add a project that is built from scratch without using a framework that has strong stances on how files should be organized, all bets are off. You have to spend a lot of time trying to wrap your head around the custom abstractions that have been built - and it is hard to argue that some of that will translate to a different job.
I've worked in projects like this. In most cases, they contained what amounted to a part of a framework. The catch in the ones I worked on is that the authors had not realized they were building a framework and so did not think through their division of functionality, cross-cutting concerns like logging, and so on.
Inevitably, each of those had started as simple project. Over time, they had accreted one easy add-on after another. Eventually they're large, complex, and difficult to work on for anyone who didn't create them.
It's been my experience that most projects tend towards complexity over time. A well-chosen framework will require a bit of complexity up front to get going and provide a lot of options you can integrate as your needs grow. Preferably while letting you focus on the specific things you need that are different, rather than having to think about how you want to do logging and so on.
Strongly agree. For me the mark of a useful framework is that is reduces the complexity of the task you are trying to do. If it increases the complexity of the task, it isn't the right tool for the job! Choosing the right level of abstraction is the most important part of software engineering.
If all you need is HTTP routing, then Flask is great, but every time I tried to use it for the kinds of things Django is great at (databasing, templating, forms), I had to effectively roll my own crappy version of Django. (Something something every sufficiently large C++ program has a poorly implemented version of LISP embedded into it.)
I saw this dramatically demonstrated by an enormous Flask installation that would have greatly benefited from a little imposed structure. I bounced hard from that gig after being shown the code because it was going to be a massive pain to understand the poorly designed abstractions. But it wasn't even the maintainer's fault - it was pretty good code but it had only been designed by one person, both the abstractions and the business logic. And the abstractions were leaky simply because abstractions are difficult to design.
The framework allows you to completely offload the architectural decisions underneath the framework to many person-years worth of design, bug squashing, and security fixes. How do I add headers to a request? Django has one opinionated way. Where do I put my database models? models.py and if you put them there you don't have to do any connection fiddling.
The ideal of a framework is that if you release attachment to how things you don't actually care about anyway are done, you get thousands of free high quality lines of code.
I think it really depends on the use case, no? You can design a framework to be more or less restrictive, and the best tend to be less so, (which allows you to do stupid things but has good guidance on how to NOT to do that).
For instance, you could have an http framework that handles things like compression, buffering, timeouts etc, which are likely to work everywhere. But you could also design it such that each mime type comes with a separate class, like a HTMLTreeBuilder, or something like that, which would be horrible and way too constrained.
Elaborate type systems can, in some cases, seduce this kind of overengineering. If it really looks like something can be modeled as a type, chances are that the author cannot resist it.
Django is a perfect example. If all I am doing is two or four pages that just return static HTML, then why would I pick that at all? A new django project creates a specific file structure: urls.py, models.py, settings.py, views.py, middleware.py, etc. If I get a new Django developer that is not familiar with the project, I can pretty much drop him in and he will not what is going on quickly. I don't need to explain what a viewset is because chances are that the dev has used Djano Rest Framework before. Whatever changes are made, will follow the same patterns, so maintainability overhead is reduced.
When you add a project that is built from scratch without using a framework that has strong stances on how files should be organized, all bets are off. You have to spend a lot of time trying to wrap your head around the custom abstractions that have been built - and it is hard to argue that some of that will translate to a different job.
Yes, of course when you want to do something else that forces the opinionated framework to do things that it was not designed to do, it is a true pain - but you have to ask yourself if for that particular case it makes sense to use that framework at all (most likely not).
Frameworks also evolve. I use to curse constantly when I had to touch a Backbone JS project in the past, but now, I can jump and look at a React project that uses Redux and get to make changes right away without paying high cognitive cost. It may not be perfect, but it gives me structure and pre-defined patterns to worry about solving the actual problem I want to attack - and not waste time trying to create yet another leaky abstraction. My two cents.