Why do we need Symfony Polyfill (… and why we shouldn’t)

Sebastian Luczak

PHP Unit Leader

In the following article, we explain how Symfony Polyfill works and how it relates to Symfony projects. We will also dive deeper into the idea that this library tries to solve.

In most modern PHP projects, you’ll notice a heavy dependency on the Symfony Polyfill library. In this article, we will explain not only how it works and how it relates to Symfony projects, but we will also go deeper into the idea of the problem it tries to solve.

Little bit of history

PHP was in a bad shape for quite a long time. It was 2005 when Andrei Zmievski started a project to bring native Unicode support for PHP due to mixed reviews and many concerns that PHP is going in the wrong way. Development of PHP 6.x started. But it was never finished – and that’s a story for another day. 10 years later, somewhere between 2014 and 2015, Dmitry Stogov, Xinchen Hui, and Nikita Popov started phpng – project that optimized and refactored the internal Zend Engine used by PHP.

>_ The PHP 7 was born

And for the past years, PHP is growing faster than ever, currently at stable version 8.1.

Due to the rapid development of new features in language not only developers had to adapt to those changes but also infrastructure and hosting service provides.

To ensure that we, developers, can use the newest and best features of our beloved programming language Symfony Polyfill project was born.

Symfony Polyfill and it’s function

This project backports features found in the latest PHP versions and provides compatibility layers for some extensions and functions. It is intended to be used when portability across PHP versions and extensions is desired.

This is a pure description of Symfony Polyfill but what does that mean?

Due to the rapidly evolving PHP language and the out-of-step software customization of ISPs, most developers have been faced with a simple choice:

As a developer, I create applications in an older version of PHP and cannot use the latest features of the language, or
As a developer, I create a modern application using the latest version of PHP.

But they had to maintain compatibility with other tools and services already used both on the code and infrastructure side – almost always using older versions of PHP.Do I need to mention, dear reader, the so-called ‘fun factor’ of these two solutions?

To ease the way for developers, the Open Source community in 2015 crafted the first stable version of Polyfill numbered 1.0. Developers’ lives became easier and one could say that Symfony Polyfill solved a multitude of problems such as code portability between different platforms, PHP version differences, and made refactoring applications and reducing technology debt much easier.

Unfortunately, not all problems can be solved by one tool.

Problems associated with maintaining multiple versions of the environment

For complex IT projects, maintaining different versions of environments for different customers/branches/departments is a common procedure. This results in the need to develop many different branches of applications at the same time, often with different functional requirements and with their own traction. I’ve faced many times the problem of maintaining the same application for different clients on different PHP5 / PHP7 environments and the multitude of problems related to the incompatibility of libraries or their dependencies for different versions is simply unsolvable using only Symfony Polyfill.

The skills gap between members of the development team

Due to the rapid growth of features built into PHP, many developers have not kept up with the pace of change. Many of the features offered in higher versions of PHP are easy to achieve with external libraries, or developers simply didn’t need the new features, such as PHP Fibers. When selecting team members, it’s a good idea to make sure that skills are matched or that the code delivery process is made more consistent by static analysis tools and early detection of version regression errors.

Reluctance to change

Adoption of new language features is still quite low and PHP 5’s over 24% share clearly shows that one-quarter of PHP projects are running versions lower than 7.x, which will have its security support terminated December 6, 2022. This means that at the time of writing this post, over 25% of PHP-based Web projects will be potentially vulnerable to all new security vulnerabilities by the end of the year. “If it works why should we bother”?

Conclusion

We should adapt to language changes as quickly as possible and use the latest solutions as soon as possible. During a possible migration of a Legacy project, it is worth including Symfony Polyfill as a helper and using techniques such as Strangler Pattern and the currently fashionable BDD methodology which is fabulously easy to apply to the Symfony framework. So are we really forced to use Symfony Polyfill?