New energy in an ecosystem is never a bad thing.
We aren't working in that environment any more. What software runs on a server is no longer up to the hosting company. A developer/devop can configure a server far more easily, with no input from a sysadmin. The process can be completely automated. That change has opened up development options considerably. That doesn't mean writing code in PHP is a bad choice, but it does mean there is a choice. PHP's primary advantage has been eroded to the point where it should no longer impact the decision making process when you're figuring out what to use. Everything else has caught up.
In terms of initial setup of an application than doesn't use anything but the standard library in either language I would completely agree with you.
Edit: Composer, not Artisan as dependency manager in PHP.
Granted, Composer is slow, but it works so well, mainly when package developers tag and release packages properly though. What issues do you have with it?
"composer parallel install plugin" is what it calls itself - it downloads all the repositories before composer gets to the install step and then composer just loads everything from cache - super fast!
It takes much more manual work to set everything correctly than running a python application.
They weren't saying it was hard but that it is not as easy as PHP. PHP is one level up from a static site for most beginners, you can simply drag and drop a file on many shared web hosts and get going. That is the attraction.
If you're writing something moderately complex then you're very likely to be running it on a virtual instance (maybe more than one) on AWS/Digital Ocean/etc, and if that's the case then you'll go much faster if you have a testable, reproducible build process that your development team can tear down and build back up easily. That is much more complicated than FTP'ing a few scripts to a server and importing a SQL script with PHPMyAdmin, but at the same time, as soon as your service hits a few thousand users with hundreds of them accessing it concurrently, your PHP script FTP'd to a shared server probably isn't going to work very well.
Learning new things is not a reason to avoid moving forwards. If anything, it's why I got in to web dev in the first place. New things are what make it interesting. I don't learn all of them, and I don't switch tools very often, but sometimes something comes along that makes life better. Reproducible builds with Ansible/Puppet/Chef/etc is one of those things.
It's better to insist on simplicity at every level, whether you're building "simple one-person web apps" or "complex large-team" ones. In fact simplicity at every level would be even more beneficial in the latter case.
So I find this "dead easy deploy is only beneficial for small apps" dichotomy false.
If a deploy fails and a client is panicking because their app isn't available, the last thing you want is a team of stressed developers trying to work out which files they need to revert.
"Simple" doesn't mean "easy".
Who said it's has to be either one or the other?
The "manual process of copying files to a server" can be done simply by a person for a small scale project, and it also can be automated any way one likes -- e.g. to "automatic copy files to a server when code is merged in to a repo".
"Copy a file to a directory and the server just works and shows it" doesn't imply manual ftp uploading or manual editing of any kind -- it's just so flexible and easy that can it work that way too.
And if anything breaks, it's still simpler to find out what went wrong -- as opposed to some convoluted server deployment process with more moving parts.
"We" are a minority.
The vast majority of websites out there are still hosted on shared servers over which the customer has very little control other than installing and updating WordPress. You might be able to convince cPanel to let you run a Rails app, but the system as a whole was designed with PHP in mind.
The owners of those websites have absolutely zero interest in messing with the server environment. They're not developers. They've probably never heard of devops. They're totally allergic to SSH and can barely even use FTP. And yet, these are the people who, whether knowingly or not, help keep the web as decentralized as it is. PHP was the only language that catered to them 15 years ago, and it still is the only language that makes this possible on a large scale.
I host my blog with NearlyFreeSpeech.net. The whole site is just a couple of PHP scripts. I haven't updated it in almost a year, but it keeps working, no maintenance required. If I had to host it on DigitalOcean like all the cool kids do, it would cost me 10x more in monthly fees (even with the smallest droplet) and 100x more in time. This kind of setup is what I call "It just works." Not dockerfiles and bootstrapping commands and all sorts of dependency management tools.
The smallest droplet is 5 dollars a month, do you pay 50 cents a month for your shared hosting?
>100x more in time
Have you even looked into DO or are you just making assumptions? You can create a ton of apps with one click (One-click apps) and install a full stack with WordPress, Drupal, Django, and much, much more, and it just works. If anything, it's the same amount of effort as some cPanel shared hosting.
Yes.
> Have you even looked into DO or are you just making assumptions? You can create a ton of apps with one click (One-click apps) and install a full stack with WordPress, Drupal, Django, and much, much more, and it just works.
My company manages servers for non-technical people whose small business or hobby websites have outgrown shared hosting. I often get clients who found out a little too late that running a Linux machine securely and efficiently is much more complicated than deploying a one-click app on DigitalOcean (or a similar service). I sweep in, optimize the hell out of everything, and occasionally patch some gaping security holes. So no, it doesn't "just work". At least not in the long term.
This. My first web programming was in Perl [1], and using PHP was much simpler to get into. You just uploaded it and it worked.
I think the biggest problem with PHP was it was a hammer and everything looked like a nail. That created a lot of spaghetti code.
[1] I still have a soft spot in my heart for Perl. I don't think it was an issue of "PHP is better than Perl", just that PHP was easier/faster.
Wordpress is an example of a PHP application that just works and deploys easily, but it also not using a lot of libraries. My take, and it may very well be wrong, is that the ecosystem is a nightmare in terms of deploying application. There's everything you could ever want though.
Of cause my experience may be down to the applications I tried to deploy.