Hacker News Reader

Comment by mpartel | Hacker News Reader

Having followed and at times heavily used PHP since the 4.x times, its story seems to be that of slowly (and begrudginly?) accepting modern language features like classes, exceptions, lambdas, GC, static typing, etc., sometimes getting things wrong on the first try but still mostly converging towards modernness.

That begs the question, what's PHP's value proposition for new projects? If PHP mostly chases feature parity with Java/.NET/TypeScript and doesn't attempt to do anything better/different (like Elm/Haskell/Rust/Go/Erlang arguably do), then why choose it?

View on HN

I am currently working on a web application with two PHP components - one light base application in vanilla PHP, and an administration app driven by the same SQL database using Laravel.

I am having a complete joy building these components, and I find two things to be striking:

My base component does not use a single dependency and it accomplishes a lot! It is really amazing what can be done in PHP with very few lines of code without the help of ANY external libraries, efficiently. I use PDO for connecting to the my SQL database, which is available natively... It can all just be very simple.

On the flip side, my administrative component is driven by Laravel, which yes, took heavy inspiration from Ruby on Rails, but by this point has greatly surpassed it and is very powerful and enjoyable to use.

PHP is the only server side language I would say I have achieved mastery in, so while I am naive to what could be better in X or Y language, I never currently feel held back for what I need to do, and I enjoy doing it.

If you are working in the web niche, what are the reasons not to choose it?

I mean, it's no longer horrible I guess :)

With mainstream languages, there's rarely any single clear and/or insurmountable problem, it's all the little annoyances you run into every day that add up, plus the cognitive load imposed by the language directly as well as indirectly through the code it lets you write.

I'm not 100% up to date on how much PHP has closed the gap in the last few years, but subjectively I never found it anything but tedious due missing features, various unnecessary pitfalls (sometimes with security implications), silly limitations (you can write a static type in this case but not in that, you can catch this error but not that, no inner classes, etc etc.), and numerous other small cases of poor "ergonomics".

The "batteries included" nature of the standard library is nice, and in contrast to the somewhat fragmented world of RubyGems or NPM it can feel downright pleasant, but finding a SQL library or such is a pretty small effort in the scope of a project, and (popular) 3rd party libraries tend in my experience to be better than the equivalent standard library stuff in most of the languages I know. Every time I wrote a non-trivial amount of code with PDO, I had to look up the correct initialization rituals to get sane settings and copy or recreate a bunch of more or less "obvious" helpers. I'm sure there's something better in Composer by now.

There has been substantial gap closing in the past few years and I understand where a lot of the initial hate came from.

This fairly-recent hour long talk covering the 25 year history of PHP by its creator was very good, if you're into that sort of thing =)

https://www.youtube.com/watch?v=wCZ5TJCBWMg

As someone who works in web I have to deal with javascript also, and always enjoyed that too, until node and npm became standard tools. Now everytime I have a project that involves npm I end up wanting to tear my hair out eventually.. I have not had similar issues with Composer.

If you don't have to mess around with PHP extensions, then it all works like magic. Depending on your environment and which extensions you need though, they can be a pain in the ass and then it's more or less the same as managing external libraries.

Thanks, I hadn't thought about that =)

PHP's value proposition has always been one thing - ease of deployment. Seriously, all you need is one install command, one command to start the services, one to git clone the files and one for certbot. And you have a fully functional deployment ready in a single script that can be deployed at scale.

No other language can even come close.

These PHP praises frankly sound like trolling. No other language can even come close? You must be kidding.

I mean I get it. It's obviously a counter-reaction to all the PHP hate that has been with every PHP thread for 2 decades, and much of it has been unfair, especially for the last 5 or so years. But please let's not swing the pendulum all the way to the other side.

So given a web server, what language can 'come close' to the ease of deploying with PHP?

I'm a mostly PHP dev, but with apps in other languages, all you need more is a systemd unit file to start the app? (ruby, nodejs, go, etc)

Unless your only experience is 1999 style FTP with shared hosting and you've never used anything else, I don't know how you can claim that `node server.js` or running your Cargo-built server.exe is somehow harder or more complicated.

For example, PHP is complicated enough that people use WAMP/MAMP.exe just for local development.

"Given a web server" seems a pretty big caveat. I'm not a big node cheerleader (even though I work in it day to day), but it doesn't need to be given a web server to achieve the rest of this claim.

