My honest opinion about PHP

Published on 12/06/2025

Although PHP powers more than 70% of the websites, many of us still hear claims like "PHP is dead", "PHP is outdated", "PHP is alive only because of WordPress", etc. . In some ways PHP is similar to JavaScript, for example, it's a dynamically typed language (although with some basic runtime type check support), has almost the same age as JavaScript (about 1 year older than JavaScript), has many type coercion quirks and has its share of design flaws.

The history of PHP

Before the main discussion, let's first dive a little into the history of PHP.

Back when the web still crackled with dial-up tones, a Danish-Greenlandic engineer named Rasmus Lerdorf wrote a few C scripts to track visits to his online resume. Those modest "Personal Home Page Tools" (PHP Tools) snowballed into a public 1.0 release on June 8 1995, giving hobbyists an easy way to drop dynamic snippets straight into their HTML pages.

From hobby hack to community engine (1995-1998)

By 1997 the project-now called PHP/FI 2.0-had acquired a primitive templating system and SQL support, but its real growth spurt came when two Israeli students, Zeev Suraski and Andi Gutmans, rewrote the parser. Their work culminated in PHP 3, released 6 June 1998, and the language officially re-branded itself "PHP: Hypertext Preprocessor".

The Zend era and mainstream adoption (1999-2004)

Suraski and Gutmans didn't stop there. They extracted their new core as the Zend Engine (a mash-up of their first names) and built PHP 4 on top of it. Debuting in May 2000, PHP 4 delivered the performance that large sites like Yahoo! and early Facebook clones needed, turning PHP into the default language of the shared-hosting boom.

Four years later, PHP 5 shipped with Zend Engine II, a full object-oriented model, SimpleXML, SOAP, and the bundled SQLite extension-features that let PHP graduate from "quick-and-dirty scripting" to a language you could architect with.

Leaping ahead: PHP 7 (2015)

A long-running, never-released "PHP 6" Unicode experiment threatened to fragment the ecosystem, so the community jumped straight to PHP 7. Powered by the phpng refactor of Zend Engine 3, PHP 7 went stable in December 2015 and instantly doubled performance over PHP 5.6 while slashing memory usage, an upgrade so dramatic that many sites saw response times halve overnight.

The modern family: PHP 8.x (2020-2025)

8.0 (2020) introduced the long-awaited JIT compiler, union types, attributes and match syntax.
8.1 (2021) added fibers and enums, paving the way for async runtimes.
8.2 (2022) brought readonly classes.
8.3 (2023) delivered typed class constants and json_validate().
8.4 (2024) landed property hooks, asymmetric visibility, and smarter array -search helpers, its general availability on 21 Nov 2024 marked the language's quickest cadence yet.

My opinion about PHP

As you can see, PHP is still evolving and gaining new features. PHP8.x is definitely not the same old PHP 5 or even PHP 7. However, in my opinion, the latest improvements mostly focus on more exotic use cases, rather than improving more common everyday issues like ergonomics.

Here I want to first list what I don't like about PHP, and then what I like.

Things I don't like in PHP

Despite the recent improvements, it seems that the ergonomics of the language still lags behind many other comparable languages, including JavaScript. Here I am going to highlight some of the ergonomic and type safety issues.

C-like procedural syntax for array and string manipulations

Unlike JavaScript, where strings or arrays have methods and properties, PHP doesn't support them. Instead you have to pass strings or arrays to some standard built-in functions. This makes IDE autocompletion and discoverability more complicated. Although many of such functions have a standard prefix in their name, such as array_ or str_, it's not always the case, and a substantial number of functions have inconsistent namings. For example, in_array, implode, shuffle, trim, stripos, lcfirst, etc. .

Array: a mishmash of a hash map and a regular array

PHP arrays are very appealing to be used as data structures in many codebases. However this chimeric nature of arrays can bring problems. You see, some arrays can be used as regular index based arrays, some arrays can be still index based while being sparse (have indexes missing, i.e. have "holes") and some arrays can be used as objects (analogue of JavaScript objects). Additionally, even some array built-in functions can transform a regular array into a sparse array and you might not even notice this until you start to access some element by index:

<?php
$array = [1, 2, 3, 4];
print_r($array); // Array ( [0] => 1 [1] => 2 [2] => 3 [3] => 4 ) 
$filteredArray = array_filter($array,  fn($x) => $x > 1);
print_r($filteredArray); // Array ( [1] => 2 [2] => 3 [3] => 4 ), the key 0 is missing, it's a sparse array

In order to fix this, we can wrap the result in array_values():

<?php
$array = [1, 2, 3, 4];
print_r($array); // Array ( [0] => 1 [1] => 2 [2] => 3 [3] => 4 ) 
$filteredArray = array_values(array_filter($array,  fn($x) => $x > 1));
print_r($filteredArray); // Array ( [0] => 2 [1] => 3 [2] => 4 ), now it's a regular array

