The reason people misunderstand me, is that the word "framework" is widely used without any qualifier - a framework for what? routing? object/relational-mapping? validation? forms? annotations? all of the above?!
To most PHP developers, the word "framework" has become synonymous with "web framework with a full stack of components" - and the word "stack" is another word that is loosely defined and, to most PHP developers, this seems to be equally (or more) synonymous with "web framework with a full stack of components".
Phil Sturgeon recently took a stab at defining what a framework is, and did a pretty good job. At one point in his article, Phil concludes,
the application architecture IS the framework. The rest of it is components, which I think is very clear and concise - perhaps more so than the definition he highlighted in bold,
Frameworks dictate architecture*.
I don't think frameworks necessarily have to dictate the overall architecture of a web-application, and I think full stacks are much more guilty of "dictatorship", as they tend to integrate what is actually many different frameworks for different things, into what should rightfully be called a "web framework" or a "full stack".
I personally love frameworks that provide architecture for one specific thing - and in recent years, I am increasingly seeing "web frameworks" as being quite simply too broad.
"Web" is a very large and broad domain - to provide an architecture for "web", at large, is more than any one framework ought to be doing, and the result of attempting it, is bound to be extremely opinionated; that's the real reason people are so religious about frameworks, and it has been great to see things like Composer these past couple of years starting to drive people away from building still more full stack "web" frameworks, towards engineering smaller frameworks with much more focused responsibilities.
Having the freedom to design your own "web" architecture or "stack" using smaller frameworks, allows you to engineer with care and purpose for the solution you're engineering, rather than having to select from large "web" architectures, many of which do a ton of things you don't need or want on every project, and all of which are opinionated, in the sense that, what you're actually getting, is not just a "framework", but someone's opinion about what a web architecture should look like.
It would be terribly convenient if something as broad as "web" could be generalized into a "one shoe fits all" architecture that worked for every project and every developer - but that has not been happening, and I don't believe it's ever going to, because the needs of projects, and (perhaps least of all) the opinions of developers, simply are not all the same, and nor should they be; diversity is a good thing.
Anything with a scope as broad as "web" is bound to please at least one group of developers, if it's any good at all - but it's also bound to drive away another group, because it is, by definition, opinionated; you can't take on something as large as "web" without some measure of subjectivity.
If I've learned anything over the years, it's that developers opinions on very broad subjects are just that: opinions. And that includes my own opinions. The idea of "the perfect web framework", is a huge fallacy that many developers (including myself) pursue early on in their career - some go as far as writing their own, and most eventually let it go and move on.
The full stack "web" framework is therefore, in my opinion, a kind of arrogant and somewhat naive statement against anyone who happens to have their own opinions about architecture.
I say Yes to frameworks, but No to default architecture.
No comments:
Post a Comment