In the past I sort-of agreed and even chose PHP in a few instances when the project was tiny enough that ease of deployment was a major factor.

Nowadays with something like Heroku or App Engine, language has almost no impact on ease of deployment, and even custom deployments are pretty easy once you've practiced the docker/systemd script + apache/nginx proxy dance once or twice.

If we're giving PHP credit here, I think we can say with some confidence that the ease of spinning up a shared server with PHP and MySQL inspired the kinds of super simple infrastructure products like Heroku that are now commonplace. The notion that PHP is easier to deploy used to be true, it's not something that should be dismissed, it's even a pretty big deal. It's a walk up experience that inspired an improved DX for every other mainstream environment. But they've caught up and that's worth acknowledging too.

All of that can easily be done in Node by setting up the appropriate scripts in the "scripts" section of the package.json file.

You would also need a properly configured Apache server wouldn't you? I can see the ease of deployment argument in the context of old-school shared hosting providers, but nowadays how is starting a PHP application any harder than Rails or Django for example.

And for modern development environments, deployment complexity usually comes from managing virtualized hardware and CI/CD pipelines, which is independent of whatever language your app is written in.

> PHP's value proposition has always been one thing - ease of deployment.

I think that advantage may have been real at one time, when FTP deploys were a thing. The myth loves on. Folks that chant this praise are often not be the same folks that have to maintain the webserver side of things, though.

Easy to deploy looks like this: ./foobar --port=80 > Listening on port 80, ready for traffic

That could be Go, could be Rust. But not PHP.

PHP webserver / application separation does bring some advantages - for example if you bring your application to a corrupted state or crash it, it will go and die. Recovery is, well "implied". But deployment wise, no.

It actually seems to be a LOT harder to run PHP that at first blush. Take this example: https://github.com/laravel/valet/issues/290

Turns out if you php-fpm app one Tuesday at 15:43 starts to write more than 4k to stderr (maybe it writes some nice verbose logs after being hit by some recoverable error), you will find yourself wondering what does "upstream sent too big header while reading response header from upstream" imply while your endpoint responds with 502. This is just one possible footgun .. ekhm .. tuning option.

The value proposition is how well the language suits stateless Web Development & HTTP. Every request is an new sandbox, it's easy to pick up for beginners and fast to get started, decent performance, no need to figure out how to compile anything.

From my experience, a huge % of PHP companies started out with a Wordpress site, added a few features then a few years later they are now hooked and are doing things more seriously with Symfony or Laravel.

* Lots of cheap developers available

* Strong community

* Mature frameworks and libraries

* Simple hosting model

Fair, though I'd say 1-3 are more or less matched by Java/.NET and probably NodeJS.

Not sure if you meant this, but now that I think about it, the "one process per request" model is actually legit differentiator that obviates a lot of the concurrency trouble new developers can get themselves into with other languages. It makes good performance harder in some cases (though there are workarounds), but overall it's maybe the one thing in PHP that I'd like to see other languages make some note of.

I'd agree that there are other languages with equally strong communities and mature libraries. I would say it's easier to hire an OK PHP developer for £40K than for any other language, at least that's my experience hiring in London.

The hosting model - what you said, plus not needing to think about memory leaks. There are so many Java and .NET boxes out there that need to be rebooted every 2 hours because of some insidious bug that nobody on the team can solve. It's also pretty easy to put PHP in a container, and scale horizontally.

Good point about the memory leaks. Not aiming to contradict it, but I'll mention that https://www.eclipse.org/mat/ is a great help in debugging Java memory leaks. .NET probably has something similar.

I can say with confidence if you're hiring a developer for £40K they're not okay. I know PHP communities can be insular and can fail to sell themselves, and I know that local economies can vary wildly, but London is not cheap and 51kUSD is less than half what an "okay" dev should be paid. If you're hiring at those rates you are hiring people who are either unhireable bad at their job or (like I was for the first half of my career) completely unaware of what's available.

You don't choose PHP. PHP chooses you.

May be easier to audit a project in a sense due to most common libraries being standard rather than imported.

Has a decent track record for major version updates being easy to migrate to (even if many projects don't bother).

Works for quick and dirty bash-style scripting (not specially better than Phyton, but it does work).

Reply on news.ycombinator.com