The Kinsta blog has published an article they call the Definitive PHP 5.6, 7.0, 7.1, 72. and HHVM benchmarks providing a comparison between these different versions running different popular PHP software (including WordPress, Drupal and Magento 2).

Each year we try and take a deep dive into performance benchmarks across various platforms and see how different versions of PHP and HHVM stack up against each other. This year we went all out and benchmarked four different PHP engines and HHVM across 20 different platforms/configurations; including WordPress, Drupal, Joomla!, Laravel, Symfony, and many more. We also tested popular eCommerce solutions such as WooCommerce, Easy Digital Downloads, Magento, and PrestaShop.

[...] The results this year have drastically changed from our previous benchmarks where HHVM was the winner. We now are excited to see PHP 7.2 as the leading engine in terms of speed. [...] This is great news for developers and end-users alike as it means more of a focus back on PHP and providing faster websites and web services for everyone.

The post then starts with a look at the system setup (well, Google Cloud instance) that's used for the testing and how it is configured. From there it goes into the test results from each of the different types of software:

• WordPress
• Drupal
• Joomla!
• Magento 2
• Grav CMS
• October CMS
• Laravel
• Symfony
• PyroCMS
• Pagekit
• Bolt
• AnchorCMS
• PrestaShop
• CraftCMS
• ForkCMS

As you can see there's more of a leaning towards content management and e-commerce solutions in their list. It's good to see base frameworks in the list too, however. For each item in the list they provide a graph of the results showing requests per second.

The HHVM project has made an announcement on their site about the latest update for the PHP language processor, v3.24 and how, among the list of changes, they're completely dropping support for PHP 5.

HHVM 3.24 is released! This release contains new features, bug fixes, performance improvements, and supporting work for future improvements. [...] 3.24 is the final release targeting PHP5; this includes source-level compatibility for PHP5 extensions (ext_zend_compat). We recommend migrating to Hack or PHP7.

As 3.24 is supported though 2018-12-17, this means that support will end at roughly the same time as PHP5 itself is scheduled to become unsupported (2018-12-31).

Other updates in the release include the retiring of support for Debian 7 Wheezy and Ubuntu 17.04 Zesty, the inclusion of "using" blocks and the addition of the XHP Attribute Spread Operator. You can find out complete details about this release from the HHVM blog.

The HHVM project (an alternative PHP runtime from Facebook) has made a major announcement on their blog - beginning with version 3.24 they'll no longer be trying to keep parity with the PHP language now that it has moved into PHP 7.

The HHVM team is happy about the direction PHP has taken with PHP7, and we’re proud of the role we’ve played in pushing the language and runtime to where they are today. Since the PHP community is finally saying goodbye to PHP5, we’ve decided to do so as well.

Our next LTS release, 3.24, will be cut about four months from now and will receive support for one year thereafter. It will also be the last HHVM release that commits to PHP5 support. This aligns with PHP’s own timeline of sunsetting PHP5 at the end of 2018.

[...] PHP7 is charting a new course away from PHP5, and we want to do the same, via a renewed focus on Hack. Consequently, HHVM will not aim to target PHP7. The HHVM team believes that we have a clear path toward making Hack a fantastic language for web development, untethered from its PHP origins. We’d do ourselves and our users a disservice by positioning HHVM as an uncommon, less well-documented, less compatible PHP7 runtime.

The post then lists out some of their goals for the HHVM/Hack projects moving forward including reinvesting in open source and staying focused on their needs for the platform and language. It then talks about some of the upcoming changes you can expect around support of current versions of popular PHP tools and work on tools created specifically for Hack.

On the Zend Framework blog Matthew Weier O'Phinney has a new post covering the state of the Zend Framework project and how it relates to PHP 7.1.

When we announced Zend Framework 3 last year, one of the changes was setting the minimum supported PHP version to 5.6. Our initial plan was to support 5.6 until it reaches end-of-life, which occurs 31 December 2018.

PHP 5.6, however, stopped receiving active support almost five months ago, on 19 Jan 2017. This means that it is no longer receiving bugfixes, only critical security fixes. As such, a number of contributors have been pushing for us to up our minimum supported version to support only actively supported PHP versions, which would mean only PHP 7 versions.

[...] Our view is that the new features in PHP 7 will allow us to simplify our code dramatically, reduce bugs (primarily by increasing type safety), make our code more easily maintainable (less code required to check types; less repetitive code), provide stronger and more predictable interfaces to our users, and simultaneously provide users access to more and better language features.

He also talks briefly about their thoughts about HHVM support and if it makes sense to keep moving forward with it (given the small percentage of their user base). He then lays out a plan for the framework moving forward that includes the release of PHP 7.1+ only components and security patches on 5.6 versions until end of life.

Derick Rethans has a post on his site with an update about the MongoDB driver for HHVM - mostly that, because of feedback he received, it will no longer be maintained.

At the start of 2015 we began work on an HHVM driver for MongoDB, as part of our project to renew our PHP driver. Back then, HHVM was in its ascendancy and outperforming PHP 5.6 two to one. With such a huge performance difference it was reasonable to assume that many users would be switching over.

[...] With PHP 7 released, we saw very little use of the HHVM driver for MongoDB. Some months ago I did a twitter poll, where very few people were indicating that they were using HHVM—and even if they were, they would likely not choose to switch to HHVM given the current climate.

