CodeIgniter is still popular and a lot of developers have no clue about namespaces and composer usage. It will really take a _long while_ before php7 becomes commonplace.
We currently run on Debian stable and don't upgrade any packages beyond what Debian is supporting. In all likelihood, we won't be using PHP 7 until the next major Debian release, which I believe is scheduled for April 2017.
Regardless, we still have to support clients that are running older instances of PHP on their GoDaddy shared hosting. If it's not EOL, we can't justify not allowing them to use it so we're stuck with 5.5+ for the time being.
The recent releases of Magento 2.0 and Drupal 8.0 should help move more sites to modern versions of PHP, but there is a lot of work still to be done on contrib modules to get full functionality out of M2 and D8
It will depend on hosting companies for some public websites and sysadmins for internal business apps. Ironically the sysadmins I know will be the hardest people to convince, for some reasons.
that's basically why as much as I can , I chose solutions with no dependencies when I'm working on apps for internal use (like Go,Nim,..). It solves a whole lot of issues. I just can't stand having to convince someone else to do his job in order to do mine.
I doubt any of those developers are ever going to switch what they're already using unless they are forced by some external factor.
The more serious factor is: if you're on Hackernews, you're at least Elvis or even Einstein. Mort is out of reach for most internet media for programmers.
What PHP added was primarily ease of use with the ability to deploy code simply by creating a single file, suitable for mass deployment at ISPs in the era where everyone used shared servers, and the combination of comparative ease of use with enough performance to do serious projects. Cold Fusion was also easy but didn't support things like persistent connections (read: order of magnitude slower) and the core language was very, very slow and also quite limited and buggy. You could find much faster options if you wanted to build, debug and deploy a conventional language like C++ or Java but the cost and risk was so much higher that this was unfavorable unless you really needed performance.
EDIT: if you want a snapshot of what the 90s web was like, http://philip.greenspun.com/panda/ was quite popular in the day. I know at least one well-known business which still has a revenue-generating website built in TCL, too…
By '97/'98 there were multiple vendors vying in this space - htmlos and ihtml are two names that stick with me, but there are some others I remember but can't recall names. And ColdFusion and whatnot, but... Perl and PHP were the big freebies, even by '97. ASP had speed on its side, but PHP already had convenience and price by '97, and it's gained ever since then. re: Java as server-side web platform - was outside my radar much, but the majority of people I worked with, even Java enthusiasts, didn't give it much credence before '99 - I don't think the infrastructure support was quite settled, and it was too 'wild west' for my colleagues (bunch of other reasons too). (IIRC, CF didn't support user-defined functions for several years, leading to much more difficult to maintain code than it should have been, but... memory gets hazy after 18 years).
But... PHP and Perl were free and largely "good enough" for enough of the problems most people were facing which is why they gained as much foothold as they did. ASP and CF both required a fairly hefty outlay and setup that you generally wouldn't be able to pay for without working in a corporate gig.
I'm happy to report that I got better at making technology choices.
I think my first was perl/cgi in Jan 96 - not a full "web app" but I could read and write data via web forms to a database (msql IIRC). Feb 96 I know I was doing some PHP/FI, though still did a lot of Perl for years, mostly because that's what most hosts supported. For my own stuff, it was generally PHP even then when I had a choice.
PHP really was responsible for the dynamic web. It had enough community support to enable newbies to wrap their head around the mind-boggling shift to dynamic server-side websites, and it became commonly provided with cheap or free shared hosting.
A big reason why it succeeded was because it was possible for people who only understood HTML to transition, since a PHP file could be nothing but HTML to start with, and people used a lot of templating rather than start from scratch with code that echoed out HTML. With things like Perl, it was not an HTML templating script first, and so that made it less streamlined and simple for the task of making websites.
Before PHP became widespread in the very late 90s there were many options for dynamic apps. I worked with ISPs which offered CGI or SSI even on cheap / free plans. Sure, it was ugly but a ton of people got what they needed done by going over to Matt's Script Archive and finding something they could hammer into shape. Before antique PHP apps, the security cliché was formmail.pl & a slew of long-forgotten guestbook / forum scripts.
I'm not saying that PHP didn't help considerably, only that it was very far from first. I remember having to make the case for using PHP 2 or 3 instead of many of those alternatives and it was based on cost and convenience, not the ability to do anything new.
You sound like an older hardcore nerd. You're from a different planet. What was going on in your circles was not at all a reflection of the web on a whole. Most people didn't even use ISPs in those times, they were on private systems like AOL. The dynamic web we know today, where almost every website is not static HTML, is because the majority of people making any little website had access to PHP, and free tutorials to learn.
Go search internet forums: "how i script PHP mail?" folks won't use the latest best practices.
And there were dynamic webpages before PHP, PHP just gave a ton more people access to them by easy installation, configuration and most importantly, development/feedback cycle.
And it's not elitism, it's a fact that many developers are Mort in all situations. Yes, we're all Mort from time to time, but some people are just Mort :)
How often do you check 100% of the APIs you use for every kind of thing you develop (including shell scripts) for deprecation warnings or bad practice warnings?
I, for one, know that I don't. Except for NASA software, I don't think it's feasible.