
Stop writing PHP like it's 2009 - imperio59
https://florianlaplantif.wordpress.com/2017/07/18/stop-writing-php-like-its-2009/
======
CiPHPerCoder
"Don't write PHP, write Hack instead" is probably a better title for this
post.

The author could have chosen to write about PHP best practices that are
ignored in the ecosystem at large, but instead chose to evangelize HHVM
features.

For anyone who currently writes PHP like it's 2009 and wants to learn a better
way (without dropping PHP entirely):

[http://www.phptherightway.com/](http://www.phptherightway.com/)

[https://planet.nomadphp.com/](https://planet.nomadphp.com/)

[https://www.reddit.com/r/phpsec/](https://www.reddit.com/r/phpsec/)

If anyone prefers to drop PHP entirely, that's fine too, but that's not _the
only good answer_ and pretending that all PHP is bad (like many of the
comments on this thread already do) is very disingenuous.

~~~
astrodust
Good PHP code tends to look like well structured Java code, but with a rash of
$ characters in it. I have to wonder why you don't just write Java and be able
to leverage what the JVM ecosystem provides.

~~~
deweller
Are you aware of what the PHP ecosystem provides? There is some pretty great
stuff in PHP land.

2 of my favorites are [https://getcomposer.org/](https://getcomposer.org/) and
[https://laravel.com/](https://laravel.com/)

~~~
astrodust
Honestly, that's like a cup of ice water in hell. Composer is a _finally_
thing, and Laravel is a "at least it's not garbage" framework. The things you
have to make do with in the PHP world are absurd. Find something in an array?
Ugh.

PHP is catching up to what other languages have enjoyed as a given for over a
decade. It's very confused. There's been absolutely zero effort to overhaul
the core PHP API which is, on the whole, absolute junk. Frameworks like
Laravel do their utmost to insulate you from having to use it too much for the
ugly things.

As an example of what could happen, JavaScript has gone from this ugly,
useless language that would crash your browser if used too much to something
that's now widely deployed and powers significant web properties both client-
side and server. The improvements to the language have been dramatic, ES6 code
is words apart from JavaScript 1.

In another 5 years JavaScript will hit another milestone, Java will evolve,
and PHP will still be PHP.

~~~
dabernathy89
Yeah, JavaScript in 2017 is so much better to read and write than it was in
the past. [https://medium.com/@sAbakumoff/es6-is-great-until-its-
not-f3...](https://medium.com/@sAbakumoff/es6-is-great-until-its-
not-f398339d0af6)

~~~
astrodust
It is. Those are valid complaints, every language has issues, but with each
iteration the number of complaints the average user has tends to drop because
convenience features are introduced.

------
verelo
Async queries, great advice..do that. The rest meh...

The bad:

"Use HHVM". Do not do this, just upgrade to PHP 7. HHVM does have better
performance [in some cases, not all], but it also has many unsupported modules
[such as Memcache based sessions]. It's difficult to get improvements added
and you're going to get frustrated by something people in the mainsteam PHP
branch can do that you cannot do.

?int $var = null;

This is a question of style. Personally, i can read it, but it is a little odd
and I've seen people get confused over it. I'd personally avoid it. The null
check and type check is much clearer.

~~~
cnowacek
It's not just a question about style. ?int can be enforced at compile-time
while the null and type check would be caught at runtime.

~~~
verelo
Great point, and for that reason I really like it, but generally my view is:
"for most situations, humans are more expensive than the compute costs, so do
the thing that is easy for a human to understand and pay the tax on your
compute power". Obviously that doesn't always hold true, so place your bets
accordingly.

~~~
int_19h
Why would it be hard for a human to understand a type declaration using a
syntax that has been well established in some of the most popular programming
languages (C, C++, Java, C#) for several decades now?

~~~
verelo
The longer [if based] format can almost be interpreted by any human that has
no programming experience but a good grasp of logic, the other is just
inherently more complex and less verbose.

Edit: And my point here is basically that less experienced programmers will
get it, which makes the barrier to entry lower. Going back to my previous
statement, without a better reason, I'd encourage self documenting code and
less abstract approaches. This is a pretty mild one, easily looked up...and
probably a great thing for people to learn, but still more complex at the end
of the day. Language is almost irrelevant here, it's a general statement.

~~~
int_19h
I think you overestimate the readability of C-based syntax in general. A human
that has no programming experience would have to start with parsing what !==
means (and it's not at all obvious that ! is negation, or why = is doubled),
and then move onto &&, although that's slightly more obvious. Nor is "int"
obvious as a shortening of "integer" outside of CS - I've seen people
interpret it as "internal", for example.

Going further, to even figure out why you need to do all this, that human
would need to know such concepts as variables, data types, and nullability.
The notion that variables can have designated types is a pretty obvious
takeaway from the first two.

~~~
verelo
Just for fun, if you didn't know what "?int $var = null;" meant, how would you
explain that to someone verbally, or better [like most programmers would] how
would you search for this online?

Finding the definition of "!==" is easy, simply searching that [including
quotes] gives me the answer. Looking for something like "?int =" just gives me
useless responses upon first glance.

------
treve
I'm a big proponent of using PHP where it's appropriate, and I've found lots
of good usecases for it.

But suggesting that writing good PHP implies using a different runtime and
different language, why not go to a different strictly typed C-like language
altogether, like Java? It's certainly maintained better.

------
Rjevski
Here's a better version of that link:
[http://www.phptherightway.com](http://www.phptherightway.com) \- using a
different runtime is not going to make someone who doesn't know anything
besides mysql_query or include write better PHP. You need to start with the
basics instead. Your post is what I would call premature optimisation.

~~~
olegkikin
You can't use mysql_query anymore. It's removed from PHP 7. And the docs warn
you about it:

[http://php.net/manual/en/function.mysql-
query.php](http://php.net/manual/en/function.mysql-query.php)

~~~
Rjevski
One of the issues I noticed in a lot of beginner PHP developers is that the
official docs is the last thing they look at. They'd rather copy/paste some
crap from W3Schools or a 10 year old blog post, and given that they put it on
shared hosting with a prehistoric version of PHP the "mysql_query" garbage
will work as expected (as in, allow their site to be exploited).

------
The_Sponge
Between PHP7, PSR4, and generally good development strategies, the only thing
hack/hhvm offers in the near future is being tied to the hip with a single
large company that both consumes and produces it.

Hack/hhvm were great visions of the future and definitely motivated the PHP7
WG to move at a more brisk pace, but tying yourself to something like that is
not a great idea, imo.

~~~
bdcravens
Wouldn't the same criticisms apply to React then?

~~~
CharlesW
In that analogy, what's PHP to React's HVVM?

~~~
bdcravens
React IS the HHVM in that example; there was no React prior to Facebook
creating it.

"...the only thing hack/hhvm offers in the near future is being tied to the
hip with a single large company that both consumes and produces it."

Both projects are of course open source so "tied to the hip" may not be
applicable (though they of course have difference licenses with the nuances
that go with)

------
cosinetau
This blog entry starts off with "I'm a former Facebook employee, and all you
PHP devs need to git gud." Pass.

------
kronos29296
Another article that talks about the scalability and benefits for wikipedia
and facebook when the websites that most people create will never be either.
You are not going to save millions on server costs and just doesn't make sense
for some personal blog on wordpress. For most cases something like php7 might
make as much sense.

But the author believes that what solved facebook and wikipedia's problems
will solve everybody's. If HHVM and Hack are really the tools that solve your
probably use it but don't go that route if you absolutely need it. Don't get
burned by hype because every use case is unique. What fixes facebook's
problems probably will not fix yours. But php 7 is another viable option and
from what I read it performs pretty well compare to HHVM for the most common
things you would use it for. Also the language got a lost of fixes for its
warts (I'm not a php expert but looks like it did).

tl;dr - don't blindly use tools where they are not needed and use the right
tool for the job.

------
bpicolo
So the answer to "Stop writing PHP like it's 2009" is to not write PHP at all,
and write Hack instead?

~~~
kuschku
An argument could be made that we need a new law of programming languages:

> Given enough time, all languages converge to become Java.

~~~
madsbuch
Except that it is far from true.

~~~
kuschku
Look at the JS world, or the PHP world, and it certainly seems true for them.

------
philplckthun
> It boggles my mind having left engineering at Facebook only 2 months ago
> that the outside world still largely seems to write PHP like it’s 2009.

I don't know the author so I don't want to make any quick assumptions, but
even if it was just a bad joke calling a community "the outside world" sounds
extremely conceited

~~~
cosinetau
It really does. I find it insightful as to potentially how these "Big Boys"
view the development community outside of their Palo Alto bubbles.

Perhaps they fail to realize that their attitudes matter? I think this lends
context as to why so many cultural problems persist through that bubble.

What up SF?

~~~
wcummings
SF will make a great looking crater.

------
TallGuyShort
Since I'm sure this will quickly be a debate about PHP, these are the reasons
I liked PHP at the time:

1\. Ubiquity across web hosts. 2\. Native support for JSON-esque associative
arrays. 3\. Integration with HTTP seemed amazing compared to other languages
used for CGI.

1's not an issue anymore thanks to the cloud and other improvements in hosting
services. 3's not an issue either thanks for good web frameworks in better
languages. But 2?

Flex / JavaScript / PHP really are a pleasure to write some things in because
of the flexibility of those data structures. Working with JSON, etc. in Java
and friends is really painful and boiler-platey. Anyone aware of really good
implementations that feel like PHP / JS in more widely respected languages?

~~~
WaxProlix
Ruby, Python, etc all do this fairly well if you're talking about
dict/assoc.array literals and ease of serialization/deserialization.

~~~
TallGuyShort
Yeah Python does well, but boy I wish dynamic properties were smoother
sometimes, e.g.: a[b][c] == a.b.c. But I'd rather Python be Python than
compromise correctness for PHP-like flexibility :)

~~~
WaxProlix
This causes all sorts of problems, though. If you conflate the language's
symbol table with a data structure managed by the language (ie, a hash or
dict) then suddenly you have the same problems as JS did for ages. I can't put
a '__init__' or ' ' in my key names anymore, or any of the other special
cases. Best to leave them as hash keys.

------
goshx
"People still largely seem to use require() and include() statements
everywhere in their code."

What should they do? Asking for a friend

~~~
oatmale
Namespacing & autoloading

------
toast0
> People still largely seem to use require() and include() statements
> everywhere in their code. What. The. Fudge.

I'm one of the people who like to have require (with full paths too, if we
can). Looking at the code, I can see what it needs and where it gets it; I
don't have to reverse engineer what the autoloader will do; I don't have to
wonder how many system calls it's going to take for it to do it.

Async can be nice, but the language contortions you need to go through to get
it are painful. If you can stuff your database calls into webservices, you can
use curl_multi to do parallel fetches everything you need and let the database
webservices run the queries single threaded in lots of different processes. It
adds a layer, but it's easy to understand.

In my opinion the right way to write PHP is embrace the PHP serving model: at
the beginning, you get a request, you return back something (html, whatever),
and then everything in memory is thrown away. Because everything is going to
be thrown away in a little bit, it doesn't make sense to invest in a
delightful hierarchy of classes; just parse the input, grab the right data,
and stuff it together in as little code as possible.

------
kyberias
Hmmm... I'm curious about the async explanation. I don't think that's the main
benefit. The main benefit, at least on other platforms, is that while your
function is await'n for your db, the thread can service other requests. It
doesn't have to be stuck on waiting for I/O. This can dramatically improve
scalability. I don't know, maybe PHP/hack doesn't really support this somehow.

~~~
toast0
In a traditional PHP installation, the interpreter is single threaded, and you
run multiple instances of them. If all the instances are waiting on I/O, you
just run more instances until you run out of ram. If you're not linking in
crazy c libraries, your php instances shouldn't get too big, so you can run a
lot of them. (Ex: on my well traveled site at work, the biggest php takes up
24M, elastic search for maybe 1000 documents (documents 128M on disc) takes up
5G; I can run a lot of php for parallelism, if needed)

I'm not sure if HHVM changed the threading model to run multiple requests
simultaneously in one interpreter.

~~~
kyberias
Right, it's just that the thread that is kept waiting for database could serve
other clients meanwhile. While keeping the thread sleeping, it's wasting
system resources.

For example, ASP.NET has a small number of threads and each async call allows
one thread to process another request.

~~~
toast0
That's true in a thread oriented environment; but it's not the case in a
traditional PHP environment, with one OS process per client. A PHP process
does not know how to context switch between many requests; if the process is
waiting for I/O the OS will schedule a different process. In this model,
sending multiple backend requests concurrently, regardless of how, is of value
when it lowers the total request time and lets it accept another request
sooner.

You can send requests to the backend through async/await language features, or
more simply by using apis that separate sending a request from waiting for a
response, assuming network buffers are large enough to enqueue the request(s)
without blocking.

------
tomphoolery
It doesn't seem surprising to me that smaller companies are cautious when
adopting tech solely supported by a large company like Facebook. Plenty of
projects in the open-source graveyard were created and (somewhat) supported by
the likes of Google, Facebook, and Twitter...only to change technology stacks
a few years later and abandon maintenance of their libraries. Having to
rewrite your code using different libraries is pretty bad, but it's way worse
to have to rewrite your whole app because the platform you wrote it on isn't
supported anymore.

Don't get me wrong, I love all these technologies and (although we're beating
a dead horse here with the Java references!) Hack really feels like the "Scala
of PHP" in the sense that it provides a lot of great features, but you can
always "drop down" to PHP whenever it's necessary. That said, I think it could
use some more adoption and articles like this are the first step toward
getting people interested.

------
dabernathy89
But the author has no problem writing this blog post using WordPress.com,
built on a PHP codebase that goes back 14 years and still largely resembles
2009-era PHP. (This is not a knock on WordPress at all - it paid my bills for
years).

------
mnm1
This is Hack, not PHP. I considered Hack and HHVM a few years back, but with
PHP 7, they really have little to nothing to offer PHP development and last
time I checked, there were still serious incompatibilities. The speed gains
for both HHVM and PHP 7 are very similar over PHP 5. I really cannot see using
Hack or HHVM, or even considering them, unless they get another 2x or more
speed improvement over PHP 7. In my testing, they're head to head and that in
no way justifies the migration. Hack is NOT PHP, sorry.

------
AndyMcConachie
If the thing you're making in PHP requires asynchronous calls to a DB then
perhaps you shouldn't be writing that thing in PHP?

------
exabrial
#1 issue is lack of strong typing.

I don't understand the appeal of dynamic languages. Worse performance, more
overhead, harder to read...

~~~
gnaritas
Good enough performance, overhead is fine, easier to read, faster development
time, vastly easier exploratory prototyping abilities, dynamic patterns
available that can't be done at all in static languages like meta classes and
dynamic message interpretation via late bound message passing. If you don't
understand the appeal of dynamic languages, it's likely because you still
program like you do in a static language while in them and you're ignoring the
new things you can do that you couldn't in a static language. Static types are
handcuffs, they prevent all kinds of perfectly valid code that work fine in
dynamic languages. Static types ensure you don't make certain kinds of
mistakes, but the cost of doing that is forbidding valid code that can't be
verified at compile time to be correct, even though it'd work fine at runtime.

I want to tell the computer what to do in the simplest form possible, I don't
want the computer telling me what to do, and I don't want to have to decorate
my intentions with a bunch of unnecessary type fluff to make a compiler happy,
and I certainly don't want the compiler telling me I can't do something I know
will work perfectly fine just because it can't be statically verified.

------
Neil44
I liked HHVM vs PHP-FPM because you don't have to one fat process per
concurrent request. But disliked it because not much actually ran on it
without tweaking. If you just have a bunch of random CMS sites to host then
forget it. (this was about 2 years ago)

------
diimdeep
What are examples of modern PHP code currently in production (open source
obv.)? Except obv. frameworks like Laravel.

~~~
diimdeep
nvm: [https://github.com/uhub/awesome-php](https://github.com/uhub/awesome-
php) [https://github.com/ziadoz/awesome-
php](https://github.com/ziadoz/awesome-php)

------
linopolus
s/ like.*//i

------
pram
Mods truncate title to "Stop writing PHP" TIA

~~~
chasing
It's funny to me that so many people on the "PHP is bad" bandwagon are
apparently perfectly cool with writing every damned thing in Javascript.

~~~
coding123
Everything should be written in Typescript if you need Javascript.

~~~
felixschl
I hope not, purescript is a much more sensible option.

~~~
galeaspablo
Elm

~~~
chasing
CSS

~~~
linopolus
ASM

