LWN: Comments on "Roose: PHP in 2020"

vs Python?

jospoortvliet — Mon, 23 Mar 2020 11:01:43 +0000

Fair enough but 2 and 3 don't apply to me (my server is a private one that just runs Nextcloud) and indeed, I use the prefork model.

How big a deal is 1? I mean, measurable? I read a bit about it and it forks the entire apache process, so I suppose it eats more memory but is otherwise not slower (maybe even faster). My server currently has plenty of memory but I get it makes a diff on a large machine or low-memory system.

So for a single machine handling everything and with enough memory, mod_PHP is fine, for scaling over multiple machines you'd want something else. Got it ;-)

vs Python?

ssmith32 — Sat, 01 Feb 2020 18:04:28 +0000

Interesting, in other languages, I see a strong pull away from frameworks. Simple libraries to open a socket, and hook up handlers to resources is becoming more common.

Of course those libraries are slowly gaining more features, and....

Label framework
jmp librarymicroservice
Label librarymicroservice
add librarymicroservice, features
Goto framework

(It been over a decade since I worked with assembly, I get that it's probably terribly wrong)

vs Python?

ssmith32 — Sat, 01 Feb 2020 17:57:56 +0000

When I used Django, I found it fairly annoying, so, coin flip for me.

TBH, what I see out there today is:

- people that just use a CMS that are written in php/python/whatever. Doesn't really matter, because most of the work isn't in that language, it's in ops & content generation.

- any new api work, separate from content is in Nodejs, (because you can have the same engineers work on apis as the website). You'll sometimes see python or Ruby (e.g. gitlab). Java in enterprises, a smattering of Go in middle sized companies (I'm talking apis, not other domains). Those are rarely using something as heavy as Django. Thankfully, for me, for now, all languages are slowly converging to lighter weight libraries for apis, vs large, opinionated frameworks..

