written by owen on 2019-Oct-06.

PHP Composer is like a cookie agreement websites put up that ask you to choose between being exploited or go away. Developers choose to jump into the PHP Composer because the phptherightway says that its cool. The echo-chamber is like "no modern PHP developer" or "No true Scotsman" can exist without composer. The advantages of Composer are small in comparison to problems it brings to the wider PHP community. Maybe it is a web dev thing or something but the constant push to "over-tool" has reached epic levels. In this article I go over a few reasons why I think Composer is an anti-pattern;

Composer encourages OOP bloat

One of the primary reasons for Composer (which few people talk about) is the fact that it allows big bloated, over engineered frameworks to continue to be big and bloated. Efficiency in framework culture is a measure of a good caching engine. Object Oriented Programming has been trying to fix impedence-mismatch syntax-sugar since the last century. In order to be "general purpose", frameworks tend to feature-creep at a high rate - getting deeper, bigger and slower each version. The bigger the framework, the harder it is participate in the framework code base - pull request? naw. PHP Composer is about easily updating a deep web of inter-dependencies and technical debt that have been amassed over years. This is advantageous for frameworks but hides the inherent dependance hell which the frameworks have created. Auto-loaders for the win. Composer is a way of continuing down the never-ending OOP/API/framework rabbit hole. The ideal number of lines of code in any project is as few as possible whilst being as clear and readable as possible!*

Composer promotes unstable and short-term code

Frameworks are known to constantly shift its parts from version to version. Code churn is a serious problem in modern programming. Large frameworks can be measured by the number of commerical side projects that benefit from their complicated nature. Sometimes frameworks make small fixes, or large breaking changes while keeping the same project title. The more active the community the more churn is generated to solve random problems. Toxic environments form around frameworks because of the constant need for new recruits. Rather than focusing on major long-term features, frameworks choose to change frequently and invalidate any mistakes as they go along. With PHP Composer this turbulence is no longer an issue; frameworks can publish unstable code and iterate, while changing slowly over time and deprecating as they go along. If users make the mistake of always importing the latest version of a package they are at the mercy of the third party overlords who can (and will) break the code every 6 months, or year or 3 years because shifting milestores or external forces.

Code rot, dead code, legacy and maintainability.

Since the frameworks have no incentive to remain stable (over long periods of time), code that is already written tends to rot faster than ever before. Third parties assume everyone is on the latest version, so everyone outside of that group becomes legacy - no matter how large the group is. Anything legacy is easily and automatically deprecated. Anyone jumping in on a old project is going to jump in on the latest version so it is up to the original developer to constantly stay up to date or risk falling out of LTS and spend months refactoring. The up-sell must continue and stable code is hard to upsell into cloud services. So you have this push to change combined with commercial interests combined with unstable/bloated codebases. Update fatigue. Remember Struts, anyone? PHP Nuke? WebForms? Would you rather maintain something that used either of those over something that was written in vanilla Java/PHP/C#?*

Planned obsolescence

Wanting to keep a working, stable, legacy version is one thing but the toxic community pushing composer is actively ecouraging the deprecation of everything that is not on the latest version. Frameworks themselves have side-quests to deprecate the codebase in some way or the other at a future point in time - developers simply do not know it yet. Even if a dev is keeping up-to-date, PHP composer allows the framework to silently and slowly erode the architecture against which the dev is coding so that - when the next version comes around - the framework can force a re-factor because the devs are not be aware of the "long-game". The long game are the small changes that are being added to meet a hidden future milestone.

Chasing version numbers

If a programmer is lucky enough to only install 1 or 2 third-party plugins in their vender folder then they might not have any problems. But heaven help them if one of those plugins start depending on other 4th party plugins, and those start depending on other plugins. It only takes one plugin deep inside to start requiring PHP 8 then your entire stack becomes legacy and insecure instantly. A domino effect. At which point the simple todo list that was created in 2010 now needs re-factoring. Developers have to constantly baby sit their application for fear that it will become useless after a random update. Composer promotes this deep coupling of tools, open source and commercial products that update themselves magically. In some cases if the developer falls more than 3 versions behind it might be impossible to get upto date meaning a full re-write might be easier than following the upgrade path of breadcrumbs.

Conclusion

Instability in the era of "modern PHP" programming is a developer trap being promoted as ease of use. Ideally you want the thinest technology stack that you can find, keep your code simple and stupid. No one wants to be the new Java. An experienced programmer knows the terrain (experience teaches wisdom) but new programmers are being on-boarded into a rabbit hole by narrow minded actors repeating memes. PHP Composer will not produce any new rocketships or flying cars. PHP Composer simply adds to the house of cards; PHPUnit tests, Behat tests (including selenium based UI testing), phpspec, design patterns, PSR, CSS pre-processors, js-UI, templating, books, PHP6, style guides and static analysis.

Allowing frameworks to grow wildly only benefits the frameworks themselves. As this instability is subliminally spread throughout the PHP community it creates a horde of tutorials, kluge and a over-arching "mono-culture". The framework noise of plugin culture reduces critical thinking. It makes it harder, similar to the agricultural practice of growing a single crop aka "mono-cropping". Continuous mono-cropping, where agriculturalists raise the same species year after year, can lead to the quicker buildup of pests and diseases, and then their rapid spread.

Footnotes

Framework Fixation - An Anti Pattern (2012)
PHP - The Wrong WayKISS PrincipleOn PHP Version Requirements (2014)

permanent link. Find similar posts in Articles.