The Reputation

You have heard the joke before you opened this book: PHP is the language of 2004, held together with duct tape, written by people who never learned to program properly. The reputation is old, it was earned, and most of what earned it is no longer true. That sentence is the whole chapter, and the rest of this book exists to let you check it yourself rather than take it from me.

Start with what is still visibly true. As of 2026-09-17, PHP runs 69.9 percent of all websites whose server-side language is known, according to W3Techs, which recomputes this figure continuously from live crawl data rather than survey responses. The number moves week to week (it read 71.8 percent in March 2026 and 70.2 percent on 3 September 2026), so treat any single percentage as a snapshot, not a constant, and expect the number printed here to already be slightly wrong by the time you read it. What the movement does not change is the order of magnitude: most of the server-rendered web still runs PHP, which means the language is not a bet you would be making alone.

That scale is also the source of the reputation. A language that a large fraction of the web has run for three decades accumulates a large fraction of the web’s worst code, written under every level of time pressure and skill, in every era of the language’s own history. Early PHP, the PHP of the phpBB and osCommerce era, mixed HTML and logic on one page with no enforced structure, no dependency manager, and no standard way to test what you had written. A program that ran was often good enough, because there was no cheap way to prove it was correct. Criticism of that era’s code was accurate, and a meaningful share of it is still running in production today, which you can read about in Governance and Versions. Judging the current language by that code is like judging a company by its founding-year prototype.

The code itself earned the reputation too, not just the era. A page that mixed the database query, the business logic, and the HTML output in one file, with no enforced boundary between them, was not a caricature: it was a common, working pattern, because nothing in the language stopped you from writing it that way and nothing in the toolchain caught the result before it shipped. There was no standard way to declare that a function expected an integer and not a string that merely looked like one, no standard way to pull in a third-party library without downloading a zip file and hoping its internal file paths did not collide with your own, and no standard, shared convention for how one library’s code should be organized so another library could find it. Individually, each gap was a minor inconvenience. Together, across millions of independently written sites, they produced exactly the ecosystem the reputation describes.

What changed did not change quietly. The language added a real type system: scalar and return type declarations, union and intersection types, and declare(strict_types=1) to opt a file out of PHP’s historical type coercion entirely, covered with code in The Runtime. It gained a dependency manager and a public package registry, covered in Cost, that turned “download a zip and hope” into a resolvable, lockable, auditable install step. A standards process, PSR, adopted voluntarily by framework and library authors rather than imposed by the language itself, gave the ecosystem a shared convention for how autoloading, logging, and HTTP messages should be shaped, so that two libraries written by strangers could be relied on to fit together. Static analysis tools that read a codebase without running it, PHPStan and Psalm among them, turned “does this function actually always return what it claims” from a runtime surprise into a question you can answer before deploying. None of this erases the old code still running somewhere on your vendor’s server. It does mean that “PHP” and “the worst PHP you have seen” stopped being the same referent sometime in the last decade, and a due-diligence review has to treat them as two separate questions.

The ecosystem around the language changed on the same timeline. A page you might have described a decade ago as “just PHP” is now, more often than not, built on one of a handful of full-stack frameworks, among them CakePHP, Laminas, Laravel, Symfony, and Yii, each imposing its own structure, routing, and testing conventions on the code written inside it. None of them is presented here as the right or the popular choice; the point is only that the language stopped being something you wrote entirely by hand somewhere around the time the reputation calcified, and the reputation did not update.

The limit. The reputation is not entirely obsolete. A meaningful share of the PHP install base still runs versions with no vendor support, and a codebase inherited rather than written under discipline can still be exactly as unstructured as its reputation suggests. Neither fact is about the current language; both are about what a specific organization did with an old version of it, and Where PHP Is the Wrong Choice names the pattern plainly rather than arguing it away.

Every chapter after this one follows the same shape, because a decision document that asks to be trusted has to be checkable, not just readable. Each one opens with the question an evaluator actually asks, states the sourced answer plainly, then shows the evidence before the argument built on it. Each one names, in its own terms, where PHP falls short of the question it is answering, because a chapter with no limit in it is not a chapter you should trust. And each one closes with something you can check yourself in an afternoon: a command to run, a public page to open, a benchmark to rerun. None of this is an argument that PHP is the right choice for your next project. It is an argument that the reputation and the current language are two different things, and that an evaluation worth trusting has to look at the second one directly instead of quoting the first one from memory. The rest of this book is that look: how the language actually executes, who actually runs it today and at what scale, what it costs, who maintains it, and, as plainly as the first four questions, where it is the wrong tool for the job.

What to verify yourself. Open w3techs.com/technologies/details/pl-php right now and compare the live percentage to the one printed above; the gap between them is a small, honest demonstration of how this book treats a moving number. Then read the version-fragmentation figures in Governance and Versions before you decide how much of the old reputation still applies to a vendor or a codebase you are actually evaluating.

The question this book keeps coming back to is not whether PHP used to deserve its reputation. It is whether the language in front of you today, the one with a type system, a dependency manager, and a funded maintenance process, completes the architecture you are actually building. The Runtime is where that question starts.