
PHP in 2019 - brendt_gd
https://stitcher.io/blog/php-in-2019
======
owenwil
I've actually been really impressed with Laravel after switching back to PHP
for a few projects. Not only is the developer tooling experience some of the
best I've experienced, it's just really the only framework I've ever
experienced with a high quality ecosystem of tools—from Forge[1], which makes
it dead-simple to deploy a Laravel app into production to things like Horizon,
for managing Redis queues.

A great example of this in action is Laravel Spark[3], a first party base for
building paid SaaS apps. I built and launched a writing tool, Write
Together[2], to the world in under three weeks, payment systems and all, and
got 150 paying customers in a matter of a few weeks. One hell of a great way
to MVP an idea and build something useful, in a low amount of time.

I'm basically developing two Laravel apps full-time at the moment, and it's
the most fun I've had in years...compared to the hellscape of NPM dependencies
and other complexities I'm usually bogged down with. Composer, the package
distribution system, really needs work and is incredibly slow, but other than
that—I'm really happy.

[1] [https://forge.laravel.com](https://forge.laravel.com)

[2] [http://writetogether.space](http://writetogether.space)

[3] [https://spark.laravel.com](https://spark.laravel.com)

~~~
nickjj
There are comparable things with other frameworks too.

For example I wrote a course on building a SAAS app with Flask. It's available
at: [https://buildasaasappwithflask.com/](https://buildasaasappwithflask.com/)

It covers everything about user registration, profiles, subscription billing,
1 time billing, invoicing, and about 50 other things you would likely want to
do in a SAAS app or any application really.

The course comes with the source code along with 15+ hours of video explaining
every line of code in stages, life time free updates and life time support for
close to half the price of what Spark charges just for the source code for 1
site license (with the Flask course you can use the code in however many
projects you want).

Spark's business model seems interesting though. I don't use it personally but
do you just get the source code and nothing else? How do they limit you to 1
site if you end up with a local copy of the scaffolding / code base?

~~~
alfonsodev
Nice! It looks very nice and complete. I've found this other one in Go lang
[https://buildsaasappingo.com](https://buildsaasappingo.com) (I'm not
affiliated nor tested it) I think it is a good idea to turn something that you
need for yourself into a side income, I've though about doing this same thing
myself in a different language.

What can you tell about your experience building this course, is it worth it ?
rewarding ? Did you find difficult to promote it ? what are the main channels
to adquiere customers ?

And if you don't mind sharing some numbers, how many people purchased it so
far?

I'd like to get an idea on how profitable (or not) and personally rewarding
are type of courses, to motivate myself and write one of these one day.

thank you!

edit: I'm thinking maybe that was too many questions, sorry if so, you could
create a "meta-course" on explaining all these things and I'd buy it! :)))

~~~
nickjj
That's how the course came into existence.

I built a number of SAAS apps (and apps that had similar functionality) for a
few freelance clients. Then I eventually thought "hmm, lots of repeated
patterns here, maybe I can make this into a course", so then I made the
course.

As for the process. Funny you mention it. The changelog just had me on as a
guest for their "backstage" podcast last week where we talked about content
creation and the process of recording courses. That's at:
[http://changelog.com/backstage/4](http://changelog.com/backstage/4)

It covers most of your questions but it doesn't cover nitty gritty details on
sales figures and revenue. Thousands of people have signed up for the course
but I still do quite a bit of freelancing. Freelancing and course creation is
my full time job.

I find it really rewarding at a personal level. I just like creating things,
but it is a lot of work. It's not just hitting record and being done in 2
days. Expect it to take 3-6 months of full time work to make a course. Then
there's having to keep it updated (because tech changes so fast) and ongoing
24/7 support.

Couple people have asked me to make a course on making courses. Maybe one day
but at the moment there's still a bunch of technical courses I still want to
make, a million blog posts to write (I have 85 draft posts that are
unpublished) and some side projects in the works.

~~~
alfonsodev
wow, serendipity I guess :)

Definitively I'll check the podcast, thanks a lot!

~~~
nickjj
No problem. If you still have questions after the podcast shoot me an email
and I'll do my best to answer everything.

------
StevePerkins
On one hand, I do see that HN (and probably Reddit) live in a bubble. Where
most of the darling languages and tools have very low use in the real-world.
And where most of the languages and tooling that actually run the real-world
go un-discussed, or simply dismissed, because they're boring and don't appeal
to students and entry-level devs working on side projects. I realize that the
perspective most rookies get from these forums is completely distorted.

On the other hand, I ALSO think that PHP is only still relevant because of
WordPress. The business world runs on Java, and .NET to a lesser extent. I see
job postings for Python all the time, as it and the JVM run the worlds of data
science and big data. One can even still make a thriving living with Ruby. But
I just don't see any recruiter activity around PHP at all. And whereas my Java
shop will hire Python or Node junior devs, on the theory that they can learn,
we would more likely to skip over a PHP-based resume (if we ever actually saw
any).

~~~
cbdumas
Often when there is a post about PHP I read over these treads sort of subtly
trying to figure out how a language with such a large user base has remained
basically invisible to me. And I don't think I live in the HN bubble, though I
do use a lot of Python, in my consulting work I've also done plenty of work
with .NET, JVM to a lesser extent and other "boring" tech.

But PHP has literally never come up, even as a suggestion or as a tool that is
a small part of the company stack or whatever. It feels like I'm looking into
a strange parallel universe of software development reading through these
threads. PHP devs, where are you?

~~~
DCoder
Right here! PHP and JS/TS is what I do every day.

PHP has its tentacles all over the web: WordPress and Drupal are immensely
popular for simplistic sites and short-lived promotionals, Magento and
WooCommerce attract many e-commerce users, and Symfony/Laravel handle the
custom stuff. I've worked with all of these and have the scars to show for it.

All popular projects have swarms of consultants offering advice, prebuilt
additions, and custom development. (E.g. WordPress plugins and themes are
_everywhere_.) This is also a significant factor for the penny-pinching
customer — from their point of view, they avoid vendor lock-in and expensive
development this way. (Spoiler: it rarely works out, in the end. "Tower of
Babylon" and "shallow learning curve" mix in _very exciting_ ways.) So there
are masses of people who know the basics of PHP and call themselves "PHP
developers". In my opinion, just a fraction of them actually deserves that
title.

~~~
cbdumas
So I get the sense that PHP is sort of the tool of choice for web development
at small or medium businesses which are not primarily software businesses, but
are looking to create a website and maybe do some ecommerce? Is that right? If
so I guess it makes sense that I wouldn't have seen it, most of my consulting
work has been at relatively large enterprises.

~~~
hnick
Pretty much any shared hosting service (which is the default for a small
business not going for a more handheld hosted solution like Squarespace or
Shopify) is cPanel enabled with PHP, MySQL (via phpMyAdmin), one-click
Wordpress installation, and other similar features.

------
mattferderer
I think the easiest thing to forget is what made PHP popular was how easy it
was to get started writing software that worked good enough. The barrier to
entry was incredibly low. It caused a lot of bad code & gave PHP a bad
reputation but a lot of good was also made from it.

PHP made a lot of careers for developers as they were able to fake it until
they made it while learning how to code & providing significant value to a
businesses.

While PHP is nothing like its former self, most people who developed web apps
in the first decade of the century will probably always remember PHP for what
it was.

~~~
gwbas1c
The thing that I like about PHP is that I can mix HTML, code, and database
queries into a single file.

This is incredibly useful when learning basic web development, even though it
doesn't scale for more complicated applications.

It's also incredibly useful when trying to bang out a simple experiment.

~~~
juangacovas
And many of us took the jump and refused to do things that way. You're wrong,
PHP scales and you CAN do separation of concerns and have pretty, maintanable
code, using a framework or not: just a matter of knowing what you are doing

~~~
barbecue_sauce
It's pretty clear that he meant mixing HTML, code, and database queries into a
single file was what didn't scale, not PHP itself.

------
ilmiont
Writing with PHP is better than ever... and getting better and better.

And... you don't need too worry too much about the server, or the request
lifecycle, or networking... you just write your app, in a language which is,
in my _opinion_ , going in the right direction with a stronger slant towards
OOP and types.

Of course it's still entirely possible to write garbage PHP code... but it's
possible to write garbage in anything.

I'm increasingly proud to say I'm a PHP developer; it still gets a lot of bad
commentary but it all tends to be based on historical stigmas which are
increasingly untrue. Yet all the original benefits are still here, and the
language itself is going from strength to strength...

~~~
momokoko
My issue with modern PHP is that it's essentially becoming Java. And with the
JVM and the Java ecosystem, what is the compelling reason to not just pick
Java at this point? With Java you are basically writing exactly what you would
be writing with PHP, except with more language features and the ability to opt
into other languages on the JVM like Kotlin and Scala.

The modern additions are fantastic for projects and teams that have a specific
need to stay on PHP. I still work on projects with PHP and am thankful it has
so many improvements. But in its current form and direction, I'm not sure how
it has not become simply a little bit worse version of Java.

~~~
dominicl
Interesting analogy, performance wise PHP has made impressive progress. On par
with node and the JVM. But Java code specifically is just so bloated. And then
there is the worker-per-request model in PHP - All resources isolated to a
worker and cleanup on exit. This avoids global garbage collection freezes by
design. Something you would get otherwise only from Elixir/Erlang natively.
Compared to the JVM that allows PHP applications to scale vertically to any
amount of RAM/CPU, and horizontally to any amount of machines. If you let me
free choices I'll do Elixir all day long. But pressed on Java vs. PHP for a
web app it's PHP for sure.

~~~
qaq
"On par with node" wow looks fairly close "on par with JVM" thats a big
stretch

------
Arbalest
One of the main takeaways I got from the original Fractal of Bad Design post
was the myriad of inconsistencies in both representation and execution of
code. This was barely touched upon, mostly this post focused on how PHP has
added features and ecosystem. But then so has Javascript.

~~~
simion314
Unfortunately this is true and it can't be changed, the functions are named
and parameters are soemtimes inconsistent like strpos and str_replace, I would
have to use the docs all the time if my IDE wouldn't show me the param names.

But after you get productive with PHP there is no feature that I think I am
missing from other similar languages.

~~~
DCoder
Features that I miss in PHP:

\- expressive type system with generics, union types, literal types, basically
TypeScript. I can say "this function returns a string" or "this function
returns an array", but not "this function returns an array of strings".

\- specialized collection/hashmap data structures with good support across
third-party libraries. Having one array() structure acting as both a sequence
and an associative array at the same time is awful.

\- a templating solution similar to JSX. I am spoiled by TypeScript's ability
to typecheck my HTML views along with other code.

~~~
Zarel
It looks like Facebook had your exact problem; you want Hack:

[https://hacklang.org](https://hacklang.org)

It's based on PHP, but adds:

Expressive type system with generics:

[https://docs.hhvm.com/hack/types/generic-
types](https://docs.hhvm.com/hack/types/generic-types)

Specialized collections: vec, dict, keyset

[https://docs.hhvm.com/hack/types/arrays](https://docs.hhvm.com/hack/types/arrays)

Templating solution similar to JSX: XHP

[https://docs.hhvm.com/hack/XHP/some-
basics](https://docs.hhvm.com/hack/XHP/some-basics)

~~~
DCoder
I'm aware of Hack and it's quite nice, but I can't use it because a) my
coworkers are … less open to new ideas … and will rightfully resist a "whole
new language", whereas mgmt will see it as an attempt at "job security", and
b) the biggest use-case for generics is third-party libraries (e.g. [0], [1],
[2], [3]) which will never add support if this is not a core language feature.

[0]:
[https://github.com/doctrine/collections](https://github.com/doctrine/collections)

[1]: [https://github.com/schmittjoh/php-
option](https://github.com/schmittjoh/php-option)

[2]: [https://github.com/schmittjoh/php-
collection](https://github.com/schmittjoh/php-collection)

[3]: [https://github.com/widmogrod/php-
functional](https://github.com/widmogrod/php-functional)

------
hguhghuff
The thing that matters is language consistency... A language with a pure clean
vision of itself in which the programmer can guess at syntax because they
understand the general syntax principles to which the language adheres.
Nothing here says PHP has been fixed in this regard.

Python made the big leap and fixed some huge problems when it went to python 3
- yes it's migration approach was a total fail, but it further cleaned up what
was and already clean and consistent language.

The only thing that would have really interested me in this post would have
been to hear that PHP had been cleaned up into a consistent syntax, but that's
not what this article says.

~~~
deanclatworthy
I've been coding in PHP for almost 20 years now. I think I can count on one
hand the number of times where I have had an issue regarding inconsistent
function signatures. It becomes second nature, and if I forget, the
documentation is available online or in worst case built into my IDE.

I can understand why people make this into such a pain point, but quite
frankly it isn't for anyone who works day in day out with PHP.

~~~
Klathmon
That's what really gets me.

Anyone that works with PHP on a daily basis very quickly gets used to some of
the naming differences or inconsistent signatures. Anyone that works with PHP
rarely is almost assuredly going to have to look it up regardless of how
inconsistent it is. (do people really guess at function names, signatures, and
return values in other languages!? I've guessed that they exist, but I don't
ever think i've tried something without first checking the docs just to see
about any surprises or differences)

Consistency is nice to have, but it's pretty far down the list of requirements
in my opinion. If it's different for some, I can see how they wouldn't like
PHP, but calling for it to "clean up" it's syntax in a giant "python-3-esque"
move seem really misguided. People who program in PHP regularly don't really
mind the warts, and the language has improved significantly in areas that it's
users found most important. Types slowly working their way into the language,
easy closures, traits, nice new operators, and the massive speed and memory
usage improvements have all been very welcome improvements that have made me
more productive in the language.

The time spent on "cleaning up" the standard library would be a welcome change
by most, but it wouldn't really have any material impact for me or any of the
other PHP devs I know.

~~~
Moru
For a while it was popular to just create your own functions with your own
naming convention and parameter order, easy to do and you have whatever order
is sane for you. Lots of frameworks around now so you don't even have to do
that any more.

------
katet
Here's the thing that always grates a little bit for me about these posts:

I don't have a choice.

I've worked at a couple of organisation where there are hundreds of thousands
of lines of code written in PHP. It's been there for years. It does its job
and - from a business perspective - it does its job pretty damn well. And I
get paid to keep it ticking, and to improve it. Not to rewrite it to fit my
personal tastes.

In my spare time I've played with Haskell, Rust, C, Lisp, assembly languages,
and I enjoy them. I dearly miss some of the more functional aspects from these
languages every time I write PHP.

I work with a large PHP codebase right now (amongst others) and while there
are a great many technical benefits I could wring from it in another language,
runtime, or environment, a lot of the changes needed to get there would be
prolonged, painful, and would provide _no noticeable business value_.

I'm somewhat reminded of Python, where there is the concept of a "pythonic
way" of doing things. There is very much a "PHP way" of doing things, a
"${LANGUAGE} way" of doing things, and of course an "${ORG-SPECIFIC} way".

I'm also somewhat amused at Rails as a frequent comparison. I've also worked
with Rails, and I hated it. It was quite some time ago, I'd probably enjoy it
if I tried again. But I will try to remember in future that opinions formed
from bad experiences need to be reviewed in light of the time elapsed since
then, and my own personal/professional growth as well.

More generally, when I hear a developer (in my own office ;P) espousing the
view that "${LANGUAGE} is garbage", I assign more meaning to the fact that
they choose to make that statement than I do to any particular view of the
language in question.

------
joemaller1
I've been using PHP semi-regularly since the late 90s. It's been empowering
and infuriating.

The ecosystem is radically better than it used to be. Composer and the
Packagist registry are as mature and dependable as npm, PyPI or RubyGems.
(despite hours lost to my own namespace screwups). I'm also happy to see the
Prettier-PHP project automating and enforcing code-style standards.

For whatever reason, I often feel clumsier after working on a PHP project.
After working in other languages like JS or Python, I tend to feel like I've
leveled-up my skills.

One thing I wish PHP would address is the inconsistency in its map-filter-
reduce functions -- their argument-order doesn't match (array, callback) vs.
(callback, array):

    
    
        array_filter($arr, $fn)
        array_map($fn, $arr)
        array_reduce($arr, $fn)
    

The amount of cognitive overhead I've wasted on those is ridiculous.

\- [https://packagist.org/](https://packagist.org/)

\- [https://github.com/prettier/plugin-
php](https://github.com/prettier/plugin-php)

~~~
benp84
I hear this complaint a lot but I find those argument orders completely
intuitive.

You filter (1) an array with (2) a function. You map (1) a function over (2)
an array. You reduce (1) an array with (2) a function.

It follows exactly what I'm thinking when I type it. To reverse the orders
would be, what? "Mapping an array with a function?" "Filter a function on an
array?"

~~~
sim0n
Why is "map an array with a function" unintuitive but "filter an array with a
function" isn't?

------
simias
As far as I'm concerned the bridges have burned a long time ago and I
definitely can't see myself giving PHP a second chance. That being said, if
I'm wrong and PHP has really managed to become a decent language (or at least
something that's not completely insane) its defenders should focus on actually
showing what modern PHP code looks like.

Is performance that much of a big deal for most people? In a world where Ruby
on Rail exists I find that hard to believe. Server are cheaper and vastly more
powerful now than in PHP's infancy, I'm sure that for the vast majority of use
cases PHP's performance (whatever it is) is good enough.

The infamous "Fractal of Bad Design" wasn't about that, it was about the
ridiculously inconsistent and error-prone API, the insane defaults, the
counter-intuitive behaviour of '==', the headless chicken development roadmap
where maintainers would add features because they were popular in other
programing languages without trying to figure out if they had their place in
PHP,...

Surely a lot of this has turned into technical debt? Even assuming that
"modern" PHP managed to come up with better ways to deal with all of this, I
assume that these obsolete functions and operators still linger for backward
compatibility? If so how do you avoid them?

Again, I personally don't really care, but if you want to win new converts who
haven't been as scarred by PHP as I have been I think that's where you should
focus your efforts. Maybe somebody should write a point-by-point rebuttal to
the "fractal of bad design" article?

~~~
chriswarbo
> ven assuming that "modern" PHP managed to come up with better ways to deal
> with all of this, I assume that these obsolete functions and operators still
> linger for backward compatibility? If so how do you avoid them?

I think the "path of least resistance" is important: developers are time-
constrained, understanding-constrained, lazy (if they're virtuous), etc.
There's a big incentive to do whatever is easiest/quickest.

When I last used PHP, about 5 years ago, there were OOP APIs cropping up to
replace many of the standard global functions; namespaces had just been
introduced; closures had become useful; frameworks like Symfony (and Drupal 8)
were becoming established, rather than the old "plugin" approach of throwing
around arbitrary code and hoping for the best; dependencies were being managed
by composer; files could be autoloaded from sensible locations; testing
frameworks like PHPUnit and PHPSpec had become best practice; etc.

Yet _all_ of those things were opt-in and verbose. The path of least
resistance was still:

    
    
        <html>
          <body>
            Hello <?php echo $_GET['name']; ?>
          </body>
        </html>
    

(For non-PHP programmers, this is appending a GET parameter straight into the
page, which is an XSS vulnerability). Doing things "properly" took a great
deal of effort and discipline.

Compare this to something like Java: it favours class-based OOP so much that
even "hello world" needs a class. The path of least resistance is to do things
"right" (from Java's perspective). Haskell's path of least resistance is
simultaneously easier ("hello world" is just `main = putStrLn "hello world"`)
and harder (`main` uses the `IO` type, whose API enforces certain
conventions).

Deprecation warnings, linters, etc. can help with this; but PHP's only real
strength is its installed base of code and developers; changing the language
too much would throw away this advantage (akin to being a new language, see
Python 3 and Perl 6); not changing it enough prevents the more serious and/or
systemic issues from being dealt with.

I wish the language designers and users luck, but I'm really hoping to never
use it again ;)

~~~
rob74
To understand that, you have to take a closer look at its origins. For me,
this talk by Rasmus Lerdorf (creator of PHP) was a real eye-opener:
[https://www.youtube.com/watch?v=SvEGwtgLtjA](https://www.youtube.com/watch?v=SvEGwtgLtjA)
He mentions that what we now refer to as the "PHP language" was originally
intended to be only the templating system, and you were supposed to write your
business logic in a "real language" such as C. However, as PHP got more
popular, bits and pieces were added until the "templating system" became a
full-fledged language. Sounds like this happened more by chance than by
design. And because you can't throw all of that out, it shows until today. You
can introduce new features, but doing that in a way that stays (more or less)
backwards compatible is difficult and forces compromises - see type
declarations, which are actually just type hinting and of very limited use. So
sure, PHP is wildly popular because of its "first mover" status, so it will
probably stay with us for the foreseeable future, and working in it may have
become more pleasant over the years thanks to better tooling, but it will
unfortunately never be as pleasant as in other, more well-designed languages.

~~~
jfengel
That's kinda the problem with any domain-specific language: it either requires
a full language for support, or it becomes one (and generally not a very good
one). Every language is an opinion about what things should be easy and what
things are allowed to be hard.

I've got nothing against DSLs and template languages and such, but most of the
ones I encounter make me sigh and say, "I know you thought it would be easier
but it's just one more thing I have to figure out how to debug, without any of
my usual debugging tools."

------
coblers
Maybe it isn't, but other languages/frameworks have improved the past ten
years as well. I don't see the selling point in building something in PHP in
2019 when you have similar if not better/more mature languages/frameworks at
your disposal.

Won't your prototyping be faster in Go/Python/Node/Ruby anyway, with a more
stable surface to build upon it? I really fail to see where PHP has its place
in 2019. For your "build a minimally viable product fast", the above win. For
enterprise stuff, the good old Java/C# win.

~~~
jbrooksuk
> Won't your prototyping be faster in Go/Python/Node/Ruby anyway, with a more
> stable surface to build upon it?

One of the most understated pros of PHP (IMHO) is that it's so easy to get
setup with. You can start hacking on something so quickly. In my experience,
Go has not been like that. Node.js also was never as quick.

~~~
jeltz
But other languages like Python and Ruby are even easier to get started with
than PHP.

~~~
tenken
I worked with rails in the 1.x and 2.x days. Deployment was a joke and you had
to restart the whole Ruby server to update scripts.

PHP you simply refresh your browser page to see the changes. This has all
changed in recent years and rails deployment/debugging is much smoother.

------
richardwhiuk
And yet ~everything in [https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-
design/](https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/) is still
true.

All that's happened is that the language is even more complex, has even more
baggage.

~~~
alexandernst
I'm not really sure why this comment is getting downvoted, but literally every
single thing in that post still holds true.

~~~
pornel
No, it's not. PHP has disabled or removed the major anti-features like magic
quotes, globals, URL includes and the bad mysql extension. It has a proper
AST-compatible parser which removed tons of quirks, and added syntax sugar to
look more normal to outsiders.

The remaining things are:

• the endless whine about inconsistent underscores in function names and
haystack/needle. These are a bad look, but aren't really an obstacle to using
the language (PHP devs memorize the common functions, rely on IDE or docs for
the rest, and move on).

• being offended about use of backslash as the namespace separator. It really
doesn't matter at all.

• old constructs and edge cases that exist, but are not used in new code.

• general upset about dynamically-typed languages, and all the consequences
and compromises that dynamic typing brings.

That post is just a rant. It presents insignificant/arbitrary choices as flaws
(e.g. "clone is an operator?!" — so what?). Some complaints are totally
ridiculous, e.g. exceptions thrown in destructors were fatal errors, and that
was bad. When the restriction has been removed, the post has been updated to
complain that this is bad too, because now you can throw literally everywhere!
Apparently, no matter what PHP does, it's bad.

~~~
out_of_protocol
> (PHP devs memorize the common functions..

Nope (c) Me, after 5 years on trying to but still falling back to googling
every 20 minutes despite years and years of using the language.

... And just writing code without looking into docs much after a week with
ruby

~~~
deckard1
I'm quite shocked that a common complaint of any language is function syntax.
Maybe it's been awhile since I've used PHP, but is it really worse than any
other language? The problem with PHP is that, at least years ago, it had no
equivalent of C's man pages. In C, you're constantly doing "man memchr" or
what have you. Perl has "perldoc -f sort".

Don't get me started on Ruby, though. Wading through a tower of classes to
figure out where and how some method is defined, only to much later find out
it was actually created by define_method or method_missing is absolute
torture. And yeah, I know the REPL can provide this info to you. The point is:
source code should be obvious in how it functions. Not obscure things through
cleverness.

~~~
innocenat
What are you talking about? I have been using php.net/{funcname} since
forever.

------
tannhaeuser
Rather than chasing MVw or OO trends of the JavaScript ecosystem and become
more like JavaScript or Java, so to say, why don't the PHP developers identify
and build on the unique strengths of PHP? Which are IMO: the large installed
base in classic web hosting, and the original purpose of PHP as a high-level
scripting language embedded in otherwise static HTML as in "<?php ...>". There
is a huge room for improvement there since PHP's quick-and-dirty hackjob of a
page-embedded language isn't HTML-aware and thus prone to injection attacks,
which has caused uncountable attacks, botnets, and other problems _for PHP and
non-PHP sites alike_ , in particular when coupled with PHP's target
demographic. This is especially painful because PHP embeds via SGML mechanisms
(processing instructions), when SGML has all the features needed for context-
aware, injection-free templating. If PHP can improve that story, and stop
becoming the language of unintended consequences and usage-outside-its-
comfort-zone, then it might earn a lot more respect and consideration.

~~~
simion314
Your claims are vague, do you have a specific example of a new feature and a
new mainstream framework that has the security issues you mention?

~~~
ptx
I think the point is that if you use a "new mainstream framework", you lose
the traditional unique strengths of PHP by using it essentially the same way
as you would any other language, so you might as well use a different
language.

So instead of trying to be like other languages but with worse syntax and
weird quirks, PHP could try to improve on the things that make it different
and lead to its initial popularity.

~~~
tannhaeuser
Exactly my point. Thanks for explaining it much better than I could.

~~~
simion314
Your point as related to security, so mention what security problems are in
modern PHP and frameworks.

------
ashton314
I worked at a small PHP shop for about two years. There was a ton of legacy
code that was utterly terrifying: a 13-deep nested `if` and the like, global
variables, etc.

I convinced my boss to let me start using Laravel. It made development worlds
more sane. It made development orders of magnitude easier. Laravel does a lot
for you, and they’ve thought about how to solve some tricky problems in clever
ways.

 _That being said_ , I would never recommend PHP as the language to solve any
given problem. It is now less of a terrible language and more of simply a
mediocre language. I can’t think of anything it does particularly better than
another language. For any given problem, there is most certainly a better
language to solve it, be it Ruby, Elixir, Clojure, Rust, etc.

I’ve been working with Elixir and Phoenix for web development for a few months
now, and it is _sooooo_ much better. It’s hard for me to enumerate all the
things, small and large, that reduce developer friction in contrast to even
PHP’s best framework.

~~~
IloveHN84
You forgot one thing: PHP has a far larger community and packages compared to
exotic languages like Elixir. Everything is documented and there are tons of
resources out there to solve a problem. It's like C++ for the web. Why does
C++ still live? Community, extensively tested and adopted by large
organizations. Well PHP is the same. Until big companies are out there using
PHP (consider Vimeo or Flixbus or Groupon as example), because it is
perfomant, it will fail to die.

~~~
ashton314
I agree with you: strong community support is essential in the survival of any
language/technology. PHP has a large community and a dizzying number of
packages. That helps a lot. But I can think of a number of languages (Python,
Perl, Ruby) that also have large communities and vast numbers of libraries at
their disposal. Therefore, I don't think you could pick PHP over any of those
just because "it has more libraries".

Furthermore, Elixir, while it has fewer libraries and a smaller community, is
growing fast. The core language is also exceptionally well documented and
discoverable. It has libraries that cover essentially all your common use
cases.

I guess what I want to say is, I'm happy PHP is getting better for all the
programmers stuck using it. There's no reason to use it for anything _new_ ,
because there's always a better tool out their for your job.

------
chairleader
I'm working in a vanilla PHP codebase right now, and I see all sides - the
fractal design fails and the surprising improvements to the language. I've
just read up on the architecture of Laravel, and given the public opinion of
it, must be a very nice framework.

What strikes me most about PHP is the fundamental request/response execution
model. Your execution context begins when a request is received and ends when
we send the last byte or terminate the request. There's no startup
healthchecks, no cache warming or any other bootstrapping of your service
unless you jump through convoluted hoops on your own. Your service is either
accepting requests or it isn't. You either lazy load your data into APCu or
you don't. I've leveraged AWS healthchecks to achieve these in the past, but
that path is not very maintainable.

Inevitably in the course of maintaining a service, I find use cases for a
phase of execution that should occur before the server is live or shared
static memory that should be available at all times, but (unless I don't know
something) those are things that PHP doesn't do.

This is the reason that I find PHP to be a bizarro language - for its
fundamental design assumption!

~~~
DCoder
This execution model is just good old CGI scripts [0].

[0]:
[https://en.wikipedia.org/wiki/Common_Gateway_Interface](https://en.wikipedia.org/wiki/Common_Gateway_Interface)

------
johnday
Thanks for sharing. The thing that I am most concerned about with PHP is not,
strictly speaking, the language itself. The syntax is slightly odd but
otherwise fine. And the semantics are much the same as any similar language.

The real problem that I find with PHP is that the designers seem (from an
outside perspective) to take a similar approach towards language backward-
compatibility that, for example, C/C++ have. There is some rejection of the
idea of getting rid of the old, bad stuff. Plenty of new, cool features is all
well and good - but there are still holes in the floor that new learners will
fall through.

[To clarify, I understand the case made by the C/C++ committees on supporting
old code. But nobody's programming pacemakers in PHP, one would hope.]

~~~
gog
The amount of legacy applications being run on the internet is huge. Breaking
stuff would put a great financial burden on the companies running those.

It is a sensible approach IMHO.

What kind of bad stuff are you talking about? If you talk about function names
and parameter ordering not being consistent that is not an issue for
developers using the language daily, most of them are using an IDE so it
doesn't matter as much as people who don't use it say.

~~~
pdimitar
Those legacy applications won't ever be upgraded to that theoretical and
slimmed down PHP anyway, so I don't see a problem.

~~~
simion314
Old PHP projects can be upgraded in the present because backwards
compatibility exists, as i metnioend in other comment I done such a small
upgrade and I hat to change only 1 deprecated function with a different one.

If this would not have been possible the project would have still be running
on an old version without security fixes and slower(eating more electricity so
bad for environment)

~~~
pdimitar
If you say so. ~5 years ago I had to work a full week, 8h a day, to fully
upgrade a medium-sized website from PHP 5.2 to 5.4, and eventually gave up.
Most of the time was spent trying to cope with different datetime parsing
idiosyncrasies.

~~~
simion314
I am sorry you had such a bad experience, can I ask you to give me some link
or details about your issues with datetime , I want to learn about the
problems I do not doubt you.

I had some problems with mysql updates though, new versions had
different)better default behavior). we were using an ORM for the project but
the initial setup and migrations were made in plain SQL and those needed to be
updated. As an example in older mysql you could have a timestamp column NULL
with no default value set and now we needed to fix to set a curenttime as
default.

------
larzang
As a primary PHP developer, PHP has improved by leaps and bounds in the ten
years I've been working with it, however there's still a major fundamental
issue that has seen improvement but remains unresolved: function overhead.

Contrived example: \- [https://3v4l.org/eEtFl](https://3v4l.org/eEtFl) \-
[https://3v4l.org/8QMFh](https://3v4l.org/8QMFh)

Two identical ways to do the same thing, one with nicer FP-like syntax, but
because of function overhead even on 7.3.x it's significantly slower.

If you're building large-scale PHP applications you have to stay away from a
bunch of shiny new features in anything remotely performance-sensitive, and it
causes you to write worse code in general (e.g. this monolith would be a lot
cleaner as multiple sub-functions, but it's going to be called in a loop 5
million times so I have to keep it ugly).

With compiled languages you can write clean code and then have the compiler
optimize it. With PHP, you have to make development-time sacrifices in
legibility and maintainability in order to not make runtime sacrifices in
performance, which is both worse as an any-stage dev and a huge footgun as a
junior dev.

~~~
efficax
Do you really find function overhead to be that great of an impact on
performance? I work on a php app that sees around 15k/rps and I use a lot of
functional patterns (feels best to me, my brain was formed in a lispy way).

By far database time remains our biggest bottleneck, especially since we
finally made it onto PHP7

------
ch_123
> Do you remember the popular "PHP: a fractal of bad design" blog post? The
> first time I read it, I was working in a crappy place with lots of legacy
> PHP projects. This article got me wondering whether I should just quit and
> go do something entirely different than programming.

Seems like a pretty extreme reaction - how about trying a job with something
other than PHP?

~~~
brendt_gd
You're absolutely right. I think it's fair to say that I was closing in on a
burnout, which made me think irrational.

Like I said: I was lucky being able to switch jobs, and re-discover my passion
for programming

------
scandinavian

        php > echo count(get_defined_functions(TRUE)['internal']);
        1196
    

They should clean up the global name space, but that will never happen, so
I'll continue not using PHP.

~~~
jbrooksuk
Why does the number of methods in the global namespace bother you?

* Genuinely interested in the rationale behind this. Sure, it's a lot, but why does that matter?

~~~
itwy
Complaints like this one make PHP seem perfect.

------
jbverschoor
It's funny how shitty decisions in tech always seems to win the masses, only
because it's easier to get started with. And only 10 or 20 years later, a
great amount of effort is put into patching all of this.

"Good tech" is created by people with a lot of knowledge of a specific domain.
For them, it all makes sense, but the mental modal does not map to newcomers.

"Bad tech" is usually forgiving (messy syntax, accepting bad data etc), so
people don't get stuck.

The solution is to have good tech with proper tooling and hints /
error/configuration reporting.

apache, php, mongo, mysql, javascript.. They all have the exact same
strengths, weaknesses, quirks, bad decisions, and mass adoption.

------
xrd
I think the way to analyze a language and framework should be: "what does this
framework permit the worst developer on the team to do?"

I think the story for Php in this regard has not been a good one historically.

You can put processes like PR review, and add coding standards, but getting
things done will always trump those things, especially when you are
bootstrapping.

If you can tell me modern PHP is better than the alternatives at preventing
bad behavior (or encouraging good behavior) then I'm interested. But, this
post didn't move me to change my mind there.

~~~
xrd
For example, coding standards:

`There MUST NOT be a hard limit on line length; the soft limit MUST be 120
characters; lines SHOULD be 80 characters or less.`

[https://github.com/php-fig/fig-
standards/blob/master/accepte...](https://github.com/php-fig/fig-
standards/blob/master/accepted/PSR-2-coding-style-guide.md)

A language that has to permit this kind of thing (or thinks it has to) is just
going to lead to developer infighting. This is an important issue because
GitHub PRs are going to be unreadable if one developer can insist that "this
line needs to be 145 characters..." and then no-one can diff changes to that
code. You can break the PR process with this kind of thing.

~~~
zerocrates
I'm not sure what this has to do with PHP as a language... barring the few
languages with a very strong default formatting convention like Go, code style
differences are both a fact of life and not terribly problematic (set rules
for the project and enforce them automatically).

------
DJBunnies
I'm hiring PHP developers in Boston!

Doctrine, symfony, AWS, all backend API work.

~~~
esistgut
If you are doing API with Symfony you may want to check API Platform:
[https://api-platform.com/](https://api-platform.com/)

------
icedchai
Developing a database driven web site with a modern PHP framework, like
Laravel, is very productive and quite pleasant. PHP is fast enough. It's
simple to deploy. It's easy for "non-engineers" to get involved with:
designers can edit templates, see the result instantly, no build issues, etc.

For my day job, I do Python and Java... For side projects that are database-
driven web apps, PHP is perfect.

------
cletus
The sad thing is that nothing else has come along to fill the niche that PHP
fills. Here are the key advantages of a PHP like language:

1\. Low barrier to entry. An HTML document is pretty much a valid PHP program.
You can add as much or as little code execution as you want to it. While at a
certain point you should probably use templating (to handle things like
escaping automatically, etc) but a low barrier to entry really helps get
people on.

2\. PHP has a stateless functional core. All the system functions are part of
the web server binary. There's no loading some giant object tree just to print
something to the screen. This is huge because of...

3\. Resource management for serving HTTP requests is, to me, basically ideal
in that you create a bunch of stuff, spit out a result and then tear
everything down. It's hard to leak resources this way. No garbage collection
oddities to deal with. The Java equivalent to this was the servlets API (years
ago) but it doesn't share the same issues;

4\. No multithreading on a per-request basis so you don't have to deal with
race conditions at all in user code;

5\. An opcode cache sufficiently closes the gap on code performance in the
vast majority of cases at little to no cost to the end developer; and

6\. Typically you can just hit reload on your browser and immediately find out
if something works. That's really nice.

Big things missing from PHP:

1\. A good type system. I use Hack at work (Facebook) and this solves a lot of
problems; and

2\. Cooperative multitasking via async/await semantics (again, Hack has this).

I'm a big fan of PHP not making breaking changes (badly) like Python did. You
can't fix the inconsistent argument ordering in standard functions ("is it
needle, haystack or haystack, needle?") but it basically doesn't matter at
this point. I use an IDE that tells me the correct order anyway so who really
cares? The way to handle that is to create new versions that are consistent.

Hack has these collections: vec, keyset and dict. These essentially replace
array (side note: PHP maintaining insertion order on array is such a hugely
useful feature). They have a consistent set of library functions (in C\, Vec\,
Keyset\ and Dict\\).

One other thing that I found hugely useful when I first did PHP was
preg_replace_callback. I found this so useful that when I did Java after that
I basically write a version of this function.

So anyway, there are a ton of legacy problems with PHP but nothing else has
that same set of desirable characteristics IMHO and I really wonder why not.

------
kijin
Not only did PHP clean itself up a lot in the last few years, it also managed
to do so while maintaining a great deal of backward compatibility.

It's not uncommon to pick up a really old library that used to work in PHP
4.4, stick it in a PHP 7.3 project -- maybe you need it to import legacy data
-- and experience no issues whatsoever. You can probably also use the library
in question in parallel with a modern dependency management system like
composer, or any framework built on top of it, without any conflicts. This is
Windows-level backward compatibility, and I mean it in a good way.

Why would anyone want that in this day and age? Because there are tons of
legacy PHP code that still power a very large fraction of the web. Not
everyone is writing new projects from scratch. Not everyone can afford a total
rewrite. PHP's backward compability allows people to transition gradually at
their own pace. It might not be sexy, but it gets the work done, and it just
keeps working. That's all that matters for many, many businesses out there.

------
tluyben2
I have kept up with PHP since I replace my own 'PHP' which was a Perl cgi
script. It is not as crappy as it was and Laravel is quite nice, but there is
still so much crap in there, compared to modern languages, libraries and
frameworks, that I only do maintenance on projects (upgrade Laravel, port to
Laravel etc) but would never start a new project on it.

------
LoSboccacc
eh my problem with php never really was performance (up to a point) or the
language itself, it was the default library making figuring out every
operation an exercise in googling

like, why the weird _ difference between strtok and str_split, why str_replace
has the search first and string as third parameter but in strpos the source
string is the first parameter and then the search term the second

it's all confusing and weird and while someone that's a specialist is maybe at
ease with this, for a generalist going in and out the language as needed it's
frustrating.

~~~
maxxxxx
When I did more PHP I quickly ended up writing my own sort of standard library
with consistent functions and unit testing. It doesn’t really take much time
and makes things much more predictable.

------
golfer
So much of the web is powered by PHP. Wikipedia (MediaWiki software) and
Facebook are two of the largest footprints of usage. And of course, WordPress.
PHP has a lot of firepower behind it.

~~~
Shish2k
The Facebook www code is written in Hack, which started off as a PHP-
compatible language / stdlib, and then dropped PHP compatibility when it was
holding them back.

Having worked with both, any one of the major additions (XHP, good type
annotations, sane collection types, etc) makes my development experience 10x
better; going back to vanilla PHP now just makes me sad...

~~~
noir_lord
Collection types is a big one for me, I miss those like crazy when working in
PHP.

------
lasermike026
PHP isn't going anywhere. PHP is fine. Perl, Ruby, Python, all fine. That
being said, for general programming TypeScript/JavaScript is the way forward.
Other than PHP, I have loved all these interpreters. It's over. Accept the
middle and move on. Everything else is nitch.

------
maitredusoi
Benchmarking should be made with a more real world point of view:
[https://www.techempower.com/benchmarks/#section=data-r17&hw=...](https://www.techempower.com/benchmarks/#section=data-r17&hw=ph&test=json)
tries to do it ...

For me [https://github.com/the-benchmarker/web-
frameworks](https://github.com/the-benchmarker/web-frameworks) is just testing
the routing system (e.g. in the rails case def user render plain: params['id']
end ) ;)

------
Roofduck
The question for me is what can PHP do better than any other language out
there?

I've worked with Laravel for a few years and while it has sooo many great
features out of the box, it doesn't quite detract from how unpleasant working
with PHP is, when comparing with any other common/modern language. Of course
this is only my opinion and experience with it.

I don't think I would ever recommend PHP to anyone unless they live in an area
where you can only find PHP job opportunities. Otherwise, any other language
can do what PHP can do and will provide a better programming experience IMO.

------
fbn79
I develop on PHP from 2 decades. I loved PHP. I took 2 Zend cerfications as
PHP engineer. After working in Javascript projects for some time on client and
node.js, and after learning basics of functional programming I think PHP is
really horrible as language. The only thing that I think make it still unique,
is the REST nature of the web server integration. Every request is world
apart. The script starts and end with the HTTP request(exceptions here). This
make it really easy to understand and scale.

------
derefr
I always wondered, in a world where

1\. people seem to hate writing (old?) PHP, and

2\. there are a good dozen languages that were created solely because people
hate this other language _Javascript_ , which both compile to Javascript and
have the semantics of Javascript, just not the syntax or stdlib of Javascript;

...why we didn’t end up with languages compiling to PHP, targeting the Zend
VM, or whatever you’d have to do to get the PHP module in Apache to interpret
non-PHP code.

~~~
dajonker
Because Javascript is the only thing that runs on the client side.

~~~
derefr
And for many “LAMP” hosting environments—such as the tiny ones many ISPs
and/or universities hand out like conference swag—(secured, sandboxed) PHP is
the only thing that runs on the server side. Same with many “WordPress
hosts”—they don’t let you run code per se, but they let you install arbitrary
WordPress plugins, so you could deploy your own code into the site... if
you’re willing to write PHP.

(Secured) PHP is used by these environments in about the same way that Server
Side Includes and .htaccess files were used by Apache in the late 90s: as a
way to give users the ability to add some dynamism to a website, without
actually giving them a Turing-complete environment that they could use to run
bots on.

And yes, I’m not being facetious, it’s _really_ not Turing-complete: most of
these environments have fixed request timeouts, fixed memory quotas, and no
ability for the runtime to write to disk or make network requests. So there’s
no infinite tape! This is “PHP as pushdown automata.” ;)

As such, the language I’m talking about would actually have to be built to
understand that it it’s operating in this super-limited environment (more
limited than PHP normally is.) I would expect that this would be presented
less as a “programming language” per se, and more as something you can use in
a Static Site Generator to inject a bit of server-side dynamism to your
generated “static” site.

------
coblers
It might not be, but how does it fare against similar languages?

I have no idea why you'd choose it over Go/Node.js/Ruby or similar for your
standard webdev stuff.

~~~
EugeneOZ
All apps I saw, written in Ruby, were awfully slow. I don't know Ruby, maybe
it's just me, but would be interesting to know examples of not slow Ruby apps.

~~~
cntainer
Well, github, just to name one:). Also shopify, digital ocean, stripe. I also
worked on a large ruby app that was faster than another large Java app. Keep
is mind that all these platforms handle a great deal of requests at any given
time, so we're not talking simple web apps.

In my experience bad software design, bad DB design and bad developers are the
major cause for performance issues, you rarely get to that level of polish
with your app that the difference between different languages really matters.

At micro-bench level PHP always beats ruby pr python, but most apps have
performance issues without ever getting to that level.

My funnies experience was with a java team that where baffled why their app is
slow. I told them it looks like they have a huge bottleneck on the DB, their
answer: "Yeah but it's java, it should be fast"

~~~
return1
github is terribly slow... or maybe it's just me?

~~~
cntainer
It's usually fast for me with the occasional slow down.

From experience (did some code contributions to gitlab) when you work a lot
with the filesystem, as is the case for platforms hosting git repos, you will
have performance issues related to that, regardless of the programming
language.

we host gitlab at my company for internal use, just switching from SSDs to
HDDs made a big difference in terms of response time for big actions like
opening a merge request, etc

I'm sure there are apps in the wild that get to that level of optimization
where you need to decide on a different language. But what I've usually seen
is you just slice that part out into a service and only rewrite that part.

I think stripe and others are basically doing this if they do hit the limits
of ruby in very performance intensive workloads.

------
majewsky
If the author happens to read this thread: Please please please use a
different font. Serif fonts with very dynamic stroke strengths look awesome in
print, but they break down on screens where the narrow strokes round down to
0px and vanish. Although I'm reading this on a HiDPI notebook display (1440p
over 13"), I have to crank up the text zoom to at least 150% to be able to
read the article comfortably.

------
bartimus
> Back in the 5.* days, PHP's performance was… average at best.

Even with 5.* it very much depended how you used it. The real world
scenario's. PHP functions are written in C. You could make great gains by
leveraging on them. Using PHP as just the "glue" for a blazingly fast library
(and templating engine) written in C.

------
guggle
Do we have still to use mb_* functions to deal with utf-8 ? That was a major
PITA when I used to write PHP.

~~~
malinens
No

~~~
guggle
How ?

    
    
        ~ php --version
      PHP 7.2.17-0ubuntu0.19.04.1 (cli) (built: Apr 18 2019 18:01:25) ( NTS )
      Copyright (c) 1997-2018 The PHP Group
      Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
          with Zend OPcache v7.2.17-0ubuntu0.19.04.1, Copyright (c) 1999-2018, by Zend Technologies
        ~ cat test.php
      <?php
    
      echo strlen("ùé");
      echo "\n";
      echo mb_strlen("ùé");
      echo "\n";
        ~ php test.php 
      4
      2

~~~
CiPHPerCoder
The answer is: Composer + Packagist. There's almost certainly a library that
handles it in a sane and transparent manner for you so you don't have to deal
with the pain.

------
myspy
Working with Laravel for more than a year now and it enables writing quality
code. Testing is nice, as is building models, routing, validation, and
authorization.

PHP itself is not that important. The language is solid and does its stuff.
I'm moving mainly in the framework to create functionality.

------
cutler
I just took a random sample from Spatie's PHP libraries -
[https://github.com/spatie/crawler/blob/master/src/Crawler.ph...](https://github.com/spatie/crawler/blob/master/src/Crawler.php).
Most of the code consists of:

    
    
        public function getSomething(int $someParameter): SomeType {
            return $this->someParameter;
        }    
    

If this, along with the fanfold block comments you see in modern PHP, is
considered "clean code" I'll take procedural PHP4 any day of the week. Why
PHP5 had to be reborn as the scripting version of Java I'll never understand.

~~~
kbenson
It's been close to a decade since I did anything in PHP (PHP5), but since I
know PHP5 had public (and private,and protected) accessors back then, but
didn't have any real typing of parameters if I remember, I assume this is a
design pattern to enforce typing on the object parameters. Also, a good amount
of them have some other guard that throws an exception on specific problems. I
think it's a valid design choice to decide that since some object variables
may need special handling that is accomplished through accessor methods, just
create them specifically for each item that needs public access, and while
you're at it throw in a few sanity checks. That provides a _consistent_
interface, where accessors are both named and act in the same manner (i.e. you
don't have mixed method call and direct assignment).

------
75dvtwin
I would say, that PHP faired through time much better than Perl.

May be is Facebook's investment in the platform, may be it is wordpress , the
PHP's 'killer app'.

I invested into building a system in PHP in 2010 (and using ignite as
framework), when opportunity came to redo it, recently , I picked Java
(besides type safety, I also had to build a client as an Android app, so
sharing classes across both was another reason for Java).

I would also say that 'health' of a particular language+ecosystem should be
measured by 6 variables.

1) new project uptake (OSS) -- eg how many new projects are created using
particular language.

2) existing project updates frequency (OSS)

3) leavers (how many projects leave this ecosystem)

and same for non-OSS projects (where this can be measured)

------
stunt
Most of the people defending PHP are talking about PHP7+, and most of the
people hating PHP are talking about PHP5-.

Both groups didn't experience what the other group did and they are not
talking about the same thing. So it is kind of pointless discussion.

The language itself has improved a lot. It is easy to find decent PHP7+ code
now. It is also easy to find bad code.

And that is the same for all major programming languages in terms of usage. As
Java got more popular, it was easier to find crappy code everywhere from
people that only learned inheritance from OOP. More projects mean more
technical debt for the future. So you always find more critics against most
popular ones.

------
dvfjsdhgfv
From [https://thinkmobiles.com/blog/php-vs-
nodejs/](https://thinkmobiles.com/blog/php-vs-nodejs/):

> Node.js is faster than PHP only in adding numbers.

------
caseyamcl
I’m going to chime in here and say that I stayed with PHP through the roughest
years.

I’ve only seen positive changes in the time since then.

I’ve made a good living from writing code and I don’t see any reason that has
to change.

------
beager
I'm impressed with the evolution of the language and the tooling around it,
driven by the necessity to scale and maintain apps for big businesses.

Nevertheless, I would think that PHP is a hard sell for new projects and new
enterprises. Unless you're a dyed-in-the-wool PHP junkie and you're bringing a
team that is the same, there are a multitude of reasons why you'd want to
choose a different language for web dev work.

------
sputr
I'm more and more surprised that Laravel is so often mentioned over Symfony in
this types of debate.

I've worked with both and done professional projects in both. While both are
great, I would have to sing some praise for Symfony's developer experience and
tooling. But realistically the're neck and neck.

PS: It's really funny seeing people seriously discuss PHP when they themselves
have not tried it since the 5.* days.

------
cwaffler
Yeam im really digging php these days. Composer and Laravel have made it
fuggin awesome! I think more so the frameworks built when php was first
picking up steam are a little convoluted and oldschool (im looking at you
drupal!... 6 & 7, mostly). The language has come along way since then though,
so thanks to the team for all their hard work.

------
joeleisner
In all honesty, Laravel has been a blast to create projects with. Prior to
that framework, I had very little experience with PHP or any back-end
development. It's simple to setup, has sane/safe defaults, and it scales well
with the complexity of projects. Can't recommend it enough!

------
bradezone
Personally I'm a fan of the Phalcon framework. It's also structured similarly
to Laravel/Cake/Rails but is compiled into a PHP module and thus runs super
fast by comparison. PHP has certainly improved with the 7.x line so I'm happy
to continue using it.

------
wyqydsyq
I respect the leaps PHP has come as a language and runtime in recent years,
however I still can't understand why anyone would elect to use it for
greenfields projects.

The developer experience might be better than it's ever been, but even as
pointed out in this article, it still has all the old issues like inconsistent
core API, vague global context, and way too much implicit magic and guesswork.
Not to mention it still relies on running a separate, third party HTTP server,
in contrast to Node.js, Java, Python etc stacks where the HTTP server itself
is a native construct of the language/runtime.

I can't see any single use case where there isn't a more appropriate
alternative to using PHP. The only feasible reason I can see someone would use
PHP for a greenfields project in this day and age is that they simply don't
know any better.

"I suppose it is tempting, if the only tool you have is a hammer, to treat
everything as if it were a nail."

~~~
jtreminio
> it still has all the old issues like inconsistent core API

Seriously, people keep bringing this up. Why? Are you a machine? Did you
memorize the API to every single language you write in? I type `strst` and my
IDE autohints `strstr()` and the argument order.

> vague global context

What's vague about it? What does global context even mean in this sentence? Do
you mean like super variables? Static properties? Can you provide some detail?

> Not to mention it still relies on running a separate, third party HTTP
> server, in contrast to Node.js, Java, Python

You _can_ run your website using only the built-in webserver for those
languages, but are you really going to do that? Or are you going to put Nginx
or Apache in front to do what they're made to do: be webservers? Hell, there's
Unicorn, Passenger, Puma, all aimed at doing exactly this.

And surprise, surprise, PHP also has a built-in webserver you _can_ use, but
shouldn't.

There's even ReactPHP, Swoole, Amp, all with webserver capabilities.

Sounds more like a person who knows PHP in passing, or may have used it
lightly, or long ago.

~~~
wyqydsyq
> Did you memorize the API to every single language you write in?

No, that is my point. Languages with consistent core APIs are more easily
discoverable, less error-prone and result in developers being less reliant on
editor hinting. Writing PHP requires to you memoize random shit like the fact
that json_encode() accepts options via bitmasks, inconsistent with the rest of
the language for no apparent reason.

> What's vague about it?

\- Imports/namespaces are not explicit (no intuitive way to know what methods
are being provided by a given import without diving into it's file)

\- All HTTP input (remember, PHP basically exists to script HTTP responses) is
magically provided through vague superglobals that are set to wildly different
values depending on what HTTP server you use and how it is configured

\- Variables are all declared in global scope by default

> You _can_ run your website using only the built-in webserver for those
> languages, but are you really going to do that?

Yes. Unlike with PHP, running a single-process HTTP server does not result in
thread locking for most other languages as their HTTP implementations are
asynchronous by nature. There are currently some PHP community projects to
implement async i/o, but there isn't even really any point trying to use them
given PHP is meant to be having native libuv support eventually which will
more or less make them redundant. And even then, why would you go to all this
extra effort reinventing the wheel if not just to be stubborn and avoid having
to learn a new language which is better suited to the task at hand?

> Or are you going to put Nginx or Apache in front

I hope you realise that other than for traditionally CGI-executed runtimes
like PHP, Ruby and Perl, external HTTP servers like Nginx and Apache are
almost exclusively used as a reverse proxy for things like load-balancing and
SSL termination and have little to no involvement in processing and responding
to the actual HTTP requests, which is typically left up to a HTTP server
implemented in the application code.

Sounds more like you have little to no experience with web services outside
the PHP world.

~~~
jtreminio
> Writing PHP requires to you memoize random shit like the fact that
> json_encode() accepts options via bitmasks

Several other functions use bitmaps. It's a convenient way to string multiple
options together without needing to pass key:value arrays. It's in the manual.
My IDE typehints this for me. It's well documented. If you're surprised by
this it's because you're using a text editor. Do folks write c# outside of
Visual Studio? I can imagine some people might enjoy writing Java in
notepad.exe but that's simply not for me. Why would I subject myself to this?
Why make programming harder than it need be?

> \- Imports/namespaces are not explicit (no intuitive way to know what
> methods are being provided by a given import without diving into it's file)

So you need to know ... what you're importing. This is difficult for you? If
you don't want your IDE to typehint on the namespace, you need to open the
stuff you imported. Honestly, you're reaching.

> \- Variables are all declared in global scope by default

I don't understand why you would think this is unique? Any variable declared
in the global scope is ... global scoped?

[https://playcode.io/317387?tabs=console&script.js&output](https://playcode.io/317387?tabs=console&script.js&output)

If you look at RoR, running `rails server` spins up a webserver using Puma.
Why wouldn't RoR use whatever built-in webserver Ruby ships with? I admit I am
not as knowledgeable in Ruby or Python as I am in PHP, but what I do know is
that a 5 minute Google search shows me that very few places on the internet
recommend exposing Ruby or Python directly to the internet, and instead
Unicorn, Passenger, etc are recommended.

Why is this even a point of contention for you? Why would you think doing
this, or being able to do this, would be a positive?

------
hiccuphippo
The thing I like about php the most is how all the different frameworks have
come together to create standard interfaces for building frameworks. I was
able to easily create my own microframework using packages from zend, symfony
and the php league.

------
lukaszkups
I'm a front-end guy (with bit of Node.js experience) and I would like to learn
PHP and Laravel properly - do you have any suggestions where to start (I would
like to learn strong PHP fundamentals as well, not start from Laravel
immediately)

------
spacemanmatt
The thing that burns me so much about PHP is all the crap in php.ini that
should be configured by applications at runtime. The container vs programming
language mindset is basically my biggest architectural/cultural peeve.

------
d33
Is the debugging experience finally any more bearable?

~~~
Lazare
The debugging experience is very good, actually. Certainly comparable to other
languages.

------
bayesian_horse
It's true.

I'd like to say it's a new crappy language, because that'd be funny, but it
wouldn't be true either!

------
pragmaticlurker
definitively much better than other programming languages out there,
especially when it comes to MVP.

Fast, easy and flexible.

CakePHP is a wonderful framework and the community support is simply huge
(orders of magnitude bigger than Java and C# for instance).

Don't forget that PHP runs 70% of internet (where also Wordpress and Magento
are big helps)

------
fruktoed
Php here to stay, I personally hate it, but respect for such a long successful
journey since 90th last century.

------
startup23
Disclousure: Amezmo creator

The PHP community and eco system is only getting better every year, and the
language continues to advance. PHP is one of the easiest platforms to get
started with. I built Amezmo to automate the modern PHP server infrastructure
and deployment. Check it out at
[https://www.amezmo.com](https://www.amezmo.com) \- Use coupon code FRIEND

------
nathan_long
What's the concurrency story in PHP - does it use 1 thread per incoming HTTP
request?

------
CodeSheikh
Does one still debug using var_dump()? Disclaimer: I have not used PHP since
2010.

------
alexandernst
Does it have an actual debugger already? Or are we still stuck with xdebug?

~~~
LeonM
What's wrong with xdebug?

Sure, xdebug requires a graphical frontend to be practical (I use phpstorm),
but so does GDB.

Debugging with xdebug has been a really good experience for me. Much better
than python or even GDB for C code.

------
nikdaheratik
I've spent basically two years working to convert a legacy project built on
PHP 5.x into Laravel on PHP 7.x and I can agree that it's come a long way as a
language, and that frameworks like this help.

The biggest issues, however, are not technical but are based on changes in the
development philosophy overall. The legacy project was written by people who
envied Java and its object system and wanted to make everything an object.
Laravel (and similar projects) have moved towards something that is a mix of
object-based approaches and Functional/Lispy approaches. This puts it more in
line with the direction alot of languages (JS, Rust, etc) have been taking.

TL;DR: PHP is in a better place than it's been in awhile, largely because it's
willing to borrow good ideas and execute them while still being able to make
use of its legacy libraries when needed.

------
pancakespls
I can't imagining switching back to PHP, even if it is much better than it was
before. It has to _surpass_ other languages.

------
jokoon
I wonder, wouldn't it be possible to generalize the work that was done for JS
with V8 to a variety of languages, to target something like LLVM? Can't most
interpreted language be targeted to a common ground?

Anyhow, I've generally avoided a lot of languages. For now my choices have
boiled down to C++ and python, and I've even used brython instead of client
side JS. I either don't touch other languages, or just thread very carefully.

My cynicism is usually yelling out to nuke all existing things, including HTML
and JS, to favor something new, clean, less bloated, so that it can possibly
run well on smartphones. I just wish public research and engineering entities
like DARPA could come up with something better. I think C and by extent C++
are already that, but crowds of nerds will keep moaning about out of bound
arrays.

HTML freed the web from the grasp of greedy capitalists, but now it has done
its job and a lot of things should be put away. Aren't there tools to optimize
HTML rendering for speed?

------
no_wizard
As someone who deeply misses Python (warts and all) and due to a job change
forced to take on PHP (thankfully, we are on an aggressive language versioning
schedule, so we're already on latest 7.3) as the full time language of of
choice, I miss a few things that just make me want to pull my hair out:

For what its worth: I used (and personally still use) Python 3.6+ so the
comparison is with that.

1\. Async programming. While in Python its not perfect, having it baked into
the core of the language makes so many things trivial like processing jobs
between requests and sending the results back later, or having a simple queue
for persisting data to a database after validation has been done on the data
(Marshmallow is my hero for this).

2\. Not having to worry about all the strange things you have to worry about
when everything has to be re-built per request. While I understand WSGI
requests are definitely this (kind of, usually you have a daemonized runner
that keeps your app alive even then), your entire app did not spin down
between requests like it does with php. Simply having to rebuild everything
every single time a request comes in (even when using php-fpm, more or less)
drives me insane, because I can't just send some data off to another channel
in memory easily, or sleep a generator in a position and resume it when I need
to. Everything has to be handled in said request. This kind of goes along the
same lines as number 1, but its sort of a different problem (in particular, I
think generators in Python are very elegant in comparison to lots of other
languages, not just PHP (looking at you javascript), but PHP generators feel
worthless unless I'm reading something line by line from a file or some other
external resource, or I'm iterating against say, a doctrine array result)

3\. Your app is full stop dead without a cache if you are planning on doing
anything interesting. I don't just mean like opcache, but even small
applications have to leverage this (APCU at a minimum), because of the
aforementioned problem of nothing being alive after a request has been spun
down. Yes, I have leveraged caching before, and yes I leveraged it all the
time with python, but for just getting a quick prototype feature out the door,
and adding those kind of layers later, I really miss that. Try iterating
through database results non-sequentially, where you have tons of variable
conditions on how that data needs to be shown, its a pain in the ass without
caching aggressively (this is unfortunately a very real scenario I have to
deal with all the time. We have non linear questionnaires in my current job I
have to deal with, and the questions have to pass a certain validation and
then we either have to get the next immediate result, or skip `x` ahead,
without really knowing whats what or having any real idea of what anything may
be keyed to. I'm open to suggestions if anyone has a good link or something to
read on this kind of problem. I have not found it easy to work through
personally with php)

With all that, Its been an OK experience though. Not my favorite language (may
never be). However, if I was to postulate further, if PHP doesn't start
gaining traction on these issues (and no, the weird async extensions are not a
replacement for any of this. It needs to be core to PHP and maintained as
such, for it to work in the language, in my not so humble opinion), it will
eventually be supplanted in full even where it may have some strengths.

Unfortunately, nobody working on the core of the language seems to care about
this at all.

------
pictur
a vicious circle

------
nippler
Falling for the php meme lmao

------
bovermyer
My major side project does most of the heavy lifting in an API written in Go,
but the front end is a Laravel app.

It works nicely, is easy to make changes to, and gets out of my way.

/shrug

------
thibran
I would argue that Kotlin is the better modern PHP. Beside of a lot of magic
Laravel makes PHP okayish, but it is still the worse mainstream programming
language.

~~~
jbrooksuk
> but it is still the worse mainstream programming language.

Please back this up.

~~~
thibran
This is my opinion.

Some hints why I think PHP is not great:

* property type declaration in doc-strings * bad documentation * verry verbose for a dynamic language * a lot of inconsistencies * automatically loading of classes is a hack (psr4) which doesn't support importing functions without specifying it in a global project file

~~~
highesttide
As a note, typed properties are coming with 7.4.

~~~
thibran
And I welcome it. Also the shorter anonymous function syntax will improve the
current situation by a good deal.

------
baybal2
> PHP isn't the same old crappy language it was ten years ago

But it is too late. JS on the backend has nearly completely ate its mindshare
in its target demographic.

I think, JS itself risks ending up like this if core developers in Node and
TC39 will not begin to think of the need for JS 2.0 and fixing fundamental
design issues, and bug-o-features.

~~~
swah
I usually code a backend in Go or Python, but recently been thinking if I
should just abandon my "prejudice" (JS sucks, Node sucks, Node is single
threaded, there are no SQL libraries, etc) and move to JS on the backend as
well, since that's what I already use on the frontend - be it web or React
Native.

(I actually find JS very expressive and oriented towards a style of "table-
oriented programming" which is useful for software that changes a lot like UI,
IMO).

~~~
baybal2
> (JS sucks, Node sucks, Node is single threaded, there are no SQL libraries,
> etc) and move to JS on the backend as well, since that's what I already use
> on the frontend - be it web or React Native.

My prejudice is the same. A lot of JS and its ecosystem feels to me to be
broken by designs, but you have an option to use a boutique option of
Scala/Dart/Go that nobody uses (relatively speaking,) or JS which is broken as
a language, but is OK as a work tool.

JS will fall just like PHP, when it will be bested by the next better tool for
"quick and dirty" programming, because Node and TC39 delayed the "2.0" change
for too long.

What I feel already is increasing awareness of real world JS performance
limitations, and people beginning to speak about JS sponoffs with native
types, and further direction of work on things that sprung up from ASMjs

~~~
coblers
Putting Go in the same box as Dart seems a tad insulting - it's not that much
of a niche language anymore.

------
aacanakin
"While async and await are not available yet, lots of improvements to the
language itself have been made over the past years"

It's 2019 guys. Please.

~~~
yzssi
It's good if they take some time to think about the implementation instead of
doing a crappy job like Python did.

~~~
makapuf
Cani you please elaborate a bit how python Async await is crappy ? Not
defending anything but I'm curious. Is it in the language or its
implementation ? I've found the loop choices and relationship with dbus loop
or other internal libraries cumbersome on Linux but that is implementation.

------
paulcarroty
Thanks, modern JavaScript is much more better & profitable than
not_a_crappy_language_anymore today.

If you're 60, you can still use PHP for legacy projects, but no sense to learn
it now and kill your career. Market matters.

~~~
megous
As a seasoned PHP dev, I can actually see where nodejs sucks. Things that are
native functions or part of default extensions in PHP, I have to hunt for on
npm or be responsible for re-implmeneting from scratch. And PHP has a _lot_
integrated.

It sucks if you know you can whip out a single call in PHP, but have to search
for an hour in npm and not really find anything satisfying - all the while
knowing that in PHP you'd already have been doing something more useful.

