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).
> 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.