PHP is big. The trolls can proclaim its all-but-certain “death” until the cows come home, but no amount of heckling changes that the Internet runs on PHP. The evidence is overwhelming. What follows is a loosely organised collection of precisely that evidence.
The bulk of public sites build on PHP via a CMS. By market share, 8 of the 12 largest CMS softwares are written in PHP. The below is from CMS usage by W3 Techs, where each percent represents 100,000 of the top 10 million sites. There’s a similar CMS report by BuiltWith that analyses a larger set of 78 million websites.
Well, first off, it’s important to point out that there’s a big difference between “wanting” and “being”. People have been calling for the death of PHP […] as far back as 2011.
PHP 7.3 was pushing 2-3x the number of requests per second as PHP 5.6. And PHP 8.1 is even faster.
[…] Because of PHP’s popularity, it’s easy to find PHP developers. And not just PHP developers – but PHP developers with experience.
PHP hasn’t stopped innovating […]. A new wave of backend engineers planned how we might carve up 500,000 lines of PHP into a bunch of [services]. […] Ultimately none of the proposals took hold.
Vimeo had grown many times over in the ten years since 2004, and our PHP codebase along with it […]
Ars Technica tells us: PHP maintains an enormous lead. Ars published a version of the W3 Techs report that includes historical data.
Despite many infamous quirks, the server-side language seems here to stay. […] Within that dataset, the story told is clear. […] PHP held a 72.5 percent share in 2010 and holds a 78.9 percent share as of today. […] There doesn’t appear to be any clear contender for PHP to worry about.
Lex Fridman put it as follows in an interview with Python-creator Guido van Rossum on his podcast (episode, timestamp):
Lex: “PHP probably still runs most of the back-end of the Internet.” Guido: “Oh yeah, yeah. […]”
Daniel Stenberg’s annual Curl user survey (page 18) asks where people use curl. After curl’s own interface (78.4%), the most familiar curl binding is PHP. It has been, since the survey’s beginning in 2015. In 2023, 19.6% of curl survey respondents reported they use curl via PHP.
Ember.js famously originated from the Ruby community. But, as a frontend framework Ember can pair with any backend. The Ember Community Survey reports PHP as the third-most favoured among survey participants, after Ruby and Java.
The Ember survey also asked general industry questions. For example, 24% described their employer’s infrastructure as “self-hosted”, and not at a major cloud provider. This isn’t a representative survey per-se, but may still be a surprise. Especially for folks who rely on social media and conference talks for their sense of what businesses do in the real world. It is more important than ever for companies to have a cloud exit strategy ready (NHS example). You can read how Basecamp’s cloud exit saves them millions of dollars a year.
PHP at scale
The stats cited above measure the number of distinct sites and companies. The vast majority of those build on PHP. But, all that says about their scale is that they’re somewhere in the top 10 million. Does that worry you? What’s in the top 500?
Laravel
Jack Ellis from Fanthom Analytics in Does Laravel Scale? makes the case that you shouldn’t make choices based on handling millions of requests per second. You’re not likely to reach that, and will face many other bottlenecks. But, it turns out, PHP is one of the languages that does scale to that level.
When we started seeing incredible growth in our software, Fathom Analytics (which is built on Laravel), […] never had moments of “does the framework do enough requests per second?”. […]
I’ve worked with enterprise companies using Laravel to power their entire business, and companies such as Twitch, Disney, New York Times, WWE and Warner Bros are using Laravel for various projects they run. Laravel can handle your application at scale.
Slack uses PHP for most of its server-side application logic […].
the advantages of the PHP environment (reduced cost of bugs through fault isolation; safe concurrency; and high developer throughput) are more valuable than the problems […]
Let’s take another look at the W3 Techs report, and this time focus on the size of some single businesses. At the top, we have WordPress which of course powers Automattic’s WordPress.com. That’s 20 billion page views each month (Alexa rank 55 worldwide).
If we move further down the report, to entries with 0.1% market share, we find PHP systems that power massive websites. Yet, these are also the platform of choice for over 100,000 smaller websites.
Other major Internet properties powered by PHP include Facebook (Alexa #7), Etsy (Alexa #66), Vimeo (Alexa #165), and Slack (Similarweb #362).
Etsy is interesting due to its high proportion of active sessions and dynamic content. This unlike Wikipedia or WordPress, which can serve most page views from a static cache. This means despite a similar scale, Etsy’s PHP application is a lot more exposed to their high traffic.
Etsy is also where PHP-creator Rasmus Lerdorf is employed. He sometimes features snippets from Etsy’s codebase in his tech talks. (Geek side note: His 2021 Modern PHP talk explains how Etsy deploys with rsync, exactly like Wikipedia did for the past decade with Scap). Etsy’s engineering blog occasionally covers work on their modular PHP monolith, e.g. Plural localisation, or their detailed Etsy Site Performance reports:
Happily, this quarter we saw site-wide performance improvements, due to our upgrade to PHP7.
[…] we saw significant performance gains on all our pages.
What about my bubble?
One could critique the PHP community for not occupying much space in public discourse. Whether PHP core developers, or authors of PHP packages (like Laravel, Symfony, WordPress, Composer, and PHPUnit), or the average engineer using it in their day job… we’re not seen much in arguments on social media.
You also don’t see us give many conference talks prescribing formulas for a stack that will “definitely be better” for your company. If talks by fans of certain JavaScript frameworks are anything to go by, we should believe that most companies use their stack today, and that you should feel sorry if you still don’t. I don’t say that to judge JavaScript. What bothers me is prescriptive messaging without considering technical or business needs, without assessing what “better” means — better compared to what? It’s hard to compare the one thing you know.
The above isn’t to say JavaScript doesn’t have its place. Share your experience! Share your results (and the benchmarks behind them), what worked, what didn’t. Keep searching, keep innovating, keep sharing, and above all: keep pushing the human race forward. That’s free software!
One could question merits through the lost decade and critique on React, but… React holds a 3% market share. Add the smaller frameworks (Vue, Angular, Svelte) and we reach a sum of 5%. Similarly, Node.js as web server holds 3% market share. Does that mean over 90% missed out on This One Trick That Will Boost Your Business?
Lest we forget, this 5% represents 500,000 major websites. That’s huge. Node.js has its place and its strengths (real-time message streams). But, Node.js also has its weaknesses (blocking the main thread). And remember, market share doesn’t say much about scale. It could be powering several organisations in the top 1% (like MediaWiki), or the bottom 1%. Or, be WordPress and power both the top 1% and over 40 million other sites.
Conclusion
Companies young and old, small and big, might not be utilising the software stacks we hear talked about most in public spaces. This is especially true outside the bubble of personal projects and cash-burning startups.
Is PHP the most economic choice for growing and sustained businesses today? Is it in the top three? Does language runtime matter at all when scaling up a business and team of people around it? We don’t know.
What we do know is that a great many businesses today build on PHP, and PHP has proven to be a sustainable option. It stood the test of time. That includes new companies like Fathom that turned profitable in just three years. Like the Fathom article said, most of us will never reach that scale. But, it’s comforting to know that PHP is a sustainable and economical option even at scale. Is it the only option? No, certainly not.
There are languages that are even faster (Rust), have an even larger community (Node.js), or have more mature compilers (Java); but that tends to trade other values.
PHP hits a certain Goldilocks sweetspot. It is pretty fast, has a large community for productivity, features modern syntax, is actively developed, easy to learn, easy to scale, and has a large standard library. It offers high and safe concurrency at scale, yet without async complexity or blocking a main thread. It also tends to carry low maintenance cost due to a stable platform, and through a community that values compatibility and low dependency count. You will have different needs at times, of course, but for this particular sweetspot, PHP stands among very few others. Which others? You tell me!
Update (6 Sep 2023): Regarding HHVM, Wikipedia and Etsy indeed both tried it as PHP5-compatible alternative runtime (no Hacklang). After performance improvements in PHP 7, Wikipedia reverted its roll out and upgraded to PHP 7.2. Etsy also abandoned the experiment and partial use and similarly moved to PHP 7, stating later: “hhvm was a catalyst for performance improvements that made it into PHP7. We are now completely switched over to PHP7 everywhere“.
In GitHub, pull requests are synonymous with feature branches. So
it’s tempting to cram commits into a branch until it’s feature-complete,
then push for review:
GitHub flow: a local feature branch
becomes a review with three commits
But this is an anti-pattern—you’ve created a monster pull request for
someone to review.
Compare the same local branch pushed into a stacked patches
system:
Stacked patches flow: a local feature
branch becomes three reviews with one commit each
Each commit is reviewed independently in a stacked patches system,
regardless of how you work locally.
Each review is a small delta—fewer changes for the reviewer to think
about.
And changes are “stacked,” so:
Commit “C” must merge before commit “D”
Commit “C” may merge before “D” is reviewed
Commit “D” may be a work-in-progress when you push commit “C” for
review
Patch stacks are like suggestions for maintainers. They may overrule
you, rearranging your patches, or cherry-picking a single change.
This is a feature. Better to get some changes merged than blocked on
the all-or-nothing approach of feature branches.
😖 Integration pain
What’s worse than a huge review? Two. Especially when they have merge
conflicts.
This is integration pain.
And it’s easy to create with big feature branches.
GitHub long-lived feature branches
resolve conflicts long after they’re created, resulting in lots of
rework
The illustration above shows two developers each working on their own
big features: Alice and Bob.
Both features required refactoring the same class. This created a
conflict.
But no one noticed the conflict until weeks later when they went to
merge.
Stacked patches make it easier to catch the same situation
earlier:
Stacked patchsets catch conflicts when
they happen, resulting in less rework
Now, each commit is a separate review. Instead of waiting until their
feature is complete, Alice and Bob spotted the conflict right when it
happened. Less refactoring for Bob.
Continuous integration of changes into main means each
change is smaller, which means integration is less painful.
🚧 You can do this with pull
requests!
It’s possible to make small pull requests.
But GitHub isn’t making it easy.
Developers hacking away at ginormous feature branches is the root of
all the problems I outline above.
And that’s precisely where “GitHub Flow” steers you:
Ideally, each commit contains an isolated, complete change. […]
Continue to make, commit, and push changes to your branch until you are
ready to ask for feedback.
Log in
![[after a minute] "Okay, I think I've got it, thanks. Can I--" "oOOOooOOooo!"](https://imgs.xkcd.com/comics/a_halloween_carol.png "[after a minute] \"Okay, I think I've got it, thanks. Can I--\" \"oOOOooOOooo!\"")
