Hacker News new | past | comments | ask | show | jobs | submit login

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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: