Does PHP Have A Future, Or Are Twenty Five Years Enough?

In June, 1995, Rasmus Lerdorf made an announcement on a Usenet group. You can still read it.

Announcing the Personal Home Page Tools (PHP Tools) version 1.0.

These tools are a set of small tight cgi binaries written in C.

Today, twenty five years on, PHP is about as ubiquitous as it could possibly have become. I’d be willing to bet that for the majority of readers of this article, their first forays into web programming involved PHP.

But no matter what rich history and wide userbase PHP holds, that’s no justification for its use in a landscape that is rapidly evolving. Whilst PHP will inevitably be around for years to come in existing applications, does it have a future in new sites?

Before we look to the future, we must first investigate how PHP has evolved in the past.

The Beginnings

Rasmus Lerdorf initially created PHP as a way to track users who visited his online CV. Once the source code had been released and the codebase had been re-written from scratch a sizeable number of times, PHP was enjoying some popularity, reportedly being installed on 1% of all domains by 1998. At this point, the language looked nothing like we know today. It was entirely written within <!-- html comments -->, with syntax noticeably different to modern versions.

Enter Zeev Suraski and Andi Gutmans, who were using PHP to try to build a business but found it lacking in features. Collaborating with Rasmus, PHP was once again re-written and released as PHP 3.0. Now we’re getting somewhere, with PHP 3 installed on an estimated 10% of domains at the time. This is also the point where the meaning of PHP changed from Personal Home Page to everyone’s favorite recursive acronym, “PHP: Hypertext Preprocessor”. This version and period is generally seen as the time in which PHP cemented its future status. Between PHP 3 and 4, phpMyAdmin was created, Zeev and Andi mashed their names together and founded the PHP services company Zend, and the venerable elephant logo appeared.

The rest is history: shortly after PHP 4 came Drupal; in 2003 we got WordPress; then in 2004 along came a student at Harvard named Mark.

Facebook and PHP

Facebook famously started as a PHP site. But when thousands of users became millions, and millions were beginning to look like billions, there were growing pains.

In particular, PHP was (and still is) a scripting language. Great for developer productivity, not so great for resource efficiency. So in 2008, Facebook began work on HipHop for PHP, a transpiler. Very simply, it parsed PHP, transpiled it to C++, then compiled the resulting C++ into x64. This was no mean feat given that PHP is weakly-typed and dynamic. But the results speak for themselves: a 50% reduction in CPU load.

I’m sure you’re imagining the horror of working as a developer at Facebook using this process. Making a change to the PHP code, running the transpiler, then compiler, drumming your fingers, running the executable and finding the problem you need to go back and fix. That’s a pretty long iteration cycle, which is why Facebook also developed HPHPi, an interpreter that does the same job as the transpiler/compiler (HPHPc), but just to be used for development. As you can imagine, keeping the two projects in sync was an almighty headache, so in 2011 they developed HHVM, the HipHop Virtual Machine.

HHVM is a PHP runtime. It uses JIT (just-in-time) compilation to provide the best of both worlds. It’s pretty cool, and you can read more in Facebook’s own blog post if you’re interested. The next big step came in 2014, with the invention of Hack, a language specifically built for HHVM. It’s both a superset and subset of PHP, adding optional type annotations and extra features such as asynchronous architecture. It also helps make HHVM’s JIT more efficient by enabling it to optimise with confidence using the specified type hints. Soon, new code at Facebook was written in Hack, with existing code being converted over time. Both Hack and HHVM are open source, and actively maintained today.

Does the fact that Facebook found PHP in its native form unusable at scale mean that it’s a badly engineered language? No, I don’t think so. I don’t believe any of the options which were around at the time had been created for the scale or specifics which Facebook required. However, that doesn’t stop people using it against PHP.

The Hate

Within the wider software community, as PHP became larger it inevitably drew fire from a growing group of cynics. Except, PHP objectively speaking gets more hate than most other languages. According to the recent 2020 Stack Overflow Developer Survey, PHP is the sixth most dreaded language. Why?

