I’m going to be honest: I was going to write a blog post about being a polyglot, how my year has been while branching out from PHP, and to encourage the community to stop being toxic about other technologies and communities, but Lorna beat me to it.
Instead, I want to flip it on its head a little bit. I gave a keynote at PHPConf.Asia earlier this year that, quite frankly, didn’t go over well (in my opinion) and left me feeling like I failed to deliver the message I wanted to give. I’m going to try and clarify what I wanted to say here.
By some metrics, and if you listen to the haters, PHP is a dying language. JavaScript is the “future of the web”; single page applications, JavaScript everywhere. And yet, per the same stats, JavaScript is also declining (source). And while new languages such as Rust and Golang seem to be surging in popularity, compared to any older language they barely register on the scale.
Meanwhile, PHP still maintains an 82% majority share of the web, and WordPress dominates in the content management space with 27% market share. If that weren’t enough, the top four CMSs are all written in PHP, totaling 34% (source).
We’ve also had at least two releases of PHP a month since February 2012. As a community, we are definitely doing something. In fact, we’ve added more than forty notable features since PHP 5.4 (inclusive).
But this only tells you about the language, and frankly, even if there had never been another release after PHP 5.3, we as a community have grown and matured immensely since then.
Last month marked the second time we’ve had more than 200,000 packages installed from Packagist (243K in fact, up from 186K when I gave this talk in August!), and there are over 119K packages available now (source).
We have more — active, healthy, and well maintained — opinions on building software (otherwise known as frameworks) than you can shake a stick at.
And yet, this idea that PHP is dying, or dead, still pervades the greater tech community. This is nonsense, and we owe it to ourselves, and our community, to combat this message.
I have had to defend my choice of language many times over the last few years, and it’s easy to do, thanks to the work of the community. We have a mature object model, a language spec, an amazing package manager, the best documentation, and more besides.
Choosing to use PHP does not make you a bad developer, and you should be proud of the things you accomplish with the tool rather than the tool you chose.
As a community we can do one thing better than any other: build the web at scale. We must get out into the wider technical community and spread our knowledge. I’m not calling on you to prosthelytize PHP, I’m asking you to take the knowledge you have and apply it to other languages.
PHP has always been a glue language. Everything we glue together has nothing to do with the language we’ve chosen. Things like using Varnish for caching, using Cassandra for sessions, building good relational database schemas, effectively using NoSQL datastores, and building work queues with ZeroMQ.
While we should continue to do this, we also have a responsibility to look to the future.
HTTP/2 The Future of the Web is Coming
If you follow me online at all, you’ll know my last year has been focused primarily on HTTP/2, so there’s no way I could not mention it in this post.
I truly believe that HTTP/2 has massive potential to change the way we build the web of tomorrow. Multiplexing and Server Push, alongside weighting and dependencies, mean the architecture of delivering assets of HTTP is going to need to be much more considered, and drastically different, to take advantage of the performance benefits made possible by HTTP/2.
But even if every other language except PHP embraces HTTP/2, the best we can do is improve 18% of the web.
This is why the PHP community needs to take a leading role in the adoption of HTTP/2. We need to experiment to create best practices. We need to deploy it and measure it. Above all else, we need to embrace what it means for us as application developers.
PHP as a language, unfortunately, just isn’t built for multiplexed responses, and we currently dodge this by pushing the responsibility up to the HTTP layer using Link headers.
But this will only get us so far. We need to work with the HTTPd vendors and the internals team to figure out how to communicate between the two in a way that allows for multiplexing. As I’ve said before, we need a new SAPI (thanks for the inspiration Jack!) and we need to rethink how we architect our applications.
You should get involved in efforts to figure this stuff out.
We owe it to the web to lead. Do you want to do your bit?