PHP is the language people love to dismiss. It has a complicated history, a standard library with inconsistent naming conventions, and a reputation built on code written before 2010.
PHP 8.2 and 8.3 are not that language. The modern versions have named arguments, enums, fibers, readonly properties, union types, nullsafe operators, and match expressions. The language has been growing up quietly while the criticism stayed loud.
Deployment simplicity that other stacks cannot match
A PHP application deploys to any shared host. No Node.js version to manage, no build step to coordinate, no process manager to configure. FTP the files, it works.
That simplicity has a real dollar value for clients running on $10/month hosting. Dismissing it as unsophisticated misses the point that not every project needs a Kubernetes cluster.
The type system has matured
PHP 8 brought union types, intersection types, and nullsafe operator chaining. Combined with strict_types declarations and a type-aware IDE, modern PHP catches a large class of errors before runtime.
It is not TypeScript. The type checking is runtime, not compile-time. But it is far removed from the untyped PHP of a decade ago.
Enums done right
PHP 8.1 enums are backed enums — they carry a value — or pure enums. They implement interfaces and can have methods. A status field in Laravel that used to be a string constant becomes a proper type:
enum OrderStatus: string { case Pending = 'pending'; case Shipped = 'shipped'; case Delivered = 'delivered'; }
Compared to the string constants and docblock annotations that served the same purpose before, backed enums are a genuine improvement to code clarity.
Where PHP still has rough edges
- Asynchronous I/O is possible via Swoole or ReactPHP, but it is not the default model. CPU-bound tasks and async workloads are better served by other runtimes.
- The standard library naming inconsistency is a permanent scar. array_map versus str_replace argument ordering remains a source of bugs.
- Dependency management via Composer is excellent, but the ecosystem is narrower than npm for non-web workloads.
PHP is the right tool for a specific set of problems, mostly centered around web content delivery and CRUD-heavy applications. Knowing that boundary is more useful than having a universal opinion about the language.