I don’t want to get into technical minutiae here, but if you do, PHP: a fractal of bad design, is the bible blog post for PHP haters. Written in 2012, some problems it mentions have since been fixed but many haven’t. (eg: why is there no native async support in 2020?)

Stack Overflow 2020 survey of most dreaded languages

I think more general problems lie in the philosophy of the language. It’s a tool for a fairly narrow domain, implemented in a complex way. In an ideal world, if an application must be complex, the complexity should be visible to the developer in user code, not the language itself. You don’t need a complex tool to create complex projects. When I say PHP is complex, I’m not saying it’s hard for beginners to use (quite the opposite in fact), I’m saying it has inconsistent naming conventions and a lot of very specific functions, both make it easy to create errors which aren’t caught until runtime. But are these simply properties of PHP’s age, to be expected? Whilst perhaps a factor, it’s certainly isn’t the reason for the hate. After all, Python was created in 1989, six years before PHP, and comes in as the 3rd most loved language in the Stack Overflow survey, as well as being one of the fastest-growing languages today.

When it comes to security, there’s some debate as to whether the above-average number of vulnerabilities on PHP sites are the fault of the language or the site developers. On the one hand, a coding language designed to appeal to a broad range of people including non-programmers, who produce sites with code hacked together from decades-old tutorials will always have issues, no matter the merit of the language itself. On the other hand, PHP has attempted to fix basic security issues in questionably convoluted ways, for example fixing SQL injection first with escape_string(), then fixing vulnerabilities with that by adding real_escape_string(), then adding addslashes(), mysql_escape_string(), pg_escape_string() and so on. Add this to its labyrinthine error/exception handling (yes, errors and exceptions are different), and it’s easy to make mistakes if you’re not well versed in the nuances of the language. The amount of sites running old, unsupported versions of PHP past their End Of Life continues to be staggeringly large, so PHP sites will continue to be low-hanging fruits for hackers for years to come.

Be this as it may, I’m not convinced that the problems the language has are as large as many would make out. Despite there being reasonable grounds for complaint about PHP, it seems to me that much of the stigma is absorbed because it’s fashionable, rather than reasoned by individuals.

The Future

This author is well aware of the irony of typing critiques of the language into a page with post.php in the address bar. But this isn’t about existing sites. I don’t think even the most ardent pitchfork mobs would suggest that we re-write all existing sites made with PHP. The question is, in June 2020, if I want to create a new website, should PHP be an option I consider?

There is no doubt that the current web development trends are setting a course for Single Page Applications – where your browser never reloads, but navigations occur from Javascript re-rendering the page using data from lightning-fast API calls (eg: browsing GitHub or Google Drive). There is an ever-growing ecosystem of Javascript libraries, frameworks, and tools for building reactive and performant applications in the browser — React and Vue being the most popular.

Ultimately, PHP is for server-side rendering. That’s fine for most sites and the best option for many. But if you’re building something new in 2020, you have to accept that this brings limitations. And whilst PHP-style server-side rendering isn’t dead (did everyone forget about SEO?), modern sites are likely to be Isomorphic, that is, able to render the same Javascript on server and client, using frameworks such as Next.js (for React) or Nuxt.js (for Vue), putting PHP out of business on the server.

But we can’t ignore the fact that PHP is evolving too. Laravel, self-publicised as “The PHP Framework for web artisans”, provides an MVC architecture for creating PHP applications safely and quickly. It’s held in high esteem by the community, and enjoys active and rapid development. Additionally, PHP 8 is coming out later this year, with a bunch of new features (many of which will look familiar from the Facebook section), such as a JIT, Union types, and improved errors.

So, happy twenty-fifth birthday PHP, you are endlessly quirky and will undoubtedly endure for many more years. You’ve empowered many people and played a key role in the rise of the web. But don’t be too upset if people are looking elsewhere for the future, it’s 2020 after all.