Yesterday, Symfony, a community of 600,000 developers from more than 120 countries, announced that it will no longer be a member of the PHP-FIG, a framework interoperability group. Prior to Symfony, the other major members to leave this group include, Laravel, Propel, Guzzle, and Doctrine.
The main goal of the PHP-FIG group is to work together and maintain interoperability, discuss commonalities between projects and work together to make them better.
Why Symfony is leaving PHP-FIG
PHP-FIG has been working on various PSRs (PHP Standard Recommendations). Kévin Dunglas, a core team member at Symfony, said, “It looks like it’s not the goal anymore, ’cause most (but not all) new PSRs are things no major frameworks ask for, and that they can’t implement without breaking their whole ecosystem.”
PHP-FIG is **not** about interoperability anymore, it's about creating an opinionated framework, a framework by committee…
— Fabien Potencier (@fabpot) November 20, 2018
The fact that the major contributors left the group could possibly be a major reason for Symfony to quit. But it seems many are disappointed by this move of Symfony as they aren’t much satisfied by the reason given.
still, I don't think that leaving the PHP Fig will fix the issue, this will probably make things worse, isn't it?
— Mickaël Andrieu (@mickael_andrieu) November 20, 2018
The matter of concern for Symfony was that the major projects were not getting implemented as a combined effort.
PSR-7 cannot be used by SF HttpFoundation, the tool used by most projects for HTTP messages, including Laravel (the most popular framework out there), PSR-6 cannot be implemented by Doctrine Cache, the tool used by most projects back in the days, same issue for PSR-14…
— Kévin Dunglas (@dunglas) November 20, 2018
Laravel, Doctrine and now Symfony are out. What's the point of a "framework interoperability group" with most big players leaving because they cannot change the state of affairs, and cannot implement the new "standards".
— Kévin Dunglas (@dunglas) November 20, 2018
Something similar happened while working towards PSR 7, where no commonalities between the projects were given importance. Instead, it was considered as a new separate framework.
So it's not about interop at all if it's not to allow major tools to be able to work together. It's a new way. It can be a good way (IMHO, it's not) but unlike PSR-1/2/3/4 its not about the interoperability between bricks of different frameworks.
— Kévin Dunglas (@dunglas) November 20, 2018
Exactly. Instead of getting the common denominator from actual current frameworks, a whole new interface was built from nowhere. That's not how you get interop.
— Titouan Galopin (@titouangalopin) November 20, 2018
People are still arguing over why Symfony quit.
It is problem of symfony that does not want to adjust… symfony is the one that has as a golden rule "no breaking changes" and every major update it's only the removal of it's deprecation layer.
— Mponos George (@gmponos) November 20, 2018
Will the PSRs die?
With the latest move by Symfony, there are various questions raised towards the next step the company might take. Will the company still support PSRs or is it the end for the PSRs?
Kévin Dunglas has answered to this question in one of his tweets, where he said, “Regarding PSRs, I think we’ll implement them if relevant (such as PSR-11) but not the ones not in the spirit of a broad interop (as PSR-7/14).”
To know more about this news, check out Fabien Potencier’s Twitter thread
Read Next
Perform CRUD operations on MongoDB with PHP
Introduction to Functional Programming in PHP
Building a Web Application with PHP and MariaDB – Introduction to caching
