I don't know whether the alternatives are objectively better, except maybe in certain domains.
Mostly, people seem not to like PHP because they find it ugly and awkward... which is valid, but subjective. The major alternatives (JS, Ruby and Python) have documentation, frameworks and reasonably comprehensible paths to an MVP, although one could argue that PHP is still slightly better in terms of speed of deployment. Everything seems to have converged and normalized to the point that the factors affecting one's choices primarily have less to do with the language itself and more to do with the ability to hire for it, and whether or not you like significant whitespace.
I strongly disagree with this statement. 10 years ago this would be correct, but as you said yourself the tooling is so normalised that pretty much everything is an alternative to PHP.
WAMP is a Windows web development environment; it is a simple way to install / run Apache2, MySQL, and PHP on your Windows machine for local development.
Heroku is a deployment solution which packages an app’s code and dependencies into virtualized Linux containers that are designed to execute code based on user-specified commands.
> PHP is still slightly better in terms of speed of deployment
When it comes to securing the deployment I think Python/Ruby would be better though - if you factor that in I would say it would be faster for me to deploy a python app than configure php to be secure.
That's probably true - other languages benefit from learning from PHP's mistakes and requiring a framework to begin with to enforce a lot of the safety that PHP doesn't have out of the box, and that's not mentioning any safety that would come from the language itself.
People say PHP is a framework, but as a framework it's terrible enough that you still need a framework for the framework.
You have to write proper configs for php-fpm, configure apache if you use that etc. All of this takes time, its very easy to deploy php app, but configuring server to sandbox it properly takes time and should be accounted for.
This response doesn't float right with me. Are PHP fpm configs horribly wrong by default? Do you not put a service like nginx/haproxy/apache/gunicorn/caddy in front of Ruby/python for a serious production deploy? Do you legitimately expect to deploy ruby/python without spending a minimum of an hour going over configs and assuming everything is right for your application by default while also assuming the opposite for PHP? I read the PHP configs for fun micro optimizations. It takes less than 10 minutes to find your framework's best practice list and apply them.
Personally working with PHP at a pretty large scale (hundreds of thousands of requests per second), I think it’s scaling is far simpler, easier, and cheaper than a lot of other options I have used, in particular node.
The simple threading model applies to many cores and across a large fleet of servers with basically zero effort.
If you’re looking towards hosting on shared style infra, php is still the choice. Also if you just have experienced PHP devs
Python is a pretty great alternative - it gives you more breadth to go wide than PHP does (batch processing, hadoop, machine learning, whatever really) but really there are like 10-20 different languages in the ecosystem that are all viable candidates.
It is not bad at all but since there are so many good/better alternatives I would never start a fresh project with PHP nowadays.
The only reason would be if you have a team with PHP experts - then PHP would be the obvious choice.