
PHP in 2020 - kyriakos
https://stitcher.io/blog/php-in-2020
======
epicgiga
PHP is a fantastic language, and my personal favourite. It was the first
language written with web serving in mind. It is packed with features due to
all the adding to it over the years, meaning you can write code how you want,
no how they want.

What it also acts as is a good barometer of dev mentality. When a dev declares
PHP is a [expletive] language, he's telling me how he's going to be to work
with, how he's going to engineer his work, and how concerned with adding value
to the business he's going to be versus playing with "hot new tech". Even if
it's for a .NET role.

The plurality of the internet is PHP back, html/css/js front. Those who thumb
their nose at that are profoundly arrogant, and probably currently
experimenting with their 8th new framework for the year.

Junior devs do as they're told and don't form opinions.

Mid devs know enough to be dangerous, run their mouth on everything, and bad
mouth anything that isn't precisely their opinion or something they personally
like.

Senior devs see the big picture, have realised the folly of their earlier
ways, have a healthy respect for practical reality, and are more concerned
with codebase integrity than in if it contains "hot new tech" (fuckarounds).

This is why it's critical to have truly senior devs at the top of the
hierarchy, as otherwise there's no one to suppress the mid level devs, who
will in turn mislead the juniors.

~~~
dijit
I don't doubt that PHP is becoming (has become?) a decent language. Especially
with frameworks such as laravel which are mature and clean.

But PHP has a legacy, lots of bad PHP code exists already, bad practices are
usually the first result on google and very "lazy" developers who never
learned anything else exist and this muddies the waters very much when talking
to people who prefer to build new things in PHP.

There's also the nitpicky fact that the old way of running PHP was that every
page request runs the code from scratch, meaning you have to build state each
time which is profoundly expensive and inefficient, although I believe people
rarely do this anymore it's still definitely the default for most PHP projects
I've seen. (both FOSS and proprietary).

I don't like your overgeneralisation about junior/mid/senior developers, the
lines are super blurred in the real world. (I say this as a non-developer who
works with developers)

~~~
epicgiga
Pardon me, but how would you know as a non-dev?

~~~
dijit
Fair question, I suppose.

I'm in SRE, so I work closely with developers and programmers who build
business logic, in fact I am surrounded by pretty much exclusively that except
for a small supplement of testers and technical managers.

So, I have some exposure.

That and the very plain fact that the mindsets that you would use to delineate
between "senior" and "mid" bands are just traits that could be apparent in
varying degrees between people of any level.

I've had mid-level developers identifying business needs on a macro level with
a well broken down bite-sized methods of achieving what they set out to.

I've had senior developers "informing" me about operating system semantics
which were just not true.

You can be senior in some areas and mid-level/junior in others. This is true
across the whole spectrum.

~~~
epicgiga
Precisely, people should refrain from informing on topics outside their area
of expertise. Pretty rife in western companies, "too many cooks" etc, must be
the democratic mindset that every voice counts equally.

~~~
dijit
If this is a comment about me suggesting that your overgeneralisation is
unwarranted because it is outside of my direct field then let me just say it
this way: It is always true that trying to define behaviours of seniority is
an overgeneralisation. It does not depend on the field unless there are formal
qualifications, and even then it's tricky.

------
la_fayette
I teach web development at a university. We have used, java, javascript,
python and php for a basics course in webdev.

Php has built in web features and one doesnt need more than a php interpreter
(considering the built in web server as well) to get started. For all other
languages i know of, there is quite a process to get started (e.g. start with
python flask one needs a package manager, environment variables, command line
experience, ...). Php is a web native language and great for learning and
getting started.

