4 ms·
There’s not a lot of applications beyond a certain size that don’t need background processing, and that’s exactly where using PHP bites you in the buttocks. As
by mikl 3y ago
There’s not a lot of applications beyond a certain size that don’t need background processing, and that’s exactly where using PHP bites you in the buttocks. As soon as you get outside the request/response cycle, the runtime really starts to show its shortcomings.
- danaris 3y agoI think that's showing a bias toward a particular kind of application. Yes, there are often things besides pure request/response that an application needs—but in all the cases I have yet personally come across, those were easily served by simple cron jobs calling PHP scripts from the command line (either directly, or through a Symfony app's Command interface). To be clear, I do not at all dispute that many types of application do need some kind of persistent background processes, and those would be much less suitable for building (entirely) in PHP. Indeed, I am happy to also stipulate that it may not always be easy to tell whether that will be the case when initially designing the spec and choosing one's tools. But there are plenty of applications that work perfectly fine using nothing but request/response, and many others that only need to add simple triggered scripts to that.