
80% of the Web Powered by PHP (2017) - ashitlerferad
https://haydenjames.io/80-percent-web-powered-by-php/
======
devsatish
PHP is not that bad. I used Laravel to build out a PHP based web-app , it was
a breeze to build - great developer experience - Eg: Netbeans/Eclipse Syntax
editors are easy to use, composer was as easy as rails was. Most of my work
was on the JS part though (React/WebVR). Tests, Code Coverage, Deployment to
AWS, everything was smooth . This coming from a polyglot dev who built apps
with Scala,Python, Java and Ruby

~~~
paulddraper
I've used PHP (pre 7) at $JOB. It's not bad for hacking a project together. In
fact, it's kind of ideal. (Though I would personally pick Python.)

It is bad when working on a business-grade product with more than a dozen
engineers. Bizarre language choices and an intrinsic tendency towards non-
encapsulation seems to make even more spaghetti code than you'd find in Ruby,
Python, Java, etc.

~~~
JohnFen
> even more spaghetti code than you'd find in Ruby, Python, Java, etc.

From working on numerous large Java projects, I can say with real-world
experience that the logical equivalent to spaghetti code is very common with
Java. The difference is where the spaghetti is -- in Java, it tends to be
spaghetti inheritance and encapsulation.

~~~
juangacovas
Nice to see more of those "real world" words that confirms that everybody can
do clusterfucks (aka spaghetti code) in any language, given the proper time
and lazyness ;P

