PHP Is Here To Stay: PHP 8 And Beyond
November 1, 2021 Mike Pavlak
In 2005, PHP ushered in the era of TRUE open source development on IBM i with version 5.3 of the language, thanks to the dedicated efforts of Zend and IBM Rochester. PHP had just gone through a major evolution and was taking the world by storm in the middle of the Version 5 phenomena.
Many IBM i developers were rapidly wrapping their heads around this wildly popular scripting technology with code stored in IFS files and Db2 data popping up on pages running directly on IBM i. Nearly every website on the web that was not HTML had some flavor of PHP and for good reason: it just works. Fast forward 15+ years and we see there are quite a few technologies vying for the attention of the development team and PHP is still doing the lion’s share of the heavy lifting. Let’s take a look at where PHP is today and where it looks to move in the near future.
Today, PHP runs 78.9 percent of the visible web according to W3techs. If you extrapolate that out by the number of websites on the net at 1.8 billion according to Statista, that rounds out at over a billion sites running PHP. With all that volume, something must be going right. But you might be saying to yourself, I bet a bunch of those are using older versions of PHP. Not so fast . . . W3techs has the skinny on that number, too – showing about 70 percent of the PHP sites are at PHP 7 and 30 percent are still running the trusted PHP 5 variants. That can’t be good, can it? Well, the obvious answer is, it depends.
IBM i has had a long-standing tradition of protecting a business’s investment in technology – meaning that very old versions of RPG can run on the newer hardware without issue. PHP, however, is not the same as RPG – but there are opportunities. Many folks are concerned because their network auditors have turned up an older version of PHP running within the environment. This is a good reminder to update to current PHP versions. There are several good reasons to do this that I will outline in the next few paragraphs, using the “carrot and stick” analogy to help amplify the urgency in each scenario.
Security – Here’s The First Stick
According to the folks at HelpSystems, security is the foremost concern of IBM i shops. There doesn’t seem to be a day that passes without some story of a company that was either hacked or bricked by ransomware. A survey by Statista identified that “68 percent of US organizations admitted to having experienced – and as a result paid the ransom for – ransomware attacks that year.” As a result, companies are really taking this quite seriously. PHP is a “perimeter” technology and as such tends to be the front line of defense against attacks on the server, just behind the webserver. Any exploit vector needs to be addressed, quickly and consistently. In the PHP community, one of the best ways to manage this is by updating the PHP stack as frequently as possible.
Performance – Arguably Carrot And Stick
It is important to keep in mind that raw performance of a single PHP script, side-by-side may not show a marked improvement to the naked eye. This is primarily due to the gradual slowing of Moore’s Law and the fact that the clock speed of processors has not gained much ground in the last few years. But what we can see is improvements in throughput and utilization of resources under load like significantly reduced memory utilization. For Linux implementations this can mean fewer servers, as illustrated in the case study of Badoo when they adopted PHP 7. For IBM i shops this means more memory and other resources for all the other applications that are keeping busy on the platform.
Pharonix, an independent firm focused on open source and Linux advocacy, recently published PHP performance statistics illustrating the consistent forward march of improved throughput and reduced resources. Since 30 percent of shops are still running a PHP 5 variant, this means everybody should benefit from improved performance, but clearly YMMV.
Features of PHP 7, 8, & Beyond: This Is All Carrot . . . But Braised in Caramel Sauce and Topped With Cinnamon
In addition to PHP 7 delivering stellar performance, there were a number of features introduced as well. A few of these include scalar type declarations, anonymous classes, return type declarations, and one of my personal favorites in constant array declarations via define(). It simply amazed me that after such a zealous focus on performance the core development team managed to sneak in a few of these goodies. What can be really attractive is that folks who had well-written code that was at a PHP 5.6 standard typically enjoyed a simple migration into the world of PHP 7+. But those who had bad habits entrenched in PHP 4 and earlier seem to struggle the most. This is no surprise and is one of the easiest examples of technical debt that we see in PHP migrations.
PHP 8 builds upon all the success of PHP 7 with a variety of updates. One in particular is the tempered behavior of the @ sign where it no longer silently suppresses certain errors. This is a good start, and we look forward to continued momentum in collectively witnessing the slow death of the most evil (but terribly useful) contraption that has been the bane of many a maintenance programmers existence for quite some time. Additional PHP 8 features include named arguments when calling methods and functions, constructor property promotion, match expressions, and much more. One interesting point about performance is illustrated by a single change in removing PHP 4 style constructors has yielded a 20 percent performance gain.
PHP 8 continues with even more features including a Just-In-Time (JIT) compiler and the ability to process requests asynchronously. Yes, one of the main features of one of those other languages is coming to PHP. I think this is a good time to reflect on the fact that jumping ship from one technology to another because of a single feature might be a little short sighted. I ran into many companies looking to abandon PHP for a language that supported asynchronous requests and found the grass was not all that green. Maybe because of overhyped expectations or possibly because the implementation is not as simple as some might expect. And now, this feature comes to PHP. Not necessarily because the language is trying to compete with other technologies, but more to the fact that PHP enjoys a very active development community who felt it’s time to bring in this feature.
27 Years And Just Getting Started!
PHP is really coming into its own with powerful stability and incredible new features. Letting PHP versions fall behind because of security is not a good idea, but when you add in the technical debt of maintaining older versions it can sometimes make getting current a significant task. Many companies simply do not have the time or resources to evaluate compliance with each annual major release of PHP, but that should not be an excuse for allowing the code base to stagnate. Perforce offers the only PHP Long Term Support which can extend production level support beyond the community level. This allows companies some flexibility in keeping up with the technical debt that can sometimes mire the development teams and extend the useful life of a significant PHP code base by offering protection.
But what if you just don’t have the cycles to “get current” with PHP? With Long Term Support editions for several PHP versions. Perforce extends the industry standard of three years by at least another two years, and often longer. This optional support provides organizations the flexibility to prioritize PHP migrations where they can best fit into organizational objectives. While staying current is always the best course of action, sometimes other priorities take precedent.
Mike Pavlak is a solution engineer at Perforce.
This content is sponsored by Perforce Software.