Nothing is wrong about a framework - except what you might think it is

D. Guhl — Wed, 25 Oct 2017 21:04:03 +0000

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.

DEV Community: D. Guhl

Nothing is wrong about a framework - except what you might think it is