5 ms·

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 th

by mikece 7y ago

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.

tyingq 7y ago
"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.md 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.
- merb 7y ago
  php also has one: php -S localhost:8000 -t foo https://www.php.net/manual/de/features.commandline.webserver.php https://www.php.net/manual/de/features.commandline.webserver... since 5.x (not production ready tough)
trm42 7y ago
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 https://www.swoole.co.uk/docs/modules/swoole-http-server-doc
- ofrzeta 7y ago
  Unrelated to the topic but why the fuck do those people need to set 600 different cookies?
johannes1234321 7y ago
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. :)
- kyriakos 7y ago
  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.
  - johannes1234321 7y ago
    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 :)
daveFNbuck 7y ago
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.
- CharlesW 7y ago
  > 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/ 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 https://www.php.net/manual/en/migration70.php and related appendices [2] https://auth0.com/blog/migrating-a-php5-app-to-7-part-three/ https://auth0.com/blog/migrating-a-php5-app-to-7-part-three/
  - blowski 7y ago
    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.
    - CharlesW 7y ago
      > 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.
      - 7y ago
agumonkey 7y ago
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.
tus88 7y ago
That doesn't scale. You want a high performance web server in front of a farm of php app servers.
thefounder 7y ago
Go after PHP has been therapy to me.
buboard 7y ago
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!
- mad182 7y ago
  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.
deleted 7y ago
[deleted]

by mikece 7y ago

tyingq 7y ago

"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.md 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.

merb 7y ago
php also has one: php -S localhost:8000 -t foo https://www.php.net/manual/de/features.commandline.webserver.php https://www.php.net/manual/de/features.commandline.webserver... since 5.x (not production ready tough)

trm42 7y ago

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 https://www.swoole.co.uk/docs/modules/swoole-http-server-doc

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

johannes1234321 7y ago

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. :)

kyriakos 7y ago
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.
- johannes1234321 7y ago
  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 :)

daveFNbuck 7y ago

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.

CharlesW 7y ago
> 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/ 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 https://www.php.net/manual/en/migration70.php and related appendices [2] https://auth0.com/blog/migrating-a-php5-app-to-7-part-three/ https://auth0.com/blog/migrating-a-php5-app-to-7-part-three/
- blowski 7y ago
  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.
  - CharlesW 7y ago
    > 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.
    - 7y ago

agumonkey 7y ago

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.

tus88 7y ago

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

thefounder 7y ago

Go after PHP has been therapy to me.

buboard 7y ago

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!

mad182 7y ago
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.

deleted 7y ago

[deleted]