Hacker News Reader

Comment by mikece | Hacker News Reader

While everyone else (well, me) have their attention on the hippest, newest languages PHP has been steadily improving, getting faster, and still runs a lot of the largest web properties. It wouldn't surprise me if before long PHP can be compiled to native binary* complete with a memory efficient, non-blocking web server and performance approaching what Go and dotNetCore can achieve... and the option to emit a "normal" PHP web app that can run anywhere if you don't need Facebook-level performance from it.

*I realize HipHop PHP did this already but it doesn't have it's own baked-in web server afaik. I'm thinking along the lines of compiling down to something small and fast to be deployed to K8S clusters without needing containers for Apache or nginx as part of the setup.

View on HN

PHP doesn't really want to do the web server part. PHP provides a request based (stateless or "Serverless before there was serverless") container for script execution and leaves the server part to some other program. Doing proper HTTP serving involves many things others have already done and where others will inovate. Dealing with security (SSL/TLS certificates and ciphers), virtual hosts, access permissions, HTTP protocol versions and so on is lots of work PHP developer leave to experts at Apache, nginx or whatever comes next.

Sure - one could do what many folks in other environments are doing: node.js or go developers often implement a simple API endpoint and use a reverse proxy (nginx or something) in front of it for interacting with the outside world, but fpm is the more specialized protocol for that.

Then again PHP is driven by people contributing. If some folks contribute according infrastructure and push for it I could be proven wrong. :)

Actual webserver may not be useful but it would open the door to out of the box support for servicing websockets which currently requires using things like Swoole to achieve in PHP.

Websockets are nice, but don't really fit into PHP's architecture around short lived requests.

Sure, for most parts PHP can handle that, but for long running things some I/O event based context switching typically is more efficient and in a few error cases PHP deferrs cleanup to "request shutdown" which might be a while out with websockets.

In the end PHP is focussed on one role (serving "normal" HTTP requests in isolated contexts quickly) and other technologies do other things better. And I think focus is a good thing.

Then again: PHP is open and does whatever the contributors want it to do and I myself am not actively contributing much anymore :)

"it doesn't have it's own baked-in web server afaik"

It does, actually: hhvm -m server -p 8080

Uses proxygen.

Proxygen is pretty cool, actually. Even does http/2 & https, and is suitable for production use. I'm somewhat surprised nobody's done the work to link it with PHP, Perl, etc, to provide what node.js does for js.

Edit: Also, on compiling PHP, there's a pretty good start here: https://github.com/ircmaxell/php-compiler/blob/master/README.... The FFI functionality in PHP 7.4, plus the internal use of an AST in php7.x, are what made it possible. Missing lots of functionality, but a neat proof of concept.

php also has one: php -S localhost:8000 -t foo https://www.php.net/manual/de/features.commandline.webserver...

since 5.x (not production ready tough)

If you use Swoole, you can implement a performant server in a async Node fashion with your code, PHP and Swoole extension:

https://www.swoole.co.uk/docs/modules/swoole-http-server-doc

Unrelated to the topic but why the fuck do those people need to set 600 different cookies?

Someone whose name I forgot (paul something ps: paul biggar) made a thesis on the uncompilability of PHP, but that was few years ago, maybe with the addition of typed annotations it's gonna be possible to get a bit of it.

That doesn't scale. You want a high performance web server in front of a farm of php app servers.

A lot of those large web properties are going to be using old versions of PHP. Newer versions have breaking changes that make upgrading a large codebase difficult.

To these companies, PHP 7 is a hip new language that they're not using.

> A lot of those large web properties are going to be using old versions of PHP.

Is that true? PHP 5.6 and 7.0 were EOL'd in 2018, and acording to data at https://blog.packagist.com/php-versions-stats-2019-1-edition... the use of PHP 7 and later is ~90%. Web properties like DreamHost have supported PHP 7+ for years, and have deprecated versions before 7.1.

> Newer versions have breaking changes that make upgrading a large codebase difficult.

The documentation on this is pretty good[1], and there's some nice tooling that can help[2]. I wouldn't say that I've migrated "large" codebases, but FWIW in my limited experience this hasn't been particularly onerous.

[1] See https://www.php.net/manual/en/migration70.php and related appendices [2] https://auth0.com/blog/migrating-a-php5-app-to-7-part-three/

I think a lot of places stick with whatever PHP version comes with the Linux distribution they use, only use Linux distributions with long term support, and only update to a later release of that distribution when the one they are on is about to go out of long term support.

For Red Hat, that means there are places still on RHEL 5, 6, and 7, which is going to put them PHP at 5.4.

It looks like Ubuntu 16 is the oldest Ubuntu still under support. That had PHP 7.0. Ubuntu end-of-life (when they stop getting security updates) are later than end of support. Ubuntu 14 EOL is April 2022. That has PHP 5.5.9.

Debian 8 has long term support until June 2020, and PHP 5.6. Debian 9 has LTS to June 2022, and PHP 7.0.

For those who are on the latest LTS or equivalent:

RHEL 8 has PHP 7.2.

Ubuntu 18 has PHP 7.2.24

Debian 10 has PHP 7.3.

Stats from packagist.com are biased towards newer versions. They are coming from composer users, and if you are using composer, you are a lot more likely to be using more or less up to date practices and relatively new version of php. There are millions of legacy projects and wordpress sites that have nothing to do with composer, and they are running on old versions of php much more often.

Earlier this year I spoke to a team on PHP 5.1 - EOL was 2006! They have a massive PHP 4 style codebase, all in-house (no framework), a team of devs that knows it intimately and doesn’t want to leave because they have no job prospects. Sadly, judging by emails I get, there are a lot such teams operating in small towns.

> Sadly, judging by emails I get, there are a lot such teams operating in small towns.

I can believe that, even if I don't understand the mindset. Unless they're ready to retire, you'd think they'd want to keep their toolboxes current.

They must struggle to hire new devs, meaning no one comes in and tries to push the team onto newer versions

we upgraded a 100k lines PHP 5 codebase to PHP 7.1 in a month. if your php 5 code wasn't using any deprecated extensions (like the old mysql extension) upgrading is really easy. there are static analysis tools that spot the potential problematic code so you don't need to do it by hand. from that point on if you got any automation testing or unit tests you can have a good level of confidence that your upgrade was a success.

Agreed, we wanted to upgrade from 5.9 to 7.1 and once we got it working we fired up docker with 7.3 and it just worked. Glorious

Sorry, what is 5.9? You meant PHP 5.6?

Yes! Unsure where I got 5.9 from

Migrated a few million lines of code spread over a few apps in a couple of days to php 7. Most of the time was spent setting up docker and migrating unit tests. There were literally zero code issues. Those are properly written and engineered apps written on top of proper frameworks as any professional would write them. There is another app that depends on a php 5 library that's still running on php 5 now, three years later. So the upgrade situation is extremely easy and simple if your code isn't total shit. With shit code, the migration is the least of one's worries.

What percentage of old PHP code do you think is well-written with good unit test coverage?

Go after PHP has been therapy to me.

i dreaded the upgrade to php 7.2 in some 10 year+ old apps, i thought too many things would break. Turns out it was easier than expected, and it's faster too!

In my experience I only had real problems with projects built on outdated frameworks, like cake 1.3, because the framework was not compatible with php7, and upgrading to latest version of framework meant basically a full rewrite.

A few other old sites, even relatively large ones, that were built from scratch or on homegrown CMS years ago, only took some minor fixes and mostly were up and running in couple of hours, some even worked right away without any issues.

Reply on news.ycombinator.com