Maybe it's like the silent majority: PHP developers have been made fun of for so long, they don't speak up. But there's millions of them hanging around the interwebs, keeping everyday systems maintained for normal people that are not flashy, but simply get the job done because it's stable and works.
Source: a PHP developer ;P
But I agree, a minor release is hardly news worthy
Eh, we aren't that traumatized. A decade and change of watching other groups of coders stick forks in outlets chasing Google's codebase has done wonders for our self esteem.
How is PHP's speed these days? I haven't been following but I heard that PHP has become much more capable in features and performance since I used it a decade ago.
My experience: coming from programming in C, then doing web-scripting with Perl, then PHP 4 through 5, 7 and 8 versions, it's been delightful. Big improvements in speed, ecosystem, very nice backwards compatibility in general (which is hard to do), and keeps being a flexible, multi-paradigm language. About frameworks, you can do things now like-ruby-on-rails with Laravel, like-java with Symfony, or just use any custom solution you see to fit better for team/yourself. Mantra: you can do shit code with any language, and PHP is flexible enough to let you organize projects the right way.
With all the stuff Facebook has made, PHP also has gotten a JIT on the standard package, I would stay it is fast enough, easily outperforming anything one would do in Python or Ruby.
If you care about performance in Webapps while using dynamic languages, it is pretty much PHP or nodejs, at least until CPython and Ruby MRI JITs improve.
I would have added VB.NET, but it isn't going anywhere nowadays.
Slow. Its faster than in PHP5 era, but benchmarks usually are misleading. Eg PHP does "less" making it faster for SOME tasks. If you include all unicode parsing, error handling etc PHP is still very slow.
Take Go as an alternative. Has unicode etc but still lots faster than PHP.
Go is not an alternative to PHP, and I say this as someone who likes (and uses) Go. It is more performant, yes, but it is also very verbose - I would hate to develop a CRUD (web) app in it. Not to mention that any data handling is more or less manual. Great language for some services, but not for a webapp.
Also PHP is far from slow. The code is precompiled ("cached") and the common operations are optimized as hell. IME the slow apps are usually just missing some MySQL indexes or similar.
PHP is slow, as an example we generate (somewhat complex pdf documents from a sourced html file), and it takes PHP multiple seconds to parse and generate the document. We since rewrote this in Go and now it runs in milliseconds.
This is pure CPU bound (the IO is only opening a file and not a bottleneck) and PHP is still very slow for anything more complex.
1. That thing point out every weird thing you can do in PHP without pointing out that in reality one does not do such things.
2. You are could replace every instance of "php"!in that text with "Javascript" and it would be about equally true: some things more, some things less, but in general they are equally bad. Doesn't prevent people from making great things with both.
Almost anything ist noch longer true. PHP has a very strong backward compatibility. Migrating from one mayor release to another mostly is possible without touching your code. But you can also start new and work with very modern language features
This was about PHP 4/5 -- we are currently on PHP 8. I wouldn't even bother reading it, and some syntax there is not used in modern PHP.
PHP still has its warts -- like any language -- but with IDEs (which weren't around in 2012) and modern frameworks, you don't run into them very often.
60% true still. Most of the issues are in "wontfix" mode. I have seen this article so many times, and its still relevant, even a decade has passed. Make you wonder what the hell php devs are really doing?
Relevant in what way? Relevant as in they are factual or relevant to the day to day of a real PHP developer, because I can tell you the latter didn't hold up even when this was written.
> even a decade has passed
We got more optional typing and better error handling, and I'm still able to run the awful code I have written a decade ago.
Java is an almost 30 year old language and I can still do this:
Last time i looked PHP still had no generics, and the "typesystem" is mostly a joke. All the builtin functions still have no namespaces, and no forced types. PHP still coerces strings to ints and vice versa. PHP still has serious bugs with its (only) collection, the frankenstein ARRAY. IIRC doing a array_filter is still broken on PHP8 for key val arrays. PHP still had no unicode in 2023, im not sure how the latest version fixed this or not. IIRC you had to use the weird mb_real functions to get anything closely functional, and it was a mess.
> Last time i looked PHP still had no generics, and the "typesystem" is mostly a joke.
So is Python's yet the language is enjoying great success.
> All the builtin functions still have no namespaces, and no forced types.
And no PHP developer cares, because neither does C and yet it's doing just fine.
> PHP still coerces strings to ints and vice versa.
Which is great for beginners, because they don't need to worry about it, unlike me when I program in Rust and have to deal with 8+ number types.
> PHP still has serious bugs with its (only) collection, the frankenstein ARRAY.
So does JavaScript, yet it's not enough to stop the language.
> IIRC doing a array_filter is still broken on PHP8 for key val arrays.
There is some odd behavior if you try to do certain things in a functional style that is actually true.
> PHP still had no unicode in 2023, im not sure how the latest version fixed this or not. IIRC you had to use the weird mb_real functions to get anything closely functional, and it was a mess.
That can get annoying in some use cases, I have developed many international web apps in PHP, it rarely got in my way, but I do acknowledge that it's not great to not have Unicode by default, I suspect they are afraid to resolve this after seeing what happened with Python 3.
Yeah that's ugly, but it doesn't really matter. What is worse is inconsistencies when declaring class vars and constants... But you learn to live with it.
Luckily PHP pop has declined drastically since 2010. Its barely holding on as a top10 language. We can all hope it dies some day. We need better and faster software, realtime and unicode aware. We dont need more php.
Real numbers is hard to measure with PHP. This is because of the weird world of CMS systems (like wordpress). From all PHP code out there WordPress is most likely taking 80% of all the online deployments. So is it really PHP anymore? Its just a UI you click, drag and drop and customize. You dont even have to touch any code.
IF this is the measure, why not count PHP as C, as its written in C?
I stil argue that a single javascript library (jQuery) is MORE popular in 2025 than all PHP installations combined. Take that for scale. Now add all javascript (non compiled) and it trumps PHP by a factor of 100.
A lot of the points were bad even when this was written for example "A language must be consistent." is probably not true for any of the top 10 languages.
> PHP is inconsistent: strpos, str_rot13
I used PHP for two decades and the naming issues while being annoying didn't really bother me in real life, nobody would tell you not to use C because you have 10 bad implementations of the same string method with weird names.
> Side observation: I loooove Python. I will also happily talk your ear off complaining about it, if you really want me to. I don’t claim it’s perfect; I’ve just weighed its benefits against its problems and concluded it’s the best fit for things I want to do.
You should check out the moment you reach this paragraph because Python has similar and sometimes worse developer experience issues.
> There’s no clear design philosophy. Early PHP was inspired by Perl; the huge stdlib with “out” params is from C; the OO parts are designed like C++ and Java.
Exactly, the language has a lot of old cruft, just like most old languages, but that does not matter, what matters is how well you can use it to build something useful today.
> There is no threading support whatsoever.
Neither in JavaScript and nobody developing JavaScript is missing horrors of threads, if you need that level of performance, there are more suitable languages out there.
> In PHP, these functions return false. If you use FALSE as an index, or do much of anything with it except compare with ===, PHP will silently convert it to 0 for you.
Just like in JavaScript, yet people are still able to build big things.
> There is no way to declare a variable. Variables that don’t exist are created with a null value when first used.
This is coming from someone who loves Python.
> PHP is dynamically-typed, so variables generally have no type… except references, which adorn function definitions, variable syntax, and assignment.
Not true anymore.
> Constructs
Full of nitpicks and statements that are wrong or don't mean anything.
> echo is a statement-y kind of thing, not a function.
This is a problem because?
> There’s redundant syntax for blocks: if (...): ... endif;, etc.
Because it used to be a templating language, don't use it or do use it, nobody will care either way.
> Error handling
It's configurable and you can configure it to meet your needs, moving on.
> PHP errors and PHP exceptions are completely different beasts. They don’t seem to interact at all.
They do now.
> But you can’t require that an argument be an int or string or object or other “core” type, even though every builtin function uses this kind of typing, probably because int is not a thing in PHP.
You can now.
> The procedural parts of PHP are designed like C, but the objectional (ho ho) parts are designed like Java. I cannot overemphasize how jarring this is.
It's not, you read the docs, you get the job done.
> clone is an operator?!
What does it matter if it's an operator or a function that is in the standard library?
> There is no module system.
There is Composer and you get an experience similar to Java.
> There are thousands of functions in the global namespace.
And this will destroy my productivity because?
> PHP basically runs as CGI. Every time a page is hit, PHP recompiles the whole thing before executing it. Even dev servers for Python toy frameworks don’t act like this.
Person writing this is not very experienced, because this hasn't been the norm for a long time.
> PHP is naturally tied to Apache. Running it separately, or with any other webserver, requires just as much mucking around (possibly more) as deploying any other language.
Author doesn't know what they are talking about, you can use whatever webserver you want.
> Similarly, there is no easy way to “insulate” a PHP application and its dependencies from the rest of a system. Running two applications that require different versions of a library, or even PHP itself? Start by building a second copy of Apache.
This is coming from someone who likes Python which has the same problem.
> The “bunch of files” approach, besides making routing a huge pain in the ass, also means you have to carefully whitelist or blacklist what stuff is actually available, because your URL hierarchy is also your entire code tree. Configuration files and other “partials” need C-like guards to prevent them from being loaded directly. Version control noise (e.g., .svn) needs protecting. With mod_php, everything on your filesystem is a potential entry point; with an app server, there’s only one entry point, and only the URL controls whether it’s invoked.
You use a framework and all of these problems go away.
> You can’t seamlessly upgrade a bunch of files that run CGI-style, unless you want crashes and undefined behavior as users hit your site halfway through the upgrade.
Has this person heard about containers or symlinks?
> No template system. There’s PHP itself, but nothing that acts as a big interpolator rather than a program.
Twig, Smarty etc.
> No XSS filter. No, “remember to use htmlspecialchars” is not an XSS filter. This is.
Use a framework.
> No CSRF protection. You get to do it yourself.
That's what frameworks do in any language.
> No generic standard database API. Stuff like PDO has to wrap every individual database’s API to abstract the differences away.
PDO is the standard database API.
-------
As someone who actually used PHP to get real work done I find this article very nitpicky and get the impression that it's mainly taking potshots rather than looking at things that actually matter day to day.
Majority of what is in this article doesn't matter in real life, a lot of the things that do matter have been fixed, there are some legitimate points that do impact you and have not been fixed yet, but they are few and far between.
This article compares core PHP with a framework from some other language, which is unproductive because most of the time you should be using a framework but at the same time it's impressive that you can actually write real applications just by using the standard library, I would not recommend it though.
PHP is incredibly stable, scales horizontally by default and has amazing documentation. I have applications I have built 13+ years ago and I can still get them to work with minimal effort on the latest PHP. PHP has a very low barrier of entry which can be incredibly helpful.
Is PHP without flaws? Of course not, some of the syntax is quirky and it's full of legacy code.
I always recommend: pick the framework not the language, if the way the framework works suits you, then choose it, otherwise find another one that is better suited to your exact needs, if I were to have a beginner write something, a PHP-based framework would be a good entry point, because they can learn the basics without worrying about typing too much.
>> PHP basically runs as CGI. Every time a page is hit, PHP recompiles the whole thing before executing it. Even dev servers for Python toy frameworks don’t act like this.
> Person writing this is not very experienced, because this hasn't been the norm for a long time.
I’m genuinely curious—what is the norm here now? I see a lot of PHP code, and 90% of it is just setting up the environment from the ground up, while only 10% is the real processing. The good side is being stateless, but the performance penalty is enormous. I still see a lot of file caching (please make this dir 777 for production) to mitigate some of it, but Redis has become remarkably visible over the last years.
Not being a PHP expert, I really need some best practices to point devs to.
Nobody runs PHP in CGI mode, either they go with libapache2_mod_php, where Apache itself does the work or PHP-FPM with Nginx.
Either way you are not going to pay for the PHP process startup cost.
PHP can also cache the interpretations of files so you avoid that cost as well.
And frameworks usually have their own usually file-based caching mechanism.
At the end of the day it's still going to have some costs compared to a single application server model, but for most web apps it's not going to matter, however it greatly simplifies the programming model.
Sure, it’s not pure CGI, just CGI on steroids. But frankly, it hasn’t gone too far. I’ve seen a lot of WordPress plugins with spaghetti code being called on every invoked endpoint. File caching is evil—many PHP devs love using the filesystem to store things, which is pretty nasty under K8s.
But it’s not the language itself, as I was advised. True asynchronous handlers are possible, which is promising.
> Sure, it’s not pure CGI, just CGI on steroids. But frankly, it hasn’t gone too far.
It doesn't need to go far, because it's selling point is that it's easy to learn and use.
The way I see PHP is not as a competitor to Java, .Net, NodeJS or Rust, instead I see it as a platform for non-advanced developers to be able to be able to create things and actually have the whole thing be cheap and sustainable.
> But it’s not the language itself, as I was advised. True asynchronous handlers are possible, which is promising.
The whole point of PHP is that it's single threaded, blocking and from the developer's point of view: your program starts at the request and terminates when the HTTP request is complete, this is what makes it simple to comprehend, if you want async, I would tell you to use something like Node instead.
> File caching is evil—many PHP devs love using the filesystem to store things, which is pretty nasty under K8s.
It's usually just an annoyance or just something you need to configure or just brute force it with a shared mount.
> I’ve seen a lot of WordPress plugins with spaghetti code being called on every invoked endpoint.
That's not really the problem of the language itself, the language doesn't force you to run anything on every request.
If you are concerned about request startup times (which is not the problem in most cases, cause db io is usually the bottleneck) you can look up the following swoole, octane, hyperf, frankenphp. Haven't used all of them in production but had good experience with swoole.
A lot of "Fractal of Bad Design" was more applicable when it was written in 2012. PHP has moved on since; there's a lot more emphasis on using OOP frameworks / libraries now. Particularly through Composer, which had only been released for a month when the essay was written (and, as such, which almost nobody was using yet).
Which ones do not require JavaScript AT ALL? Simple use-case: in which language may I make a CAPTCHA that does not require JavaScript? What about a full-blown e-commerce website?
I made a PHP CAPTCHA that requires no JavaScript, so pretty much everything?
What would a client-side language have to do with CAPTCHA? Kind of defeats the purpose of it, or rather, what it (server-side) does not have to do with it?
Have you tried building web apps at all in these languages as opposed to PHP?
I do not like PHP much but I don't get the hatred. I chose PHP as opposed to Go (and I never, ever considered a JVM-like language) when trying to make a simple CAPTCHA, but I did choose PHP for a full-blown e-commerce website too.
PHP has built-in session handling, the deployment is extremely simple and works out of the box, and PHP's server-side rendering aligns perfectly well with no-JavaScript sites, form handling and image submission work natively with PHP, and so on. Go may offer better raw performance but it does not make sense to use Go, and it is laughable to ever consider Java or Kotlin for it.
If you need an exhaustive list as to why picking PHP is the right (or pragmatic) choice here as opposed to Go or JVM-like languages, let me know and I will provide you one.
I argue that there is nothing more easy than deploying something like Go (or anything else that is compiled). With PHP you STILL ens up with a complex deployment pipeline even the apologists argue "just ftp it like in the 90s".
Why is the only PHP defence i hear always the same "use a framework!". I did those for decades, and they always end up sucking. Either you need to hack around them, they have shitty defaults and finally they are abandoned and bitrot without any way of rewriting because of the huge size of the app.
How about just write the code, using the stdlib and picking highly focused libraries for things you dont want to write (crypto, drivers etc.) your self.
Because using the particular framework in my experience once you have a basic grasp of it's concepts, makes development time of applications extremely fast. Delivering is what pays the bills.
You cant have unicode without the mess of mb_real_uppercase and friends. Concurrency on a webserver? LOL, this is like the lowest bar i have heard. This limit SO much and pretty much forces the concurrency to the client, and thats not always an option.
Of course you can. Write your own abstraction of Unicode string, it is easy. Php has all the tools for it.
Yes, in mainstream PHP you use the webserver to leverage forking. The great thing about that is that vastly simplifies the language and any frameworks written in that language. No, it doesn’t force anything to the client.
Also any performance gains made in web server technology is given to PHP for free.
In Java and Python and the like you typically have a thread pool to handle every request, this has the benefit that you can share memory with mutexes between request (threads) . However 99% of cases that is not typically something you want, to have leaky requests, thus most of the time you write code similar to PHP to avoid any hard to debug lock. In Python you also have bad threading performance because of the GIL, thus you avoid anything that steps into that.
Thus PHP share-nothing-model wins again. It is also a natural fit to stateless REST. In PHP you use the database to share memory (data), which is a natural fit in a web stack. And as with the web server you can now leverage any performance gains in database technology.
Nodejs is of course complete trash with the mini freezes of the event loop. And to leverage multiprocess you have to use something like cluster, thus you are back to share-nothing again.
Thus what you argue for is to change a successful request and memory model because of that 1% use case. That is dumb.
LongUniqueStringToHopefullyAvoidCollisions/Calc.php
---------------------------------------------------
<?php
namespace LongUniqueStringToHopefullyAvoidCollisions;
class Calc {
public static function sum($a, $b) {
return $a + $b;
}
}
hello.php
---------
<?php
require_once 'LongUniqueStringToHopefullyAvoidCollisions/Calc.php';
use LongUniqueStringToHopefullyAvoidCollisions\Calc;
echo Calc::sum(1, 2)
For people who don't know PHP it is probably hard to grasp and hard to believe: To avoid name collisions, you have to wrap your code in classes and then use the "namespace" and "use" keywords which function like prefixing the class names with a given string, so the class names hopefully do not collide with other class names in your codebase.
I cannot relate to this problem. The namespace is rarely a single "word". If you [follow PSR-4](https://www.php-fig.org/psr/psr-4/), you will create namespaces based on the directory structure - thus there would be no collisions possible.
Composer adds even more tooling around the fundamental problem that PHP does not have modules.
And it does not do away with the problem that you have to preemptively wrap everything in classes and add a LongUniqueStringToHopefullyAvoidCollisions via the "namespace" and "use" keywords to all your classes to hopefully avoid name clashes in the future.
PHP not having modules is a non-issue. Proof: It's done fine for several decades without it. If you're running into namespace collisions in your codebase frequently enough to demand a language change to help get your shit together I don't even know what to tell you.
It is not a non-issue. You can run into naming collisions by just using two different composer dependencies where each dependency depends on the same library but different major versions.
That's just not true. It's not JS. Composer will install exactly one version of every package. If your dependencies have incompatible dependencies themselves, then Composer will refuse to install the package. And this fact has led to PHP packages actually being maintained and kept compatible with each other. Of course, sometimes you run into dependency issues, but it's worth it because you'll always have quite clean, flat and small vendor directory. Compared to the node_modules horror it's great for maintenance.
This can definitely be an issue and it was when Guzzle released a new major version every month.
Also when working with projects that are 10+ years and lines of codes a million you will run into this. Sure you can always fork and move the library to another namespace, but that is extra work.
Modules are vastly superior to namespaces, with modules it is the caller that decides the symbol, with namespaces it is the callee.
Another problem with namespaces in PHP is that you can’t put anything into it, like a variable, it is not like namespace in C++. Namespace in PHP is just name added to the class or function name, kind of fake. Don’t get me wrong, it was a pragmatic solution to a real problem and it worked for what it tried to solve, make it easier to share code.
Modules could be elegantly solved in PHP by reusing the internal concept for a class (how it is with enums and interfaces)
Modules would also make it easier to unit test code, because you will not need to worry about a symbol already have been loaded and can’t get unloaded.
With that said I don’t think it the most important feature to focus on, there are others that give more bang for the buck, like string templating and operator overloading.
Yes, because functions can’t be autoloaded and you can’t put variables and constants inside a namespace. But it isn’t hilarious, it is because of legacy.
Now there are proposals to fix function autoloading but it won’t fix variables and constants.
Thats why PHP code looks like Java. EVERYTHING is wrapped in a class, because of the shitty packaging PHP currently has. Namespaces are weak and can be inconsistent. Also the stdlib has no namespaces? Wtf?
You're pointing a finger at the wrong villain. Laravel's your culprit not core PHP. I have no idea what mind-altering substances that crowd got into when they decided to objectify everything all the time, but it isn't a hallmark of either the language or good coding practices and the result is so hard to debug it requires it's own toolchain. Fun Fact: Drupal's core team threw a big chunk of it's community developers overboard switching to this bullshit. Net result: they bricked the project's credibility listening to the wrong people and lost a bunch of market share and mindspace because of it. A shame too, the project could have credibly challenged Wordpress if they'd gone another way.
We dont need yet another adhoc dependency. All the PSRs out there are just a big ball of mud. We have incrementing numbers each years, and today there is something like PSR-12. Its a joke.
If you mean anything like the clusterfuck that is Java Modules, please keep that out of PHP, thanks.
In any case - is there any concrete actual real world example in a modern Symfony/Laravel application where you run into issues while using a decent IDE?
This. PHP bolted on namespaces, back in 5.3 (iirc) and they failed to namespace the stdlib, and now 20 years later we are still stuck with the same garbage.
PHP has only globals really, no module system what so ever.
I think you’re being a bit disingenuous here. Almost all packages are vendor and package prefixed yes, but your own code from very easily be as simple as:
namespace Me;
function test(){}
———
use function Me\test;
test();
Conflicting package names require you to be working on a very poorly written project (not using PSR-1) or a dependency that is even worse which is fewer and further between since composer.
It becomes a problem if you want to use multiple versions of the same library, which may happen if you are using composer, e.g two different dependencies uses the same dependency but different major releases.
It is valid. I’m running 8.4 and with autoloading etc it all works as expected. Maybe the language you’re arguing against isn’t the same language anymore.
https://www.php.net/ChangeLog-8.php#8.4.4
That being said, this is a pretty boring release. Save the upvotes for 8.5 when it comes? :)