PHP is the language I reach for most, in 2026, by choice. I know how that reads in a market where every job description asks for TypeScript, and I would rather answer the objection directly than let it sit unspoken on my profile.
The short version: the PHP I write has almost nothing in common with the PHP that gave the language its reputation, and most of the arguments against it are arguments against code written fifteen years ago that nobody has touched since.
The longer version includes where I think the criticism is fair.
What the objection is actually about
When someone hesitates at PHP, they are usually not making a claim about the language specification. They are picturing a codebase: a few thousand files, database queries inside templates, no type declarations, no autoloading, no tests, a config.php with credentials in it, and a deployment process that involves an FTP client.
That codebase exists. There are a great many of them, because PHP powers an enormous amount of the web and a lot of it was written under deadline by people who have since left. The reputation is not invented.
But that is a description of unmaintained software, not of a language. I have seen the same shape in Java, in Python, and increasingly in JavaScript projects old enough to have lived through three build tool migrations. The thing people are reacting to is age and neglect, and PHP has more of both because it has been in production longer than most of the alternatives have existed.
What modern PHP actually looks like
The code I write has typed properties, typed arguments, typed return values, and enums. Strict types are declared at the top of the file, so the language stops silently converting a string into an integer behind my back. Dependency injection through a container rather than globals. Composer for dependencies, which is a perfectly ordinary package manager. Immutable value objects where the data should not change after construction.
A static analyser runs over all of it in continuous integration. So do ten architecture rules I wrote to enforce the layering, which fail the build when a controller reaches for a model or a service reaches past its boundary. Those rules are the reason the structure still holds after years of people being in a hurry, including me.
Underneath it there is Redis for caching and sessions, a queue with background workers for anything that should not make a user wait, token-based authentication, and an error format that follows the actual standard for HTTP problem responses rather than a homemade envelope.
None of that is exotic. It is what any competent backend looks like in any language. That is the point. The interesting parts of my work are not language features, they are decisions about layering, consistency, failure handling and how to change a system that people are using right now.
Where the criticism is fair
Three things, and I would say all of them in an interview.
The ecosystem’s floor is lower. If you pick a random PHP package you are more likely to find something unmaintained than in a comparable Go or Rust ecosystem, partly because the community is older and larger and partly because the barrier to publishing was always low. This is a real cost. It means I read more dependency source than I would like and I take on fewer dependencies than I otherwise would.
Concurrency is not its strength. PHP’s request-per-process model is simple and it handles ordinary web traffic well, but if I needed thousands of long-lived concurrent connections, real-time streams, or heavy in-process parallelism, I would not argue for PHP. I would reach for Go or Node and say so.
The typing is good now and it started late. Compared to a language that was designed with types from the beginning, PHP’s type system has gaps and its generics story is weaker. Static analysis fills a lot of that in, and static analysis is not the same as a compiler.
If those three things describe your problem, PHP is the wrong tool and I would tell you that rather than talk you into it.
The decision rule I actually use
Greenfield standalone service: pick the language that fits the problem. If it is heavy concurrency, that probably is not PHP. If it is a web application backed by a relational database, which is most business software, PHP is a completely reasonable answer and the productivity is excellent.
Established surface already running in production: keep it on what it runs on, and modernize in place. Rewriting a working system into a fashionable language is the most expensive way to end up roughly where you started. The rewrite freezes feature work, and the new system reproduces the old system’s bugs because the bugs were in the business rules, not the syntax.
This is not loyalty to PHP. It is the same rule I would apply to a Rails application or a .NET service. The language a working product is written in is rarely its actual problem.
Why this matters beyond the language
The reason I will defend this in an interview is not that I need PHP to be popular. It is that “which language” is usually the least interesting question about a piece of software, and how someone handles it tells you something.
An enormous amount of the world’s revenue runs on systems written in languages that are no longer fashionable. Somebody has to keep those systems safe to change. That work requires reading code you did not write, understanding rules nobody documented, and changing things without breaking the business that depends on them. Those skills transfer across every language. Fluency in this year’s stack does not transfer backwards.
I spent ten years making one system progressively safer to change, and most of what I know came from living with my own decisions long enough to see which ones aged badly. Almost none of what I learned was about PHP. It was about layering, enforcement, observability and knowing when a migration is worth its cost.
I write PHP because it is the right tool for a large class of problems I am good at solving. When it is the wrong tool I say so and use something else. That is the whole position.
Questions I get asked about this
Is PHP still a reasonable choice in 2026?
For a web application backed by a relational database, which is most business software, yes. Modern PHP has strict typing, enums, dependency injection, a mature package manager and static analysis that catches a large class of errors before runtime. The objection people actually have is usually about a specific old codebase they once worked on, not about the language as it exists now.
What are the fair criticisms of PHP?
Three. The package ecosystem’s floor is lower, so you read more dependency source and take on fewer dependencies. The request-per-process model is not suited to thousands of long-lived concurrent connections, where Go or Node is the better tool. And the type system arrived late, so it has gaps that static analysis narrows without closing.
Should you rewrite a working PHP application in another language?
Rarely. A rewrite freezes feature work and tends to reproduce the original bugs, because the bugs live in the business rules rather than the syntax. Modernize in place instead: add types, enforce layering, add observability, and migrate one surface at a time. The language a working product is written in is rarely its actual problem.
When would you not choose PHP?
Heavy concurrency, long-lived connections, real-time streaming, or in-process parallelism. If that describes the problem I would argue for a different language rather than talk someone into this one.