He includes some of the responses in his post ranging from people saying that HHVM only "masked slow code" for them. Another mentioned that, while Hack has some nice features, PHP moves on and integrates some of these ideas anyway. As a result of this disinclination towards HHVM on new development and the low adoption of the HHVM MongoDB extension, it will no longer be maintained. If you're a user and are interested in keeping development going, contact Derick for more information.

Fred Emmott has a new post to his site sharing some of his experience with creating a "greenfield" project in Hack, the language Facebook developed to work with its HHVM runtime for PHP.

Until late 2015, the Hack and HHVM documentation site was a fork of PHP's own documentation site. This had many shortcomings, and ultimately we decided that the best approach would be something custom. As most of the public Hack code at that point was toy examples, we decided to also make the site itself open, and start investigating the greenfield problems.

There are 3 basic approaches to 'library code' in Hack if there isn't already a Hack version:

• Use a PHP library, without typechecker support
• Use a PHP library, and add HHI files so that Hack understands it
• Write something new

The Hack/HHVM site uses a mix of all three, though mostly #2 and #3.

He talks some about using plain PHP libraries in Hack projects and how you won't get the full benefit of Hack's features without some of the type-checking enforced (sometimes required to get some libraries working). Following this he covers the integration of three projects/structures, changed a bit for supporting Hack: FastRoute, PHPUnit and the things based on the PSR-7 request/response structure. He wraps up the post talking about writing "something new" and things to consider to make its APIs more "Hack-like".

On the Slack Engineering blog there's a new post from one of their engineers talking about a choice the company made about their platform - they decided to take PHP seriously. In this post author Keith Adams talks about why they chose PHP and what kind of experiences they've had with it in their own environment.

Slack uses PHP for most of its server-side application logic, which is an unusual choice these days. Why did we choose to build a new project in this language? Should you?

PHP-the-language has many flaws, which undoubtedly have slowed these efforts down, but PHP-the-environment has virtues which more than compensate for those flaws. And the options for improving on PHP’s language-level flaws are pretty impressive. On the balance, PHP provides better support for building, changing, and operating a successful project than competing environments. I would start a new project in PHP today, with a reservation or two, but zero apologies.

He starts with some background on the history of PHP itself, where the language came from and what kinds of issues it tries to mainly solve. He then gets into some of what he sees are the "virtues of PHP" including the blank slate at the start of every request, one-request-one-process concurrency and the fast programmer workflow. He then gets into the "bad stuff" they've found when working with PHP, things like surprise type conversions, a "failure-oblivious philosophy" and inconsistencies in the standard library. Finally he looks into two options (created by Facebook to improve its use of PHP) - HHVM and the Hack language - and how it was integrated into their environment.

On the SitePoint PHP blog Younes Rafie asks the question "Can we have static types in PHP without PHP 7 or HHVM?" One of the main features introduced by both of these versions (or platforms) is the ability to type things strictly and enforce more correct data handling. Previously PHP has been a "lazy typing" language and would regularly shift the type of a variable depending on the immediate need. Obviously, this can lead to unpredictable behavior.

Now that PHP 7 has been out for a while with interesting features like error handling, null coalescing operator, scalar type declarations, etc., we often hear the people still stuck with PHP 5 saying it has a weak typing system, and that things quickly become unpredictable.

Even though this is partially true, PHP allows you to keep control of your application when you know what you’re doing.

They show how, through a series of examples, to add a bit of additional validation with exceptions to ensure the input is the correct type. However this can be a bit more time consuming and difficult to remember so the team at Box put together the augmented types extension that brings some of the static typing to PHP 5.x. They help you get it installed and working in your PHP installation and include an example of it in use with DocBlock-based type hints. The extension provides handling for the basic types as well as arrays, multiple arguments, default values and return types.

Derick Rethans has posted the next part of his series looking at the new an improved MongoDB drivers for PHP in this post to his site. This time he focuses on the updates to cursor behavior from the previous versions.

We released a new version of the MongoDB driver for PHP (the mongodb extension) near the end of last year. In a previous blog post, I covered the back story of the how and why we undertook this effort. And in another post, I spoke about the architecture of the new driver. In this episode I will discuss changes in cursor behaviour.

I recently found the following comment added to the driver's documentation, on PHP.net, which read: "I noticed that ->sort is missing from the cursor. Seems like the old driver has more functionality."

The new driver certainly allows for sorting of results of queries, but no longer by calling the sort() method on the cursor object. This is because cursors are now created differently than in the old mongo extension.

He starts by talking about how the legacy driver handled its cursor functionality and when it actually performed the data lookup (hint: not until used). In the newer drivers the cursor request is made when the object is created. Because of this change, actions like "sort" and "skip" have to be sent as options on the query instead.

Derick Rethans continues his look at the latest version of the MongoDB drivers for both PHP and HHVM with this look at their architecture and how it's different from previous versions.

We recently released a new version of the MongoDB driver for PHP (the mongodb extension). This release is the result of nearly a year and a half of work to re-engineer and rewrite the original MongoDB driver (mongo). In the previous blog post, I covered the back story of the how and why we undertook this effort. In this new blog post, I will talk about the architecture of the new driver.

He uses the goals stated at the end of his previous post and covers:

• Support for Other PHP Engines like HHVM
• [How/Why] The Driver Should Be Bare Bones
• No Reinvention of the Wheel
• Provide an Easy to Use API
• Backwards Compatibility

From there he then gives an overview (complete with a handy graphic) of the overall MongoDB PHP ecosystem and where the extensions fit in the plan.