That said, it's amazing how much we revisit the same debates, just going to one side or another for a while - I just saw someone praising the fact you don't have strong typing in Go, and here's this blog, praising the fact that "good" php can declare types. Big frameworks will probably come back some day. And, in the last few years, I've run into more functional programming fans (as in, it's a universal good, not just a great guideline for some situations). I suppose we'll have some APL-like language re-invented, and then that will get tempered down.

Roose: PHP in 2020

ssmith32 — Sat, 01 Feb 2020 17:38:42 +0000

And some that are still relevant aren't even "sad" - sort in place, for example.

Functional programming is a particular style with benefits in some situations, but it's not a universal good.

The old "php is a fractal of bad design" was far more damning.

Nothing here seemed particularly egregious compared to any other options.

vs Python?

claude.bing — Sat, 25 Jan 2020 18:02:42 +0000

1. mod_php is not thread safe, so you have to use the mpm prefork model for apache, which is the slowest option.

2. Every apache process will have the extra weight of including a PHP interpreter, even if you are serving static content.

3. You are limited to using the same machine for request handling and PHP execution. This does not scale well.

vs Python?

jospoortvliet — Sat, 25 Jan 2020 14:53:10 +0000

what's the difference, for a maintenance perspective? On my private server I use mod_php and I can't figure out why on earth I'd go through the extra trouble setting up php-fpm... ppl claim it is faster but I'm not really convinced it makes much difference on a php app. Haven't seen any real benchmarks, for sure, and I can imagine that the extra context switches that come with php-fpm do little for its performance...

Roose: PHP in 2020

jkingweb — Fri, 24 Jan 2020 16:16:11 +0000

I'm not sure the example for arrow functions is particularly flattering, but then I'm skeptical of arrow functions in general, especially since equal-arrows have a very, very long history is meaning something else in PHP. Otherwise, though, it makes a good, concise case.

One of the things Roose did not talk about, though, is the PSR series. Published by the PHP Framework Interoperability Group (PHP-FIG), they serve as standards for how PHP should be used. I'm not too keen on all of them, and only seem to have gained wide acceptance, but PSR-4 is part of what makes Composer a practical system, and PSR-1 and PSR-2 have proved to be very influential and effective style guides.

vs Python?

claude.bing — Thu, 23 Jan 2020 23:51:28 +0000

I suppose with the rewrite magic it does not have to be the way I have it, but it's just something I prefer. Since that directory is the web root, it should not be possible to escape out of it easily.

vs Python?

pabs — Thu, 23 Jan 2020 23:34:01 +0000

Why is the single index.php file is stored within the publicly accessible web-root directory rather than alongside the rest of the code?

vs Python?

Lennie — Thu, 23 Jan 2020 07:58:32 +0000

It's obviously still very common in dedicated environments with just one website/app.

For example inside Docker containers.

vs Python?

claude.bing — Wed, 22 Jan 2020 20:30:27 +0000

> Back then, almost everyone used the Apache PHP module, which was a spectacularly terrible idea for *so* many reasons.

If I still had to use apache with mod_php on a daily basis, I would probably switch careers.

vs Python?

yodermk — Wed, 22 Jan 2020 19:43:30 +0000

> As with anything, if someone is given the capability to shoot themselves in the foot with a tool, they will eventually do it

Yes you're right of course. From my historical perspective though it seems that PHP has given folks a lot more opportunities to do that than other modern languages.

Another thing that's always bothered me about PHP is the fact that settings in its config file fundamentally change how a lot of command are executed. If it weren't possible to over-ride them with per-directory overrides, that would be a big problem for web servers with multiple sites. Fortunately, php-fpm allows such overrides, but it still strikes me as ugly. Python has no such configuration issues.

BTW I was one of the first proponents of php-fpm at my web host. I agree with you that it's a huge improvement. Back then, almost everyone used the Apache PHP module, which was a spectacularly terrible idea for *so* many reasons. While I'm still not thrilled with the language, php-fpm makes its administration tolerable.

vs Python?

ggiunta — Wed, 22 Jan 2020 10:07:53 +0000

Although one can still develop php apps 'old school' style, starting development from scratch, I think most developers today take advantage of frameworks. Two of the most commonly used are Laravel and Symfony. For both of them, a single index.php file is stored within the publicly accessible web-root directory. The routing of requests (url -> php code) is not done any more by the web server, but by application code. Css/js and other assets are copied or symlinked into the web-root directory by using deployment commands from the framework.

This, together with usage of php-fpm to separate the os accounts used to run the webserver process and the php engine process, allows for a much more secure default setup than it used to be 10 years ago.

On a side note: in php land the 'composer' package manager is now ubiquitous, on the same level as npm for nodejs. This means less reinventing-the-wheel and more sharing of packages/libraries within projects. There are tools that will scan your project's dependencies for known vulnerabilities - recently even github started scanning your composer.json file and sending you warning emails in case it finds insecure stuff.

ps: the config that routes all http requests to a single frontend php controller is done withing apache/nginx. php-fpm does not do routing, it only manages php processes (in a similar way to what the apache mpm modules do)

vs Python?

claude.bing — Wed, 22 Jan 2020 04:31:21 +0000

https://www.nginx.com/resources/wiki/start/topics/recipes...

Every request is rewritten to be sent to index.php. Personally, I have the following structure:

/var/www/public/index.php
/var/www/public/assets/css/sample.css
/var/www/public/assets/js/sample.js
/var/www/src/ProjectName/bootstrap.php
/var/www/src/ProjectName/Controllers/SomeController.php

index.php handles every request, and no other PHP files are accessible by the public.

vs Python?

pabs — Wed, 22 Jan 2020 04:13:34 +0000

What does the web server config side of this look like? I can only find PHP-FPM webserver configs that look like the old style of "bunch of PHP files in a directory" setup.

vs Python?

claude.bing — Wed, 22 Jan 2020 03:53:32 +0000

I think there is some confusion here. This is basically what PHP-FPM does. nginx (or Apache) passes all requests that match a path, or regex, and passes them to a single PHP script that you specify. Then, that script routes the request to different controllers within your application. This is what I meant by the "framework" portion earlier.

See https://github.com/nikic/FastRoute for a routing example. Of course, the example in the README is quite basic; more sophisticated applications would have a few service layers helping to fulfill requests.

vs Python?

pabs — Wed, 22 Jan 2020 03:01:25 +0000

At least with Apache, it looks like you can alias /static to the directory and then alias / to the WSGI script and everything under /static will be served from the directory instead of from the WSGI script, for example:

https://www.digitalocean.com/community/tutorials/how-to-s...

vs Python?

claude.bing — Wed, 22 Jan 2020 02:57:55 +0000

It is the traditional model, yes. Though, handling static assets would be better served by a much lighter weight process (web server). With the WSGI approach, is the developer forced to use a separate domain or CDN for those? Seems wasteful for the app server to handle those requests.

vs Python?

pabs — Wed, 22 Jan 2020 02:39:11 +0000

That still sounds more like traditional PHP where the web server is responsible for routing individual URLs to corresponding PHP scripts than a modern setup like WSGI where all URLs on a domain or localtion are passed to the WSGI script and it is responsible for routing the URLs to code.

vs Python?

claude.bing — Wed, 22 Jan 2020 01:45:18 +0000

It does have a built-in web server, but it is not meant for production use. I usually use nginx with PHP FastCGI process manager. It passes requests via IP or Unix sockets to a long-running PHP instance. URL rewrites are necessary for things like clean URLs, but PHP is totally separate from the server.

vs Python?

pabs — Wed, 22 Jan 2020 01:09:12 +0000

> Best practice in this instance would be to have a single entry point for your application

Does PHP have WSGI or something like it yet, or do you still have to do Apache rewrites to get that to happen?

vs Python?

claude.bing — Tue, 21 Jan 2020 23:58:54 +0000

> Ok, so maybe it's time to stop mercilessly bashing it.

For developers who continue to perpetuate the poor coding practices encouraged by PHP 4/5, I think this is still an appropriate response. It could go hand-in-hand with mentoring and training to become a better programmer, however.

To be honest, I have ten years of experience with PHP, and almost none with Python. But, I have had to make minor modifications to existing software built using non-framework Python. I am quite comfortable with PHP's syntax, but I do not think I mind how Python approaches things like scopes using indentation and the like. Surely there are language features that Python has implemented which PHP does not have yet, but I am not sure about the other way around.

> I assume you normally still put .php files in the HTML content directory? That has always struck me as a terrible idea, and was the source of many security issues. It made a bit of sense when you intermingled PHP code with HTML, but now if you properly separate code and presentation, there's no reason to do that.

Best practice in this instance would be to have a single entry point for your application which is publicly accessible, and then your framework of choice would handle the requests using PHP files from a non-public directory. As far as handling user input, I believe both languages would handle things similarly (having at least one way of accepting that input, then directing it within the application).

As with anything, if someone is given the capability to shoot themselves in the foot with a tool, they will eventually do it. Maybe this is wrong, but I do not see it as a language-specific problem. Just think of all of the ways you can solve problems the wrong way with C! I personally look forward to the core developers merging in more language features that would bring it more in line with modern practices, such as generics and enums (the latter of which should have been implemented a long time ago).

vs Python?

yodermk — Tue, 21 Jan 2020 23:34:24 +0000

Ok, so maybe it's time to stop mercilessly bashing it.

But is there a good argument for using it instead of Python? Maybe you just like its style -- braces, and $ variable prefixes. Anything else? How do the frameworks like Laravel compare to Django?

I assume you normally still put .php files in the HTML content directory? That has always struck me as a terrible idea, and was the source of many security issues. It made a bit of sense when you intermingled PHP code with HTML, but now if you properly separate code and presentation, there's no reason to do that.

(I was a PHP programmer 20 years ago, and 7-12 years ago was a support admin for a web host and saw waaaaaaay too many compromises through PHP, so I am a bit biased and jaded against it....)

Roose: PHP in 2020

claude.bing — Tue, 21 Jan 2020 17:57:02 +0000

Many of those items are now out of date, but the remainder are legitimate concerns. Unfortunately, people sometimes become fixated on these shortcomings and ignore similar issues in other languages. Every tool has a purpose, and PHP is no exception. For web development / web accessible services, I would still consider it to be a leader in the field by taking into account its ease of use, widespread support, large user base, and long-term stability.

Roose: PHP in 2020

pj — Tue, 21 Jan 2020 17:38:25 +0000

Useful in arguments against this assertion: http://phpsadness.com/