In many ways, the transition to PHP 7, from the 5.x line we had used for many years before, was a clean break, an opportunity to clean house and sweep aside development practices and software dependencies that had outlived their usefulness.
Operating on a codebase which had grown out of the days and practices of CodeIgniter and their ilk, which had proved useful for years but was unquestionably showing its age, we jumped at the opportunity to build the framework we would like to use in 2016, rather than the one we had inherited from 2009.
Here was an excuse to revamp our development practices, throw out bits that made sense in 2008 but were a source of a headache today, and incorporate improvements that have taken hold in the ecosystem in the meantime.
Most notable improvements are the standardization efforts that have occurred under the umbrella of PHP-FIG, and the package management ecosystem(courtesy of Composer) that these standards have enabled and allowed to thrive.
A packaging system is something that, given a lack of, you will inevitably try to invent yourself — poorly, incompatibly, and inevitably counter-productively. Such was the state of the PHP framework ecosystem before standardization, and the reorientation of our own framework from an inward-facing framework to an outward-looking one. A framework which naturally integrates with third-party packages and is itself incorporated into third-party packages in a similar fashion.
In this series, we will explore the changes that have occurred in our own development practice, the ways in which these are reflective of the ecosystem as a whole, and why these make for such an exciting time to be writing PHP on the backend.