Symfony 4: End of HHVM support
Fabien Potencier
We started working on HHVM compatibility on December 2013. On July 2015, we proudly announced full support for HHVM. Symfony 2.3 and all other maintained Symfony branches were compatible. It was a long journey and it took us a lot of time to get there. We also got support from the HHVM team as they fixed bugs we weren't able to work around in Symfony.
Back then, the most attractive selling point of HHVM compared to PHP was performance. HHVM was way faster than PHP. But soon enough, the PHP team embarked on a quest to find ways to drastically improve the performance of PHP. PHP 7 was born. Nowadays, the performance difference between HHVM and PHP is not significant anymore.
After a poll on Twitter, we have decided to drop support for HHVM as of Symfony 4.0. Results show that HHVM adoption is very low in the Symfony community (less than 4% said they were using HHVM and wanted it to be supported by Symfony).
But if Symfony supports HHVM today, why do we want to remove it in 4.0? If HHVM
and PHP were equivalent (same features, same bugs, same behaviors, ...), that
would not be a problem. But the reality is very different. Some PHP 7+ features
are not (yet) available in HHVM. Symfony's code has quite a few workarounds for
HHMV. Nobody in the extended core team uses HHVM. But more importantly, when we
decided to bump the minimum PHP version to 7+ in composer.json, we realized
that there were no way to make our tests pass. The first blocker is that even
Composer is not compatible with
HHVM when using PHP 7. And the issue was created about a year ago. I knew it as
I tried to make it work back when I was about to release Twig 2.0 about 6
months ago. Nothing changed. It looks like PHP compatibility is not much of a
priority anymore for the HHVM team.
Given the low adoption, compatibility issues, insignificant performance differences, we had no choices but to officially drop support for Symfony 4.
We will keep HHVM workarounds in Symfony 3.4 though, which means that projects using HHVM will still be able to use HHVM with Symfony until November 2020 (three years from now as 3.4 is a LTS version). That gives plenty of time to migrate away from HHVM or Symfony.
Symfony is not the first PHP project to drop HHVM support. Doctrine, CakePHP, and MongoDB dropped or will soon drop HHVM support (as commented on the Twitter poll). Laravel also dropped support as of version 5.3 (released 9 months ago). I can imagine that more PHP libraries will drop support as they will face the same issues as Symfony when requiring PHP 7.
That's also why I have decided to drop HHVM support for all my other significant projects like Twig (as of version 2), Silex, and Swiftmailer.
I have also created a pull request on the HHVM repository to remove my projects from the HHVM compatibility test matrix as we don't want people to think that Symfony is still compatible with HHVM while it's not properly tested. It is even more important as tests run on an old and unmaintained Symfony version (2.4.8). I think other projects should do the same to avoid confusion.
Help the Symfony project!
As with any Open-Source project, contributing code or documentation is the most common way to help, but we also have a wide range of sponsoring opportunities.
Comments
Comments are closed.
To ensure that comments stay relevant, they are closed for old posts.
When starting a new project, we had looked into HVVM some time ago. However, as the performance benefit is minimal compared to PHP7, we decided to stick with PHP7.
I hope, the community will understand and support your decision.
We must, however, appreciate HHVM and the role it played the last few years. I believe that HHVM gave us PHP7. Without a strong competitor (both performance and community) we would not have PHP7 as we know it today.
If the HHVM team made the projet grow faster and follow PHP7 compatibility, maybe HHVM support wouldn't have had to be dropped :/