Ruby was (very) slow back then (notably and measurably slower than PHP, Python, or Perl) and people still loved it. The warts on PHP that got the most bad press were rarely related to performance.
So, yes PHP used to be slower than it is today, by a lot. But, speed wouldn't have immunized it against the criticism leveled against it. All the effort going into fixing performance for PHP coincided with fixing some of the bigger warts of the language, as well...so much of the hate for PHP has dwindled in recent years.
The fact that people building for the web are much less often required to work in PHP also reduces the hate.
Since PHP5, the lead team made progress into making it solid. And in PHP7 some eastern/russian guy hacked the VM a lot. Adding new traits and improving memory usage and performance a lot too.
The "hatred" comes from old days (v3,v4):
- massive inconsistency in naming
- global side effect was a norm
- bugs, bugs, bugs
Combined with the nascent web boom, tons of new kids (that includes me) started having fun with html/php. A large mass of the web was written with it, carrying all the bad design decisions in forms of security bugs and impossibly bad code.ps: I audited one famous wordpress plugin and it was 10 pages long of redundant code in 3 big loops, dead code everywhere, commented code released in production. All this to add a few links here and there.
Facebook hasn't spent a lot of time worrying about their choice of PHP either. Facebook's primary language is Hack, a mostly compatible derivative of PHP. Prior to Hack (~2014) Facebook used traditional PHP, which they reimplemented a couple times for performance reasons. It seems that Facebook has spent its time worrying about how NOT to leave PHP.
Makes one wonder about the value of this daily new programming language era we're in at the moment.
There was some legitimate criticism to be had about PHP 5.x being slow, especially if it wasn't paired with an opcode cache system / accelerator.
But in practice, the Node.js ecosystem is all built around evented I/O and PHP has to execute them one at a time.
(Well, actually with libraries like Kraken and ReactPHP and amp, you can have an event loop, but there are not that many I/O options for you.)
Most of the replies here are stating that PHP is fast. It can be for these kind of benchmarks.
But, it does have the reputation you're suggesting. That reputation, though, is based on the old CGI model. Most php apps are built in a way that all of the initiation and setup code is run for every single request. That makes it comparatively slow.
Some PHP apps get around that by using a shared memory cache, like apcu, to box around that. That helps a lot, but isn't the same as a typical golang or node.js app where startup code is truly run once, and new requests go through a much shorter path.
All of that, though, is less a "language" thing and more of a runtime thing. You can, for example, use Facebook's HHVM+Proxygen and run PHP code in the exact same way as node.js.
PHP also has the best language features and IDE integrations, the only remaining problem is the legacy stdlib and devbase. Ruby with an inliner and method cache would catch up, but I don't see it happen. Python is doomed by its architecture. Perl has a faster interpreter loop, but data structure bloat and similar dev problems as the other 2.
The means that a lot of rather bad (inexperienced?) programmers use it, which means there is a lot of bad PHP code out there.
People see that bad code and assume the language is bad.
The language has some warts and inconsistencies, and people are eager to point them out as justification for their hate. But for real programming most of them hardly matter.
The biggest difference between PHP and the other dynamic languages, though, is that PHP came out with pretty popular stuff like wordpress, joomla, magento or drupal that they all share crappy code coz they all have a large codebase started before PHP managed to fix some stuff starting from version 5.3
This is also becoming less of a distinguishing factor in the container era where the answer for a number of cases is “Extend a base Docker image”.
If you really, really try it's possible in Python, C# and Java too, but ... wtf.
[1] - http://hhvm.com