------
piotrkubisa
I think link should be changed to
[https://w3techs.com/technologies/details/pl-
php/all/all](https://w3techs.com/technologies/details/pl-php/all/all), because
it points to more actual results. On that page, we can see a diagram that
shows many websites has not been updated to work with latest PHP 7+, which I'd
say is quite shameful and/or method used by authors of this report to check
PHP version is not adequate (I guess it is now a common standard to hide
version of the used interpreter in a HTTP header, while it wasn't obvious todo
task when only 5.x was available). Additionally, I found it is quite wrong to
putting equal mark between PHP and Hack (HHVM) in section of "Popular sites
using PHP".

Edit: Fixed some language errors and typos.

~~~
teh_klev
> that shows many websites has not been updated to work with latest PHP 7+,
> which I'd say is quite shameful

Speaking as an ex-hoster here who had to look after a fleet of shared servers
running PHP (000's of sites) for 15 years, sadly life is not that simple in
the trenches. The major problem with PHP is breaking changes. Even within the
5.x releases there were enough breaking changes such that upgrading from say
5.3 to 5.6 could break a site. The jump from 5.6 to 7.x has enough breaking
changes to make you cry. I think there should have been a commitment to
maintain 5.6 for the next ten years, if only for security fixes.

Now I'm not suggesting that developers shouldn't go back and fix stuff that
breaks because the PHP folks removed/altered that functionality (with the good
intentions of encouraging more secure programming, for example), but there's a
labour cost and someone needs to pay for that time.

There's also functionality in PHP that shouldn't have been removed
(register_globals) but should have been defaulted to disabled. Sure
register_globals is insecure but what we saw were folks adding the same
functionality back, just google for "php emulate register_globals".

And don't get me started about the annoyance that was removing mysql_*
support. Those exact same insecure string concatenated queries are still being
executed via mysqli_* and the PDO libraries. In my experience, binning mysql_*
didn't make a damn bit of difference when it came to sql injection attacks.

Don't get me wrong, I admire the efforts of the PHP core team, but they made a
rod for our already sore support backs whenever a new release of PHP shipped
because of some fairly unnecessary BC's.

~~~
DannyB2
> The jump from 5.6 to 7.x has enough breaking changes to make you cry.

It's not just PHP. But Python 2x / 3x as well.

Just to point something out: this is one reason why Java is so well liked for
large enterprise code bases. They have been religious about backward
compatibility in new versions.

A 2nd principle I would advocate is that if there must be a breaking change,
it should be caught at compile time, not at run time. The project should fail
to build, and the errors point you to exactly where the source code problems
are.

Other language systems would do well to embrace backward compatibility and
build time errors over run time errors. IMO.

~~~
consp
> ... But Python 2x / 3x as well.

That was one of the lowest effort upgrades I ever did for my company (backend
services, no front end websites).

One of the other reasons Java is popular in big companies is the low effort it
requires to find people who can work with it.

~~~
fucking_tragedy
> That was one of the lowest effort upgrades I ever did for my company
> (backend services, no front end websites).

If your application does a lot of ASCII/unicode/raw string and byte
manipulation, the transition from Python 2 to 3 can be very cumbersome.

------
_RPM
This is slightly off topic. But PHP has a great devloper experience, in
general, now with vscode, and autocomplate, find all references, etc. But the
best framework out there is Laravel. It's great, but the maintainer doesn't
seem reliable. Every single release has some type of backwards incompaitible
change to it of which they don't document all the changes. So it's basically a
blackbox if you are to upgrade your laravel/framework version.

~~~
ficiek
The PHP experience was one of the worst experiences I have ever experienced.

~~~
_RPM
PHP is very fast. The tooling is great, and it's very easy to get started.
VSCode with the right extensions makes PHP development fun.

~~~
dcbadacd
D:

Which are the "right extensions" because what I saw was not "fun" at all.

------
mutt2016
I think this speaks more to people running lts versions of servers that have
php5 in repos.

~~~
jdhawk
Looking at you CENTOS

~~~
Spivak
But that's the value proposition of a distro like that. Write your app against
whatever is in the repos in the .0 release and get a stable ABI until the next
major release in a little over a decade.

------
osrec
PHP is a great because it lets you get stuff done. Easy to understand, deploy
and extend. Also, with the new reactive frameworks such as swoole, it can even
support situations where you need to service a very high number of
connections. We use it extensively at my firm and are proud to do so. A lot of
PHP criticism comes from developer snootiness and a fairly hefty survivorship
bias. PHP is good for a bunch of things - let's just be okay with that!

~~~
brianpgordon
Other programming languages "let you get stuff done" without all of the ugly
warts and rough edges of PHP. And the only survivorship bias involved is that
only developers with a high tolerance for terrible programming languages stick
with PHP so the community disappears into its own navel in an endless cycle of
awfulness. Calling this developer snootiness is like building houses with
stone hand tools and scoffing at the workers who won't join your construction
company until you buy some hammers.

~~~
osrec
Not really. PHP is not awful. It powers much of the web because it's actually
good at its job. What's your programming language of choice? I bet you will
find ample, justified criticism of it too.

------
vikaskyadav
That is mostly because of Wordpress

~~~
maxk42
According to WordPress, it's about 25%. [1] So it would mostly be not-
WordPress.

[1] [https://venturebeat.com/2015/11/08/wordpress-now-
powers-25-o...](https://venturebeat.com/2015/11/08/wordpress-now-powers-25-of-
the-web/)

~~~
liveoneggs
that is out of date- wordpress is up to over 33% of the web

[https://wordpress.org/news/2019/03/one-third-of-the-
web/](https://wordpress.org/news/2019/03/one-third-of-the-web/)

That's the _entire web_. It is staggering.

------
casper345
Recent (funny) Observation, I hear more non-programmers trash PHP than actual
programmers

~~~
mywittyname
Young programmers too.

I guess it's like how people trashed COBOL and Fortran when I was getting into
development. Then later in life, I come to find out that Fortran is ubiquitous
in engineering and is actually amazing for what it does.

------
combatentropy
I prefer PHP but as glue. Like my first-grade teacher taught us, a drop of
glue goes a long way. Too much glue makes a mess.

Unlike many programmers, I don't pick one of the Turing-complete programming
languages (PHP, Python, Ruby, Go, whatever) and try to write as much of my app
as possible in it. Because they are Turing complete, you really can write
everything in it. Because you can learn only so much, you are tempted to write
more than you should in that language.

But like I said, PHP is just a part of my stack, and I try my best to make it
one of the thinnest layers. The other parts are Postgres, Apache, and the
user's browser. I try to use each of those as much as possible. The server
operating system also plays a part, and I suppose my stack includes Bash.

Basically I try to do as much business logic as possible in Postgres. This
leaves PHP to do little more than glue the output of Postgres to HTML
templates.

~~~
sebastianavina
I prefer PHP as a whore.

Because we all abuse it, and is damn easy to make it work.

But at the end, we all feel dirty for using php.

------
liveoneggs
this site has tons of trends and is probably more up to date:
[https://trends.builtwith.com/framework/programming-
language](https://trends.builtwith.com/framework/programming-language)

they have tons of other metrics. To summarize PHP and Wordpress absolutely
dominate the web.

------
arendtio
Well, the question is why so many admins stick with PHP 5. My guess is that
due to the breaking changes that came with PHP 7:
[https://en.wikipedia.org/wiki/PHP#PHP_7](https://en.wikipedia.org/wiki/PHP#PHP_7)

~~~
merb
it is also shocking that they use php 5.5, which basically is unsupported for
two years.

Well PHP 5.6 is unsupported aswell, but it was supported till december 2018..

~~~
kijin
Ubuntu 14.04 shipped with PHP 5.5 by default, and it's supported until next
month. I don't know how well the maintainers backport security fixes from
newer versions, but at least technically it's still supported. The last
security update to php5-common on trusty came out only a few days ago.

End of upstream support is meaningless in a world where most servers run LTS
distros of one flavor or another. I've been telling my clients that they
should be able to rely on PHP 7.2 for a long, long time because it's the
default version in Ubuntu 18.04 and RHEL/CentOS 8, both of which come with 10
years of support.

------
rdevsrex
I use PHP everyday and it rocks for what it does when you use it with best
practices. The real problem is with small companies who won’t or don’t upgrade
their infrastructure on a regular basis.

Heck, even with Wordpress these days you could use it as an API source and
build a modern SPA website. It’s just getting over the inertia of intransigent
stakeholders.

------
RocketSyntax
Would like to see "sites" vs "webapps"

~~~
bigblind
That's quite a blurry line, though. How much functionality does a site need to
become a web app?

~~~
derefr
I would describe a web-app as “any website that can’t be replaced by a Static
Site Generator outputting to a public_html directory of a stock-standard
Apache 1.3 installation on a locked-down server that has no CGI-bin.” (So, the
SSG could output .htaccess files, and even files that contain Server Side
Includes, but can’t do CGI, FCGI/WSGI, PHP, or in-server Lua like OpenResty.)

Or, a simpler definition: a webapp is any website that you can’t effectively
host on your ca. 1995 ISP’s web hosting.

Many webapps where the “app” is purely in a CMS backend (e.g. most Wordpress
sites) are websites. Unless they include comments, in which case they’re not.
Unless those comments are JavaScript-embedded third-party (e.g. Disqus)
comments, in which case they are. :)

~~~
coolreader18
That's an incredibly narrow definition. Why does the backend's capabilities
matter? If a site has comments set up through its own backend vs through
Disqus, the UX will/could be pretty much the same.

~~~
derefr
Because we're talking about the backend-deployment+ops-jargon terms "website"
and "webapp", not their general usage. Words can have precise jargon meanings
_which are different_ in different disciplines. This is where ops people tend
to draw the line: a web _site_ is something you can deploy to e.g. an S3
bucket and it'll be fully functional, with no other dependencies that you have
to maintain for it. A _webapp_ is something that _does_ have such dependencies
that you need to set up and maintain—e.g. a database layer.

But even ignoring that, I also define the terms this way because of the prefix
"web." A webapp isn't "an app on the web", but rather "an app powered by the
web." An entirely-offline JavaScript SPA that is just _served over_ the web,
_isn 't_ a web-app. It's just a program that runs in a browser, just like a
Flash or ActiveX or Java applet is a program that runs in a browser. (Is a
Flash game a "web game"? It's usually considered a _browser game_ , but that's
not the same thing.)

We already have a term for the thing that {Flash, ActiveX, Java} applets are:
apps. Offline JavaScript SPAs are just apps too. We don't need to add the
prefix "web"; it's meaningless here. In any of those cases, if you took the
exact same program, and slammed it into an Electron wrapper instead of into a
domain-fronted S3 bucket, it would clearly not be a "web app" in any sense.
Your SPA would just be "a JavaScript _app_ that uses a browser DOM as its
graphics toolkit." Well, that's just as true before you put it in the Electron
wrapper.

So "web app", then, has a specific meaning, above and beyond "app." You need
something extra. That something extra is a backend, which your browser—driven
by the app's logic—interacts with _over the web_. That's what makes an app "a
web app." (This definition intentionally encompasses both server-rendered
dynamic HTML, and client-rendered JavaScript SPA apps. You don't need a
frontend _app_ ; you just need a _web backend_ that something is interacting
with. That something can be the browser directly, by clicking links and
submitting forms; or it can be a JavaScript frontend, using AJAX.)

A "web site", then, is a "web app" without the "app" part. If it's clear in
the above definition what an "app" is, and what a "web app" is, then you can
subtract one from the other to derive a definition of a "web not-app." That's
a website: something powered by a web backend, which does not do any app
things. If we decide that "app things" are basically "storing state", then a
"site" is an "app" with no persistent state.

And since the definition of "web" here is about a backend, then the difference
between a "web app" and a "web site" (a web not-app) is probably defined by
the properties of the backend. So the difference about the ability of the web
backend to store state. So a "web site" is a "web app" where the backend does
no app things—i.e., stores no state.

------
4FNET7
What about PHP RoadRunner, PHP Swoole, ReactPHP, ... ?

~~~
bufferoverflow
I recently benchmarked Swoole. It's insanely fast compared to regular PHP.

It's currently taking #4 place in the famous framework benchmark:

[https://www.techempower.com/benchmarks/](https://www.techempower.com/benchmarks/)

------
EGreg
People have asked us why we use PHP in 2019, sometimes scoffed at us.

This is why.

~~~
astazangasta
"This" being "everyone else is doing it"? Doesn't seem a great reason.

~~~
brightball
PHP has it's flaws but it has it's strengths too. For low traffic sites or
more content heavy sites that are going to be heavily statically cached
anyway...it's REALLY hard to find cheaper hosting.

PHP scales down better than just about any other language out there since most
of the rest of them have to boot up.

~~~
brianpgordon
It seems like for that kind of site what you're really looking for is
completely static content behind a CDN. Your average blog or corporate
homepage doesn't need to be dynamic at page-load time. You can generate the
pages with a template engine when you update them, and then serve up the
static content.

If you want to power some little dynamic things like blog comments you can run
a custom microservice in a less awful programming language, or go with some
hosted cloud option like AWS AppSync or Aurora Serverless.

~~~
mgkimsal
So one should increase their reliance on third party services, potentially
having their small site requiring two or three external services (potentially
at different providers) instead of just having it all in one package (in PHP
or anything else)?

~~~
brianpgordon
So one should dynamically generate the page's markup for every single page
view? With the attack surface that comes with exposing your PHP site to the
public internet? Are you going to conscientiously check for security updates
on your server? Are you going to trust whatever CMS you're using to win the
whack-a-mole game of patching vulns (and god help you if it's Wordpress)? Are
you going to stand up and maintain your own database server? Can you scale up
capacity if you need it? Have you thought about backups?

The "all in one package" solution is a lot more complex than you make it
sound. I would argue that much of the 80% of the web powered by PHP would be
well-advised to utilize cloud services.

------
dep_b
PHP 7: didn't use it too much yet but things definitely have been improving on
the syntax side! But doing PHP is 80% awful jobs and 20% cool companies so
it's not something I would put too high up on my resumé.

------
matthewfelgate
I'd like to see websites excluding WordPress.

~~~
cturhan
It's not just wordpress. There are magento, joomla, drupal...

------
paulcarroty
Right time to learn Node.js :)

------
smrtinsert
6 months coding php. Never again.

~~~
frfl
Care to go into some details?

------
onion2k
This is wrong.

What they're measuring isn't the number of websites that use a particular
technology, but the number of websites that _report_ they're using a
technology. In the case of PHP that means expose_php is set to true in the ini
file, and Apache is configured so use "ServerSignature On". Those are the
defaults, and they're arguably _bad_ defaults because gathering information
about a target is Hacking 101. You definitely shouldn't be giving away version
numbers unless you're _really_ good at patching stuff on day 1.

What this survey means is that PHP gives away data about your web apps
internal structure. Most other web technologies don't do this. The defaults
are more sane. They're not adding x-headers to every request about what
versions of which technologies the server is running.

If you dig a bit you'll see this line in the source data: "PHP is used by 79%
of all the websites whose server-side programming language we know."
([https://w3techs.com/technologies/overview/programming_langua...](https://w3techs.com/technologies/overview/programming_language/all)
under "How to read this diagram")

tl;dr PHP server admin need to get better at security.

~~~
tyingq
Assuming most are running WordPress, Drupal, etc, hiding the fact that you're
running PHP is a bit fruitless. Those platforms are dead simple to identify by
the URL paths of components, like /wp-content/whatever and other similar
clues.

I do agree that exposing the version isn't a great idea.

~~~
Theodores
[https://github.com/AliasIO/Wappalyzer/blob/master/src/apps.j...](https://github.com/AliasIO/Wappalyzer/blob/master/src/apps.json)

Handy reference from the Wappalyzer browser extension for you.

