department of hack
1780 stories

An Internet of PHP

1 Share

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.

  1. Statistics
  2. Anecdotes
  3. At scale
  4. What about my bubble?
  5. Conclusion


PHP as programming language of choice

From Language analysis by W3 Techs on the top 10 million websites worldwide:

  1. PHP at 77.2%.
  2. ASP at 6.9%.
  3. Ruby at 5.4%.

Content management on PHP

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.

WordPress logo
  1. [PHP] WordPress ecosystem (63% of CMS-based sites, 43% of all sites)
  2. [Ruby] Shopify
  3. Wix
  4. Squarespace
  5. [PHP] Joomla ecosystem (3%)
  6. [PHP] Drupal ecosystem (2%)
  7. [PHP] Adobe Magento (2%)
  8. [PHP] PrestaShop (1%)
  9. [Python] Google Blogger
  10. [PHP] Bitrix (1%)
  11. [PHP] OpenCart (1%)
  12. [PHP] TYPO3 (1%)

E-commerce on PHP

From BuiltWith’s report on online stores, as of Aug 2023:


Kinsta published a retort demonstrating that PHP is fast, lively, and popular:

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.

Matt Brown from Vimeo Engineering in It’s not legacy code — it’s PHP:

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.

curl (CLI) 78.4%, php-curl 19.6%, pycurl 13%, […], node-libcurl 4.1%.

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.

Ember Survey 2022 results:
First 29.9% Rails (Ruby).
Second 14.3% Spring (Java).
Third 7.6% PHP.
Fourth 6.5% Express (Node.js).

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 logo

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.

Matt Brown again, from Vimeo Engineering in It’s not legacy code:

I’m here to tell you that it can, and Vimeo’s continued success with PHP is proof that it’s a great tool for fast-moving companies in 2020.

Vimeo is also known as the developer of Psalm, a popular open-source static analysis tool for PHP.

From Keith Adams, Chief Architect at Slack Engineering in Taking PHP Seriously:

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 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.

MediaWiki is the platform behind with 25 billion page views a month (Alexa #12). MediaWiki also powers Fandom with 2 billion page views a month (Similarweb #44), and WikiHow with 100 million monthly visitors (Alexa #215).

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.


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!

Further reading

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“.

This post appeared on Reply via email

Read the whole story
1 hour ago
Boulder, CO
Share this story

A case for stacked patches 📚


I’m wondering why you talk about “branches” at all. No such thing should exist.

– Linus Torvalds, 2005,

Git branches are hard to think about.

But “GitHub” forces you to think about branches. A lot.

Instead of futzing with GitHub’s feature branches, many big projects1 opt for a stacked patches workflow—the kind Gerrit and Phorge offer.

I can see compelling reasons why, I’ll focus on two:

  1. Slow review
  2. Integration pain

🐌 Slow review

Code review decision fatigue is real—big changes make for slow reviews.2

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:

git checkout -b feature-foo --track origin/main origin/main
…*:・゚✧ git commit -m refactor *:・゚✧ …
…*:・゚✧ git commit -m add new code *:・゚✧ …
…*:・゚✧ git commit -m change the UI *:・゚✧ …
git push origin feature-foo
GitHub flow: a local feature branch becomes a review with three commits
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
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:

  1. Commit “C” must merge before commit “D”
  2. Commit “C” may merge before “D” is reviewed
  3. 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
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
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.

GitHub’s docs, GitHub Flow: Make changes

Pile up isolated, complete changes until uhhh…your call, good luck!

✏️ GitHub could fix this

GitHub supports stacked pull-requests3.

But they’re almost unusable.

The process is pretty Kafka-esque:

  • You must create and push a branch for each local commit (or use strange git syntax to approximate this).
  • You have to generate a pull request for each branch in the stack while thinking really hard about the branch names you chose earlier.

Because GitHub makes this so hard, tools have sprung up to hack this into GitHub:

There’s even a VC-backed startup whose entire focus is stacked patches for GitHub.

But GitHub could obsolete all these tools if they cared to.

  1. Google, Facebook, Twitter, Android all use either Gerrit or Phabricator for code review↩︎

  2. “Smaller patches undergo fewer rounds of revisions, while larger changes have more re-work done before they successfully land into the project’s version control repository.” via Investigating technical and non-technical factors influencing modern code review↩︎

  3. The process is well described by Michaela Greiler.↩︎

Read the whole story
1 day ago
Boulder, CO
3 days ago
Ojai, CA, US
Share this story

A Halloween Carol

1 Share
[after a minute] "Okay, I think I've got it, thanks. Can I--" "oOOOooOOooo!"
Read the whole story
1 day ago
Boulder, CO
Share this story



Read the whole story
1 day ago
Boulder, CO
Share this story
1 public comment
2 days ago

Saturday Morning Breakfast Cereal - Series


Click here to go see the bonus panel!

Really you should wake up every morning and check the integral of happiness over time.

Today's News:
Read the whole story
5 days ago
Boulder, CO
Share this story


1 Share
Sequoia Brussels sprouts are delicious but it's pretty hard to finish one.
Read the whole story
23 days ago
Boulder, CO
Share this story
Next Page of Stories