The utility of frameworks polarizes communities. Not only there are many of them, they also solve more problems than the developer actually has. But maybe it's the concept of a framework which has been understood the wrong way all along.
In web development, a popular or widely used language and the upcoming notice of its flaws confluence together to emerge a period of time where enthusiastic developers will kick-off a framework to solve common problems in a common way. JavaScript had such an era, PHP had such an era, as well as Java, Ruby and Python.
The latter three evolved a single framework (Spring, Rails and Django respectively) to not only be the single known jack-of-all-trades programming solution in the language they're written in, but also defined our present reception of what a framework is for most of us: a toolset to collect common and otherwise repetitively self-coded solutions to problems of the programmer, so they can keep their actual application logic essential and neat.
Many mechanisms of deploying and structuring an application, for example as a set of components working together, only being held together by a framework, were not supported in languages by technologies we know today: dependency managers to load third-party modules as components into our application, or even the possibility of modularizing your application at all.
For this reason, earlier versions of frameworks which shipped for early versions of their language had to circumvent the lack of such features, and one result is that these frameworks came along as toolboxes to solve all kind of problems a developer commonly has in every project they face: database connections, HTTP request handling or console output, to name a few.
This turned the nature of early frameworks into a prejudice of what today's frameworks mostly are not anymore. Modern frameworks like PHP's Symfony (or smaller footprinted Silex), or VueJS for JavaScript, are essentially a collection of components and what delivers them as the framework we all know is the standard issue of a component collection. If you chose a good framework, it uses a well-designed dependency management system, with that we always should select the parts we need.
The components of Symfony, for example, are also widely successful in other projects and frameworks: the ORM data component of that project evolved into the Doctrine project, the templating component into the Twig project, the Symfony Console component is the most popular module for console output in the PHP ecosystem - and even used by the Symfony successor in popularity: Laravel.
So when PHP's inventor, Rasmus Lerdorf, expresses his scepticism about frameworks, he refers to a kind of framework which literally belongs to the last decade: a monolithic boilerplate with a pre-executing stack as wide as a server rack on which you just append your code onto. And since the current decade is also almost over, you clearly see how long this false understanding of frameworks kept in the heads of developers.
The modern framework is modularized and structured in components. The few concepts which a framework brings to all its depending applications are merely concepts which you would have and implement in your application anyway: configuration and autoload mechanisms (which can be part of the dependency manager now) or even patterns like Dependency Injection or Model-View-Controller, achieved in a way which can be shared as common knowledge between every developer familiar with that particular framework or - if your community came beyond a framework-popping era - a particular language standard like the PHP Framework Interaction Group presents in their widely recognized and followed PSR's.
Eventually, the framework of the present is doing what a framework always has been a concept for: it frames selected components to the solution. Just because there might be a component for every problem, it doesn't mean they all have to be in your selection: despite a framework offers the tools, it doesn't mean you use them all in every project. The toolbox the framework used to be by circumstance turned into a tool shop by the circumstance of an improving language, maintained by the respective framework community, and visited by you, the developer.
TL;DR Frameworks never supposed to be a swiss army knife, but a platform provider to make your frame containing selected modules work. The required modularization for this is a recently introduced feature to most of the languages popular frameworks base upon.
Top comments (3)
I generally look at frameworks as: they require my code to fit a certain shape to use them (e.g. my code has to inherit a class or implement an interface). Whereas I look at a library as: I can substitute a chunk of common code with a call to the library function/object. From this perspective, frameworks are restrictive whereas libraries are freeing.
If you are the only one writing code, that's great. But that way you rarely create maintainable software or follow concepts which make code more clean and structured. There is nothing wrong in following a framework's paradigm, as it represents publicly shared, interchangeable knowledge, while every custom structured program which merely uses some libraries is - knowledge-wise - a vendor lock-in to everyone who would probably like to contribute.
Writing code in a way which is widely understood by developers as it bows to publicly available best practices and standards can lower the threshold keeping people from filing a pull request to your project.
I used to think this way too. But maintainable software ends up depending on replaceable and refactorable pieces. If the framework doesn't fit some use case, you can't just refactor it. Even if you can (or if the framework provider does and releases a new version with breaking changes), you then have to refactor every bit of code that coupled itself to the framework. With libraries you can add the functionality as a separate / optional part. (Whether a library author does or not is perhaps another matter.) The most reusable pieces of software are structured as libraries with optional functionality rather than required abstractions.
I'm not sure how you got vendor lock-in from libraries? I wasn't discussing any vendors, and the library may even be internally created ones. E.g. Amazon maintains it's own infrastructure services libraries to make it easy for teams to access the Amazon infrastructures they need.
All that said, I do use some external frameworks in absence of other reasonable choices. And sometimes frameworks are a good answer to certain problems. Internally, I try to avoid developing frameworks for my apps. Because I tried it in the past and paid for it later. :)