A Case For Async PHP

As PHP developers, we’ve been conditioned to fear sockets. “PHP scripts should die quickly”; some say. Still others; “Why don’t you use Node for that?”.

The problem is that these arguments shut down any attempts to evolve core PHP, and the surrounding ecosystem.

Don’t get me wrong: PHP was not built to use an event loop. PHP was not built to be asynchronous. Any attempts to do these things are by definition going against what PHP was built to do. Yet many people think PHP can change to accommodate these tasks.

For starters, there’s ReactPHP. It’s a set of libraries which rely on extensions and a handful of core functions to emulate an event-loop. There are other things that React does, like Promises and Partial Function Application. But the focus is reactive programming and the event loop.

Then there’s Hack. It’s a superset of PHP (developed by Facebook), aimed at providing static typing. Additionally, Hack provides asynchronous language constructs. Let’s not forget that Facebook are writing the PHP language specification. They’re developing HHVM, which is the first major competitor to the traditional PHP interpreter. They are shaping the future of core PHP without needing to push code into core PHP.

Finally, modern PHP supports many asynchronous functions and extensions. It may not have begun with the event-loop, but there are signs that PHP wants to be [a little bit] asynchronous.

I am excited about asynchronous PHP. I’ve spoken about it and developed around it. What I want is for every PHP developer to explore the concepts and tools of asynchronous programming. To realise that it’s within our grasp, and that we can talk about it without feeling (or being made to feel) ashamed of PHP’s past or performance.

PHP might not yet be the best tool for the job, but if we don’t explore asynchronous PHP, it will never be the best tool for the job.