Another small issue is that in edge cases PHP arrays can behave undesirably when working with JSON strings:

<?php
$nonEmptyData = ["foo" => "bar"];
$emptyData = [];

print_r(json_encode($nonEmptyData)); // {"foo":"bar"}, an object in JSON, as expected
print_r(json_encode($emptyData)); // [], an array in JSON, this might introduce problems for frontends or apps
				// when they expect an empty JSON object

This can be fixed by using an actual PHP object instead of array:

<?php
$emptyData = [];

print_r(json_encode((object)$emptyData)); // {}

But, unfortunately, many PHP codebases and frameworks prefer to work only with PHP arrays for dynamic data structures, and I can understand this.

All of this above can make working with PHP arrays more frustrating than with JavaScript.

Dangerous loose equality even for values of the same type

We can't even count the number of memes about the insanity of loose equality (==) in JavaScript. Well, at least in JavaScript, you will be fine if you compare values of the same type (except for NaN, but this is not specific only to JS). This is not the case in PHP, where even 2 different strings can be "equal":

<?php

echo "0.1" == ".1"; // 1 (i.e. true)
echo "123" == "000123.000"; // 1 (i.e. true)
// This happens because both sides are converted to numbers

This example alone shows that you probably should always use === instead of == in PHP! Who knows how many security issues exist because of ==.

Lacks deeper type validations

Although PHP supports types for function arguments and class properties, it doesn't support deeper level type validations, such as for array keys or values. There is an article by Brent Roose called Why we can't have generics in PHP where the conclusion is that native generics won't come to PHP, because the performance / memory overhead will be too high. The best we can hope for is to create a superset of PHP and transpile it into PHP, similar to how TypeScript is transpiled into JavaScript.

The $ prefix in variables and string interpolation

OK, we can live with this, but honestly, even Rasmus Lerdorf himself would probably not do this if he designed a new language in 2025. The $ prefix was initially used in variable names because at that time with $ prefix it was much easier to write the code parser and also easier to insert variables in strings. This is mostly not for the programmer's productivity. Also string interpolation is done poorly and inconsistently, especially for complex expressions:

<?php

$o = 5;
echo "$o"; //5
echo "{$o}"; //5
echo "{($o)}"; // {(5)}, would expect "5"
echo "{($o + $o)}"; // {(5 + 5)}
//echo "{$o + $o}"; // parser error if I uncomment it

In contrast, JavaScript did string interpolation really well with template literals which were introduced in ES6:

const o = 5;
console.log(`${o}`); //5
console.log(`${(o)}`); //5
console.log(`${o + o}`); //10

Things that PHP has done right (for most websites)

Despite the mentioned problems, PHP has some advantages over other alternatives, including NodeJS. I would say they are one of the reasons (not all) that make PHP so popular. Here I'll list a couple of them.

Doesn't need restart or recompilation when updating files

PHP is designed in such a way that it doesn't require any restart or recompilation when you change some file. The user only needs to reload the page in order to see the result. This fact makes it very easy to learn PHP. This makes deployments easier as well.

One isolated thread per request = more robustness + horizontal scaling

PHP's execution model differs from many other technologies. For each request PHP creates / reuses a new thread with its own isolated context where things are done mostly sequentially. Firstly, this means that PHP gives you some decent horizontal scaling out of the box. Secondly, this means if the code misbehaves, crashes or hangs, there is a chance that it will be limited to only one request. These two facts lower the entry barrier for newbies.

Just compare this to NodeJS, where by default there is a single thread running, and if the code misbehaves or hangs, it can affect the entire system. In NodeJS, for a comparable scale system, the code must be written much more carefully, many things must be taken care of, such as memory leaks, RAII, long-running sequential tasks, asynchronous events, promises, error handling, etc.

Is PHP dying?

A lot of people, including myself wonder, whether PHP's usage is declining and how fast is this process. There is a significant inconsistency in many statistics, but at least I can say that even if PHP's usage is declining, the process seems to be very slow. Besides the mentioned above virtues, PHP has a lot of structural forces which slow down the process. Among them are WordPress, hosting infrastructure, frameworks & package ecosystem and talent pool & knowledge base. Migrating millions of sites (plus 70 k+ plugins) to another runtime would be breathtakingly expensive and risky. Hosting infrastructures have 20 years of automation, support scripts and cPanel tooling around PHP, rewriting those stacks would cost them more than keeping PHP. The situation is a bit similar to ICE vs EV cars. Even if the new tech becomes objectively better, things won't change overnight.

So the most likely answer is that PHP is here to stay for many years to come.