Considering professional development
([https://en.m.wikipedia.org/wiki/Programming_languages_used_i...](https://en.m.wikipedia.org/wiki/Programming_languages_used_in_most_popular_websites))
it seems that it doesn't matter what language one chooses, various different
stacks are used by the most popular websites..

~~~
Kwantuum
> for all other languages i know of, there is quite a process to get started

It's funny that you included javascript in the list when you can literally
just type javascript code in an html <script> tag and open it in the browser
that comes with your OS.

You quip at flask for requiring "command line experience" then talk about
PHP's built-in web server that's also a command line tool.

And let's be realistic, if you're using php without a package manager, you're
either no doing anything serious or you're reinventing the wheel, and you will
need to get comfortable with the command-line sooner or later anyway.

I will say that PHP is probably the the most frictionless server-side web-
development language to get started with, but it's not by a huge margin.

And considering that in web-dev you're gonna need to learn javascript anyway,
I'd probably consider it to be the best introductory language.

~~~
nkozyra
> It's funny that you included javascript in the list when you can literally
> just type javascript code in an html <script> tag and open it in the browser
> that comes with your OS.

Let's be fair: you're going to be very limited in terms of the type of web
site you can make with this approach compared with a PHP app via web server

~~~
bpfrh
Is he?

Somebody built a photo editing app in JS which runs locally in your browser.

[https://www.photopea.com/](https://www.photopea.com/)

~~~
epse
Of course, such things are perfectly possible and for an image editor I'd
consider in-browser js superior to anything but native apps.

However, consider this, you want an app that has to use a database, you can't
store everything on the client or use things like Dropbox integration. Plenty
of situations where you want that, but that just can't be done with clientside
js without also making your database acces keys and encryption keys available
to all. So all in all, it depends on what sort of app you want to build or
form your course around

~~~
bpfrh
Or I just use node on the server side and write the server part also in js?

This was not about building anything sensible, but just to counter the point
that js allows you less than php.

I think today the only big language with is a pain to setup is perl, java and
sometimes python, the rest is just a matter of ecosystem, needs and personal
taste.

------
timw4mail
PHP is, and always has been a practical language.

7.4 has been especially exciting with the introduction of FFI. Few other
languages even have runtime FFI, and in most cases you have to do the binding
stuff in C.

I even ported a terminal-mode text editor (which uses FFI somewhat) from C to
PHP: [https://git.timshomepage.net/timw4mail/php-
kilo](https://git.timshomepage.net/timw4mail/php-kilo)

I would guess most of the PHP haters got stuck working on Wordpress, or
someone's old business app, or they just hate PHP because it's popular to do
so.

~~~
wahern
This new FFI support intrigued me. But looking at the source, it's just a
wrapper around libffi. I don't know of any language that _doesn 't_ provide a
wrapper around libffi, though not all provide it as a default-installed
module. PHP's bindings also provide a simple YACC-based parser for
automatically extracting simple size and layout information from C header
files, though this is easy enough to write in-language (heck, there's a full
C99-compliant LPeg parser). Notably, PHP's parser, like LuaJIT's, doesn't
handle the preprocessor, so its useless without resorting to a separate
program (e.g. cpp(1)) if you want automagic bindings.[1]

So, kudos for PHP for doing this. Not exactly a game changer, though. The
performance cargo cult dislikes libffi as it can be relatively slow compared
to an inline binding (static or dynamic) due to the need to copy input
parameters (by reference, not by value) to an intermediate data structure on
every invocation, and due to the fact that some JIT'd languages can JIT
through the external function invocation (LuaJIT can do this, IIRC). It's
ridiculous, but it is what it is; libffi effectively "taints" FFI support as
non-native, which is a death sentence these days.

I think PHP is a horrible, cobbled together language. If the core maintainers
had a strong grounding in language theory, design, and practice, they do an
impeccable job filtering it out of the final product. It's been this way from
the very beginning, and by everything I see today, remains so. That said, it's
the first thing I turn to when I need to put up a simple web page with server-
side logic! I have absolutely no desire or tolerance to fsck around with CGI,
modules, packages, or anything else, and the PHP ecosystem Just Works out-of-
the-box on every system (Linux, BSD, Windows) I've ever tried it on.

[1] Such parsers are kind of useless. Better to provide built-in sizes for
core system data types like time_t and then, optionally, provide a simple,
quasi-C grammar for expressing redundant definitions that you parse inline.
Which is presumably how such parsers are used in practice, notwithstanding the
pretense. Plus, I run all my web applications in jails (chroot, pledge,
seccomp, etc). If system and library headers are visible at runtime, something
is broken. If someone really wanted to go the extra hundred miles for proper
automagic bindings, one could use ELF symbol information, for example debug
symbols (e.g. DWARF) or simpler symbol info (e.g. BTF on Linux, derivative of
Solaris' ABI metadata, which was directly supported by OpenBSD before the
Linux project got started).

~~~
rawoke083600
>I think PHP is a horrible, cobbled together language. If the core maintainers
had a strong grounding in language theory, design, and practice, they do an
impeccable job filtering it out of the final product.

urg and then ?? We will have just another Python, C, .Net or Go, which are all
good for some ppl and some things.. Sometimes you just need some outside the
box thinking...

~~~
wahern
None of PHPs warts _benefit_ the language. At best they benefit the
implementation, which is presumably why it happens. (Various inconsistencies
and warts in Python and JavaScript can be readily traced back to
implementation barriers, as well.) But languages like Lua show that PHP could
have implemented all its features wart-free without undue implementation
complexity or any runtime cost as almost no language element in PHP was added
and implemented until long after it was added in other languages, including
Lua, which is a fraction of the size of every major comparable language out
there and generally faster to boot.[1]

PHP is great despite itself. But great it is. You can say that about many
popular software tools, but PHP is unique in effectively going unchallenged in
its domain, iteration after iteration, decade after decade, quirk after quirk.
ColdFusion was the only real competitor, but it died when they tried to
replace CFML with CFScript. (Well, also because ColdFusion was proprietary.)

People believe languages become popular because of their design features, but
if that were true we'd all be writing in Haskell and Scheme with shims for
C-family, imperative-style syntax. In truth language features, including
syntax, are usually driven by implementation barriers that arise early in a
language's evolution, starting with the choice of GC or no GC. The language
succeeds despite itself. Lua is a uniquely elegant language precisely because
the Lua authors eschew backwards compatibility between every significant
release. Every major release of Lua (which looks like a minor release if you
expect SemVar) involves a wholesale refactor of the implementation, and syntax
breaks are judiciously allowed (i.e. more weight is given to implementation
complexity than to compatibility convenience, relative to other languages). It
drives people nuts, but the product of this process is the only reason one
comes to use Lua in the first place. Functional language families have a leg
up in this regard, but ultimately it still plays out the same way, which is
why not all functional languages are the same. PHP stands out for having no
legitimate excuse for its quirks beyond, "we don't need to bother because
we're unchallenged [for myriad accidental reasons]."

[1] For example, JavaScript's lexical scoping quirk derives from its original
half-baked implementation. But the Lua authors published a paper many years
before PHP got closures (possibly more than a decade before?) that explained
their technique for implementing proper, quirk-free lexical closures in just a
handful of lines of C-like example code. And Lua's compiler compiles to
bytecode as it parses, much like early C compilers, so it doesn't have the
benefit of arbitrary lookahead or multiple passes. Someone elsethread asked
why PHP (and some other languages) require explicit variable bindings for
closures. People like to say that they _prefer_ this syntax, but regardless of
whether it's preferable, the fact of the matter is that in practice it happens
because it's easier to do it that way, especially for statically typed
languages. (Except it's not necessarily easier, as Lua shows.)

~~~
scq
> the Lua authors published a paper many years before PHP got closures
> (possibly more than a decade before?) that explained their technique for
> implementing proper, quirk-free lexical closures in just a handful of lines
> of C-like example code

That sounds interesting, do you have a link to that paper? (I couldn't find it
with a quick Google.)

------
CiPHPerCoder
A lot of people hate PHP because they don't think it's possible to write
secure PHP code.

Sometimes companies enshrine this ignorance as official policy, and their
knowledge of PHP security is as shallow as "php.ini hardening".

When anyone encounters such ignorance, point them here:
[https://paragonie.com/blog/2017/12/2018-guide-building-
secur...](https://paragonie.com/blog/2017/12/2018-guide-building-secure-php-
software)

Or for more general code quality complaints:
[https://phptherightway.com](https://phptherightway.com)

I'm looking forward to PHP 8, and beyond. Mentalities that were only relevant
in PHP 5.1 (or earlier) are outmoded and should be laid to rest.

~~~
rvz
Absolutely, most of all your points can also be applicable to the same reasons
why many programmers complain in their hundreds of thousands about how much
they hate C++ due to its footguns and sheer complexity which they assume that
they have to literally learn everything in the language and from their bad
experiences from C++ 2003.

So Rust becomes the most loved alternative to C++ but is also equally just as
complex, slightly harder to read, twice as frustrating due to some having bad
'anecdotal' experiences fighting with the borrow checker and a large lack of
post-1.0 libraries. Those wanting to "Rewrite it in Rust" from a C++ code base
will be quickly disappointed...

Perhaps the answer to both the PHP, C++ and Rust issues from programmers is
always a reply saying "You'll get used to it"...

------
krick
Wow. I'm honestly surprised by the amount of people (on the HN!) in 2020,
thinking PHP is some pre-historical language clearly inferior to... I'm not
even sure _what_. JS? That would be funny.

(It feels like I'm defending PHP now, which is feels weird, because I can go
on for hours talking about the stuff I hate about PHP. But there is a
difference between hating it for problems it actually has, and just not
treating PHP as seriously useful modern tool which it definitely is.)

That aside, I cannot really treat seriously author's recommendation of Amp,
ReactPHP and such as a solution for async. Don't bring up HHVM either. There's
no real solid support for async/await in PHP, not even in the form Python has
for quite a while now. And for me, it might be the biggest problem it has
right now, which seriously hurts in some applications.

~~~
CiPHPerCoder
> There's no real solid support for async/await in PHP, not even in the form
> Python has for quite a while now.

I'll second this. Async/await support in PHP is _at best_ an ugly hack.

I don't know if we'll ever get first-class async/await support since there is
no event loop in the PHP runtime, and because of how PHP works (build and
teardown on each HTTP request).

> And for me, it might be the biggest problem it has right now, which
> seriously hurts in some applications.

What problem are you trying to solve where a lack of async/await would help?

~~~
krick
I've encountered dozens, maybe hundreds of problems where it was actually
something that would matter. Here's one example. Consider you need to process
lots of requests, that require making multiple requests that take a long time
to finish (like 10-30 seconds) and you need to do it nearly in real-time.
Given there's no sane multi-threading in PHP as well, you end up building your
own parallelism support, which requires running lots of workers. Now, every of
these workers does some pre-processing, makes a requests and waits for
multiple damn seconds, to get the result back, make some computations and get
to the next job. Consequently, to handle the same number of requests/sec you
need much more workers, which has a lot of overhead, which results in needing
more servers.

Sometimes you can use CURL to just make multiple similar requests in parallel
and call it a day, but in practice I rarely could make use of it (consider
that service you need to call might require some fucked up protocol, like
SOAP, so you best option would be to rewrite SOAP client using CURL with
parallel requests, which is not fun at all).

At that point you really start thinking some (any?!) other language would be a
better fit for the application, but you have tons of _very_ domain-specific
business logic written in PHP that you'd need to rewrite for that app, as well
as a team of PHP-developers that are not necessarily ready to learn whatever
you have in mind, sooo...

~~~
meritt
> to handle the same number of requests/sec you need much more workers, which
> has a lot of overhead

When doing multiprocessing, it's advisable to fork() instead of creating fresh
processes (or launching them in containers etc). As long as you preload the
necessary libraries/modules in the parent process before the fork, children
will reference the same memory in a copy-on-write fashion. It keeps overhead
extremely low.

This [1] article is for the Unicorn (ruby) webserver but the way it explains
forking, signals, and pipes for inter-process control it's absolutely
illuminating. These techniques are applicable to any unix-based applications,
including php daemons.

[1] [https://thorstenball.com/blog/2014/11/20/unicorn-unix-
magic-...](https://thorstenball.com/blog/2014/11/20/unicorn-unix-magic-
tricks/)

~~~
krick
Thanks, that's a nice idea. Kind of hard to implement in the setup I'm
thinking about right now, but, still, that never occurred to me, so this is
something to consider.

But, of course, it doesn't replace proper async/await. First of all, there are
other situations where this solution wouldn't apply. And even in described
scenario it isn't ideal. For starters, pre-loading everything before fork is
really easier said than done: quite often data you need to fetch depends on
the result of request, but just so happens to be very much reusable between
multiple jobs. Then, it complicates the code quite a bit, makes to constantly
keep in mind across the whole codebase things you wouldn't really want
developer to think much about to start with. Additionally, it makes DevOps
harder as well: people want to rely on LoadAvg (which is very unreliable
metric, but explaining this to people every time is not what makes for a
friendly environment) and multiple jobs doing nothing just waiting for I/O to
finish sky-rocket it. Then some DevOps tools (you don't necessarily know about
because of department communication) try to be smart by relying on loadavg and
start _actually_ breaking things.

------
open-source-ux
Although I don't use PHP, I'm impressed by its staying power and the
improvements in speed (which are substantial compared to other dynamic
languages). It has almost universal support amongst web hosts. It can be
deployed by simply uploading your code to a directory on your web host. It's a
widely criticised language, but still accounts for the vast majority of server
side code (80% according to some sources).

And in 2020, it's still the only language that gives your users a relatively
easy method to self-install web apps or products. (Sorry, but Cloudron,
Sandstrom, Docker etc will never match your customers definition of 'easy'.)

Having a ridiculously easy web app installation process for servers would
unlock countless opportunities for developers to reach more users or
customers. PHP is closer than most. No other language has tackled it (or
cares).

This is an excerpt from a blog post by programmer Jeff Attwood:

 _" If you want to produce free-as-in-whatever code that runs on virtually
every server in the world with zero friction or configuration hassles, PHP is
damn near your only option. If that doesn't scare you, then check your pulse,
because you might be dead."_

To broaden choice, Attwood argues we should:

 _" build compelling alternatives and make sure these alternatives are equally
pervasive, as easy to set up and use as possible."_

That was written in 2012 ([https://blog.codinghorror.com/the-php-
singularity/](https://blog.codinghorror.com/the-php-singularity/)).

It's 2020 and none of the alternatives are 'as easy to set up and use as
possible' for server-side installs as PHP. Why?

~~~
cutler
Because the industry is obsessed with over-engineering. React and Angular were
originally developed to power the likes of GMail and Facebook. Now the
simplest of sites have to be redone as SPAs simply to support the
React/Angular/Vue industry. With deployment it's even worse. Now we have to
wrap our simple PHP/Ruby/Python apps in a goddamn virtual OS. Kubernetes and
Docker were originally designed for managing massive fleets of servers but now
every startup with a 2-bit website seems to think they're missing out if they
don't wrap their code in all this infrastructure. Chef and Puppet were good
enough for most jobs a few years back so why the obsession with Docker and
Kube* ?

~~~
systematical
I agree, though for local development environments docker is pretty handy for
getting the full stack up. Especially if you just came aboard.

But this is the name of the game. More and more complexity. I am not sure how
green engineers manage to learn everything. Woof

------
dpau
I'm fairly language agnostic. What keeps me working in PHP is the Laravel
framework, with all of the application plumbing and core functionality built-
in and tested for me, so all I have to do is write the code specific to my
application. Every once in a while I search for other frameworks but still
haven't found anything that competes.

~~~
kugelblitz
I also like Laravel, though nowadays Symfony wins it for me. But it's probably
also a matter of taste.

Doctrine's DataMapper vs. Eloquent's ActiveRecord pattern and the use of
configuration in Symfony vs. convention in Laravel (e.g. facades) are my 2
main pain points with Laravel.

But having 2 big frameworks is awesome, both are upping their game constantly
and the whole ecosystem is benefitting. (E.g. I use Laravel's Homestead for
Symfony development, but I might also use Blackfire.io to improve Laravel
performance).

~~~
cdolan
It’s possible to use a data mapper in Laravel though, and it works very well!

------
slifin
I think PHP suffers from the java migration, we now write code like this
[https://github.com/aran112000/Advent-of-
Code-2019-PHP/blob/m...](https://github.com/aran112000/Advent-of-
Code-2019-PHP/blob/master/Day01/Day01.php) when functions in a namespace would
have sufficed

It seems like collectively developers are patting themselves on the back for
putting the same old crap code in classes, as if putting data into a change by
reference data structure is a good idea

Personally I'm trying to migrate out to Clojure where mutation is hard and
controlled by default & we don't pretend modelling reality with a tree of
nouns is a good idea

~~~
pas
Classes are/were thought as awesome because you can do dependency injection
via providing an object, but you can't easily do that with just providing a
different implementation namespace.

That said, maybe PHP is not the language where you need to do DI. Just have a
few different config files around, do the includes and wiring there and that's
it. And hope for the best. (After all there's no compile, no checking of
interface correctness with any kind of DI either.)

------
darknoon
It's a shame that Hack didn't replace PHP in general use. I didn't see a
mention in the article, but it was created to be exactly this
safer/faster/more elegant version of PHP. For example, it has a broad type
system including generics.

My first decent sized codebase was web site for my high school in vanilla PHP.
It was a total mess (mostly due to my lack of experience and the need to
support Netscape 4.7). I understand that some PHP apps are good, though I got
burned by WordPress vulnerabilities enough to swear it off.

I wrote a little code in Hack while at fb, and the incremental typing was
slowly evolving a messy codebase to some kind of order.
([https://hacklang.org](https://hacklang.org))

~~~
timw4mail
Wordpress is not PHP. Wordpress would be just as bad in Hack.

~~~
Implicated
Seconding this.

As someone who built (5 years ago now) and maintains a client application that
runs along side a Wordpress/WooCommerce shop of pretty high volume - it's
absolutely mind blowing to me the kinds of decisions that
Automattic/Wordpress/WooCommerce make... from a code and operation viewpoint.

------
jimatlampio
I should probably get around to making a ShowHN, but my co-founder and I,
having worked with loooots of clients that are still very actively working
with PHP code bases (sometimes even still in datacenters!), aggregated and
productized our "dream" stack as a PHP PaaS. Please check it out, kick the
tires, and let us know what we forgot!

[https://www.lamp.io/](https://www.lamp.io/)

~~~
ryanmccullagh
Interesting project. And it's great to learn about your company. My project,
Amezmo [0] is providing a similar service, but focused exclusively on php
hosting along with continious deployments and managed databases. We bundle
deployment and hosting. I've been working on this since 2018.

[0] [https://www.amezmo.com](https://www.amezmo.com)

~~~
jimatlampio
very cool, I like your design eye better than mine!

I think the overall market is huge here, plenty of room for both of us (and
fortrabbit). The EIG family of companies and the 5.6 "issue" is creating a
giant market for next-gen-php hosting.

------
selfsimilar
I have a love/hate relationship with PHP but it has undeniably gotten better
than its reputation would imply. That said, I think that regardless of the
language's continued improvements its reputation will continue to suffer
simply because it IS so easy to write and deploy code. Any sufficiently
popular and widely supported web language will be the most common entry point
for new coders and entrepreneurs who learn just enough code to get that MVP
out the door. They will blog about their successes and add to the the number
of 'not serious' coders putting poor quality code out in the world. If Python
or Go were this easy to deploy, we'd be see their reputations suffer as well.

~~~
oaiey
Very true. It is the same with Basic.

------
skor
Can anyone suggest anything that is superior to PHP in its development cycle:
save file.php = instant result? As far as I've seen, everything else needs to
restart a server, obviously much slower.

What about its die-hard intention of fulfilling a request no matter what? What
about autoloading? And what about the amount of things you can do in vanilla
PHP, no libs, no extensions.

Hey i've worked with it for some time and sure, its got its nasty things, like
gotos :)

~~~
TylerE
Basically any other framework/language will have some sort of dev-mode
autoreloader that will restart everything faster than you can switch tabs.

~~~
skor
yeah, I know, but PHP does not even need that. That's the point.

~~~
TylerE
It's not an actual advantage, and PHP's "throw the world away" execution model
is so so dumb.

~~~
justapassenger
It adds a lot of complexity to write performant code (you basically need
another middle layer), yes.

But it also has some security benefits - with that model it’s harder to have
exploits (as in your request you don’t carry over any other state), session
swaps, no need to care about concurrency, locks, etc.

It’s by accident, but it’s a real benefit of php.

~~~
stickfigure
_with that model it’s harder to have exploits_

The PHP community's track record on security is abysmal compared to all those
other environments that don't throw away the world.

~~~
justapassenger
Security record is due to enormous popularity, low barrier to entry and some
questionable/archaic design choices. But clean state at start of each request
is clear security advantage.

I can have a car with super safe airbags, that does horrible in crash tests.
That doesn’t make those airbags bad.

------
pjmlp
I used to be on the hate side and kept searching for alternatives for my site,
until I decided to actually spend some time learning PHP best practices.

Quite happy that I took that route, and that I was able to keep getting the
language and eco-system improvements along the way.

Modern PHP is quite good for the context of building web sites, its original
purpose anyway.

Languages don't need to be good at every domain.

------
axegon_
PHP was intended to be a templating engine and nothing more. It's the
community that pushed it in that direction even though that wasn't the
creator's intention. And though that has lead to some bad decisions, let me be
the one to say it: though it is by no means a good language, it's far not the
worst. Surely, dive into most other dynamic languages and you will quickly
want to stay as far away from php as possible. And in the modern day and age
if I were to start any project from scratch, regardless of what it was, I
can't think of a single reason to use PHP over most other available options.
As a matter of fact java and javascript are the only two languages I'd avoid
more than PHP. Java for all the annoying boilerplate code you have to deal
with as well as the incredibly strict way of how you need to structure your
application and javascript because it's horrible in every way - syntax, type
system, ecosystem, npm is probably the worst thing to ever come out of
mankind. I think this might be the result of a small number of js developers
who were above average and wanted to prove the "haters" that javascript can do
more than juggling dom elements. I can probably write an entire book of why
both java and javascript are horrible languages but that's not the point here.
PHP has evolved and while I can't really find a single vallid reason for using
it in 2020, other than legacy systems or maintaining something that isn't
worth the effort doing from scratch, it isn't the worst language out there.
Certainly not as horrible as people portray it to be.

~~~
rhacker
I guess those are personal preferences. I would rather use typescript and Java
moreso than PHP, Python, Ruby, C++, C#, etc...

Not exactly sure what exactly is specifically wrong with npm, have you tried
yarn?

~~~
axegon_
Both tpescript and yarn live under the npm ecosystem which, to put it mildly,
is a meal that was un healthy and tasted horrible and in attempt to make it
better, thousands of cooks tried fixing by eating it, puking it out, cooking
it again and repeating that process thousands of times. As I said, I can write
a book about the bad things which from all the languages I've used, are only
applicable to js & co.

~~~
rhacker
So no real example or specific reason it is worse than maven, cpan, or any
other.

~~~
axegon_
Well cpan hardly matters in 2020. I haven't even heard of perl in a good 6
years or so. Marven, though largely a java(also a horrible language) thing,
targets languages which at least aren't used and abused by people who believe
that "6" \+ 1 = "61" and "6" \- 1 = 5 are acceptable behaviors. What's more is
the fact that compiling the entire linux kernel takes less time and resources
then it takes node to figure out how to "compile" x = 1 + 1 into the gibberish
it makes. Also the preinstall, postinstall, preuninstall and postuninstall,
all of which are horrible concepts and I have no idea what kind of an idiot
thought that this isn't literally inviting the security hell into your bed
while you are strapped down naked. I can go on for days, those are just off
the top of my head while I'm falling asleep.

------
captn3m0
Why is nobody reading the damn article?

>I hope I was able to show you that PHP has evolved tremendously over the past
years, and you're perfectly able to write clean and maintainable code with it.

~~~
notJim
People have been writing this take (and it has been true) for something like
5–10 years. I doubt anyone who didn't believe it was just waiting for PHP to
get type annotations to be convinced.

------
nwmcsween
The PHP ecosystem is similar to the language (I work on it daily), tools are a
mishmash of features that may or may not be relevant to the tool. PHP ORMs in
general (compared to say Ruby or Python) are absolutely painful to work with,
which leads to most large projects that need a DB making a hard dependency on
MySQL.

~~~
Implicated
Do you have any examples of "tools are a mishmash of features that may or may
not be relevant to the tool"?

Or why the ORM's make MySQL a hard dependency?

Honest questions, genuinely curious. I, too, work with it daily and am curious
as to what you're doing/seeing/running into that I'm not.

------
rgj
PHP nowadays has almost all the syntactical candy of Ruby, and Laravel has all
the neat stuff of Rails. But PHP is so much faster and easier to deploy. All
it has against it is its bad past and ditto reputation.

~~~
verisimilidude
> PHP nowadays has almost all the syntactical candy of Ruby

Seems like a stretch. Ruby's whole mantra is about offering a very flexible
and forgiving syntax. Matz wants to _make programmers happy_. The whole
language is candy. You get powerful tools to make your own candy. It's
extremely sweet. For some people, it's too sweet, which is understandable.

PHP is not that.

You may have a point if you're limiting the conversation to people who use
OOTB Laravel or Rails to build basic CRUD apps. I'd argue Ruby is a much
richer language for those who explore it beyond Rails.

------
zonidjan
Array destructuring: already existed, list() pseudo-function

Array spreading: already existed, array_merge

Variadic functions: are probably better implemented as a function accepting an
array, especially now that there's a proper array syntax instead of a pseudo-
function. Also already existed, func_get_args.

Argument unpacking: already existed, call_user_func_array

Arrow functions: are not any shorter, and are less clear, than anonymous
functions.

Literally the only item on your list that was any good for the language is the
null coalescing operator. The rest are just re-implementing something that PHP
already had, in _yet another_ incompatible (and often unclear) way.

Hell, good luck coming across '??' and trying to find any documentation on
what it does. Searching Google for 'php ??' returns results for 'php',
searching php.net for '??' returns seemingly random functions, going to
php.net/?? gives you the homepage.

------
bovermyer
If I were to teach a course in basic web development, there are three
languages I would introduce students to. These would be Go, JavaScript, and
PHP (alphabetical order, not pedagogical order).

All three are forgiving languages. Each of the three focuses on a different
part of the stack. None of the three will save you from writing gawdawful
shitty code, but none of the three will prevent you from writing the most
elegant code known to man either.

~~~
hopia
Wouldn't it make pedagocially more sense to introduce languages that are more
different (paradigm) from each other than those languages you listed?

~~~
bovermyer
In a single course? I don't think so. Choosing languages that are this similar
will make it easier to make the transition between them. The intent is to
teach foundational skills in different areas of web development, and not to
teach everything about programming.

~~~
hopia
If it's a single course, then I'd say teaching more than one language is
already too much.

Javascript is necessary to learn as a webdev no matter how you look at it,
while the other two are not. Javascript can do all the aspects required from a
programming language in the web domain so focusing on that would make the most
sense.

------
app4soft
I would just quote Fredrick Brennan's statement on PHP in 2020:[0]

> _“There was nothing wrong with the PHP 5 language specification. The problem
> with PHP is PHP Group.”_

[0]
[https://www.youtube.com/watch?v=9crnlHLVdno](https://www.youtube.com/watch?v=9crnlHLVdno)

~~~
wolco
The PHP group works best when small groups within breakaway with an idea and
remerge.

------
notJim
It's kind of interesting (or incredibly mundane) how the feature sets of
popular web languages have converged. The examples could almost be typescript
(and the only reason I don't say Javascript is because of the types.) My
understanding is that new versions of Ruby and Python also will have (or
already have, I don't follow either language very closely) optional type
annotations. It seems like the real difference is on the
operational/deployment side, which tends to be elided (or only addressed on
the surface level) when we talk about languages on HN.

~~~
ironmagma
This is why the development of new languages and constant iteration of
“reinventing the wheel” (as some say) is worth it, I feel. Ideas from new
languages make their way into old standard languages. If over time, every
language starts to look the same, that seems to indicate we are honing in on a
sort of global maximum. The power and expressivity of programming languages is
immense but not infinite (practically speaking), and it is quite arguable that
eventually we will find ourselves with no major improvements to make. At that
point, it will make sense to settle. Until then, it makes sense to keep
building new ones and using them as inspiration for the existing ones.

------
jameslk
I could not even begin to consider using PHP again until php.ini is completely
eliminated. Not even optionally eliminated, I need to know I won't have to
deal with a hidden php.ini with all it's configured extensions somewhere on a
system before use, surprising me with missing, insecure or completely changed
PHP behavior. The fact that I didn't know what features a server supported
until I investigated or configured this file was a sinkhole of my productivity
in any new project.

~~~
tylerjwilk00
Why not run phpinfo()?

Lists all loaded configuration as well as extensions and their configuration.
Basically everything about the runtime environment your in.

Beginner level stuff.

~~~
jameslk
Yes, that was the first thing I had to do when starting a project. Create a
file called pi.php that ran that very function and scan pages of configuration
looking for a specific key. I would have to do this not once but many times,
whenever I thought I was losing my sanity because some random extension wasn't
available or the configuration enabled something unpredictable that I only
found out about at runtime (e.g. magic quotes was a perfect example).

~~~
gremlinsinc
you couldn't just run "php -i | grep xdebug" ? Or even explicitly set/unset
the phpini settings from the app in question or even your nginx settings? Lots
of ways to ensure everything works as needed. You can also include excensions
as requirements in composer so it errors if they aren't installed so you don't
forget to install them.

~~~
jameslk
I spent 10 years in the PHP world and yes I can do all that stuff. I had to do
it just to use PHP. Grepping around configs isn't even the problem I'm trying
to point out. It's the surprises, and having to do anything at all to prevent
these issues.

~~~
gremlinsinc
really? Arguably webpack + babel.config.js + eslintrc.js + postcss +
typescript config + package.json ... ALL just to be able to get your ui/ux
built -- and still the entire stack can fall apart w/ one wrong version, or
one wrong babel setting, etc.... JS is way worse than PHP... yet I'm not going
to throw it out w/ the bath water. Not to mention all the damn dependencies
inside node_modules...

Vue and react have some amazing things going for them, once you've got all the
tooling setup. But it's still a nightmare config wise that makes php way
better. I generally touch php.ini maybe once or twice over the lifetime of an
app. Can't say the same about JS tooling/webpack configs.

------
colordrops
The problem with PHP is that every discussion is about PHP's reputation. It's
a language that is overly self-conscious.

~~~
krapp
The language isn't self conscious. Programming languages have become subject
to fashion trends, unfortunately, and "discussing PHP's reputation" is the
tech equivalent of virtue signalling that one is too hip to shop at Wal-Mart
like a common pleb.

------
lunias
PHP is so polarizing... so much so, that it's enough for me to pass entirely.
Even if the language has improved I think the culture is still broken.

------
ausjke
for system coding you have c, c++, rust, even java and go.

for scripting you have bash and python these days, no need for php.

for web frontend, js remains to be the king, the sole ruler.

for web backend where PHP used to shine, you have python(django,flask,etc))
and js(nodejs,etc)), plus go and java, very crowded area.

In short, PHP is only good at web backend, nothing more, but that place is
getting really crowded these days, PHP no longer is the first choice.

While recent PHP added nice features and performance boost, I feel it might be
too late. Its high time has passed.

I can learn Python do CLI/web-backend/AI/ML, I can learn JS for
frontend/backend, I can learn C/C++/Rust for system programming, I use Java
for enterprise,etc. I really do not need PHP anymore and there is only so much
time left to master all the languages.

------
luord
I'm happy for the PHP developers.

I still find it an eyesore to read, but everyone is free to use their
preferred languages. Stuff like this article shows that good software can be
created in any language if there's the will.

Even in brainfuck (I assume).

------
nkozyra
This is a quibble but reminiscent of the kinds of inconsistency PHP
programmers are known for:

$value = $object->property ?? 'fallback if null';

$value = $array['foo'] ?? "fallback if key doesn't exists";

~~~
lemcoe9
I do not understand, both of the expressions on the left-hand side are NULL,
which looks like ?? is doing the same thing in both examples. A non-existent
array key and a non-existent property on an object are logistically identical.

~~~
nkozyra
I was referring to the single-versus-double quotes.

------
rahuldottech
See also:

PHP in 2019:
[https://news.ycombinator.com/item?id=19917655](https://news.ycombinator.com/item?id=19917655)

------
buboard
is there another language that was written domain-specifically for building
websites?

~~~
darkstar999
javascript?

~~~
rgj
No, that was written for client side DOM manipulation. Only.

------
pabs3
Does PHP have the ability to be run as a WSGI script yet?

~~~
treve
What would the benefit be? (I don't know WSCGI that well)

------
Keverw
Nice overview.

I like how it seems like PHP has a lot bigger built-in standard library
compared to Node, as some people install NPM packages for little simple
things. Then PHP has a built-in time and date helpers, like timezones.

However, the $ dollar sign for variables kinda annoys me, as switching back
and forth between PHP and other languages like JS. Like recently ran into an
issue where I forget $ in front of a var and JSON encoding it, and then went
to var_dump it but realized I forgot the $ so it was outputting the variable
name instead of the variable contents. I guess muscle memory.

I know I was reading a blog post though where someone built a React frontend
around Wordpress as a headless CMS, thought that was interesting but haven't
looked into how to do it yet 100% but was proposing it to someone I know that
has a large site built around WP but seems like a mess of plugins and theme
tweaks so I felt moved to something else would let controlling the design and
changing things without forking plugins when there are tweaks wanted that
isn't part of the official plugin, etc as I feel like that would allow more
complete control of the presentation layer without tweaking multiple things
and stuff. However some businesses don't really care about the tech under the
hood, they just want it done quick with results, don't really understand all
the technical stuff and care about costs, so not like a tech startup where you
care about a lot of the little details or maintaining things for the future.
Then some people don't even really know what they want either, but I guess
business people managing tech people, but even big tech companies I doubt all
of their CEOs are even technical either though but maybe they hire technical
project managers to help bridge the gap between the two parts of the business
but their product is mostly tech though anyways so I assume a different
culture than tech in a non tech business.

Looks like some projects to do server-side react with PHP too, but haven't
played with any personally - but that's useful if someone cares a lot about
SEO even though Google can crawl SPA's but other search engines might not be
as capable, then sharing on social media not sure if they use server-side
rendering when grabbing the metadata for open graph for example. That'd be
neat to pitch to non tech businesses who might just be running on a cPanel
server and don't want to really invest in servers and managing them much yet,
so mix both PHP and React would be prefect maybe for some types of companies,
PHP and MySQL for the data part with a nice clean modern and fast react front
end with near instant page loads.

Kinda interesting about support for web sockets and more async stuff in the
future, I guess in theory than you could write real-time game servers in PHP
for example? I know some game servers are in C, C#, C++ or Node though, but
long-running PHP code would be useful for other types of applications that
aren't just mainly restful web pages or APIs.

Then another thing is you might find examples or libs in PHP but have to dig
for equivalents in other languages, probably since PHP is so popular and
easier to get into maybe. Then somethings you'd find a good lib in Python like
I was looking at something and didn't see an official JS client but they
offered a C, Go and Python one... Would be neat if somehow you could easily
just combine the languages, I seen there is a Node PY bridge though and sounds
like some experiments of compiling PHP to WASM but haven't played with
it(wondering if it compiles only the code you wrote(I guess perfect for code
you happen to strongly type) or the entire PHP binary along with it, but I
know FB was working on compiling PHP to C with the HACK project, so a similar
idea might work for WASM but not sure if it's a sane idea - maybe just porting
the code you need would be a better answer maybe... but that'd be an
interesting way to develop, but I guess with microservices you could mix and
match too but some little tiny things seems a waste with all the networking
calls.

------
blantonl
To all the haters out there.

I self taught myself PHP almost 15 years ago, and I've completely developed
over the years, from the ground up and from scratch by my self, a complete
network of businesses: RadioReference.com and Broadcastify, that does

Public and Private APIs in SOAP, JSON and XML. Complete user authentication
and session for millions of users. Integration with third-party best of breed
apps like MediaWiki and Xenforo. Database, Ticketing, Location, Admin, User,
Payments management. Provisioning, Scripting, Web Services consumption etc

The code is ugly, barely any OOP except for some reusable internal classes.
Tons of copy paste from Stackoverflow. I'm still using mysql_query() in a lot
of places. Did we hit some security issues, sure!

But it works, it generates millions of dollars in revenue, and it's all
managed and developed by one person.

So, to all the PHP haters out there. See above.

~~~
mthoms
As someone who _likes_ modern PHP and hopes to see old stereotypes go away,
this comment made me sad.

~~~
blantonl
Why sad?

The objective is to build a business, generate value and execute on a vision
using a programming language, not win a popularity contest by proclaiming your
use of anonymous classes, unicode codepoint escape syntax, and the spaceship
operator.

I'm doing some really cool things in PHP, and some really ancient things as
well. Who cares? The business is killing it, delivering some of the latest and
great technologies to end users. That's all that matters.

~~~
mthoms
It's just that your cavalier attitude towards best practices and apparent
pride in having a shoddy codebase perpetuates the stereotype that PHP
developers are second rate.

And no, I'm not advocating for using the latest and greatest just for bragging
rights. There is a middle ground.

> "Who cares? The business is killing it"

What happens when you want to sell the business, or the sole developer of this
monstrous codebase becomes ill? Based on the picture you've painted of it, a
good developer won't want to touch it with a ten foot pole.

Anyhow, I am very glad for your success. It does sound like an interesting
story. Just don't be surprised to see a negative reaction from a community of
professional developers when you brag about how poorly written (and vulnerable
to attack) your "million" dollar application is.

I can only hope that you aren't operating anything that other businesses rely
on, or worse — handles personal data.

~~~
rawoke083600
>What happens when you want to sell the business, or the sole developer of
this monstrous codebase becomes ill? Based on the picture you've painted of
it, a good developer won't want to touch it with a ten foot pole.

Lol the same can be said for any website written in plain-js+jquery, or C++

