Hacker News new | ask | show | jobs
by combatentropy 2038 days ago
I got spoiled by PHP as my first language. It was so easy to get going. I was surprised to learn that other languages didn't work the same way, when integrating into a web server. Also it has always been rock solid. A bug in my code brought down only that request for that user, totally did not affect or even slow down responses to other users.

People have attacked its syntax forever. I avoided the worst of it by learning PHP around version 4, when it was moving away from magic quotes and register globals --- and I also had the sense to see that those were unwanted anyway. But I think the main reason that PHP hasn't bothered me is that I try to use it as little as possible. Let me explain.

I consider PHP a glue language, between my database and the user's browser. When you use a lot of glue, things get messy. I try to push things out of the middle layer to the edges, if they will fit. So I try to do a lot of data preparation in the database, through fancy queries, so that the data is mostly ready for the HTML template by the time it is received by PHP. It helps that my database is Postgres. For authentication, I try to lean on Apache, so that PHP would just have to consult the CGI variable REMOTE_USER. So PHP acts sort of like an extension language to Apache (even when I'm using PHP-FPM instead of mod_php). It takes the data from the database and wraps it in HTML. It takes the form submission from the user and hands it to the database (and most server-side data validation is in the database).

The people attacking its syntax sound like they are writing an awful lot of PHP per app. And maybe for some things you have to, but not for CRUD apps, I think. I try to keep the middle layer as thin as possible, and I would do that whether it was PHP, Python, or Perl.

4 comments

> I was surprised to learn that other languages didn't work the same way, when integrating into a web server

Oh boy... I'm still not sure how you deploy a non-PHP webserver to be honest... every language seems to be doing something different, with php you just needed to drag & drop your files in the "public" folder.

It's pretty simple really. With php, your php sites consist of some php files that will be run by a webserver (apache, php-fpm, etc). When the webserver receive a http request, it will executes a php file that matched the request url, pass it the request body as input and send back the output as request response. On other languages, your app is typically deployed as the webserver itself, handling request directly (or indirectly with a reverse proxy in front of it) without executing any external process or terminating after each request.

The php model is simpler and easy to reason with, but many use cases in modern web development is not possible in this setup and requires you to write your app as a long-running webserver process (e.g. websocket model).

> I'm still not sure how you deploy a non-PHP webserver to be honest... every language seems to be doing something different

Coming from PHP and having used a bunch of different languages I can understand what you are saying.

Unlike PHP, the other languages run in a process that listens on a port (80, 443 or another). The single process continuously run and handles multiple requests.

Back then, I still had to use NGINX or Apache with PHP, and in retrospect I find that more difficult to understand than a script that listens on a port.

Caddy largely solves that problem. A config for a PHP app is usually about 4 lines long, see the example on this page: https://caddyserver.com/docs/caddyfile
I've never thought about it this way before, but it makes sense! I think I've been pushing things from the middle to the edges subconsciously but didn't have a solid understanding as to why. I got something out of this, thank you!
REMOTE_USER as in HTTP Basic auth? the ugly login prompt you can not logout of again?
That is one way, and I agree it's ugly, but Apache came out with form-based authentication in version 2.4, https://httpd.apache.org/docs/2.4/mod/mod_auth_form.html
Oh thanks! That's nice.
In my app, I use basic auth in place of captcha.

Every useragent going back to IE3 and NN1 support it.

I then set a cookie, and users never see the prompt again.

Cookies are sent on the first request, before auth happens.

In my extensive testing, even the most "non-techy" people are able to complete this task, while most bots fail at it.

If any bots start getting through, I can change the password.

For visitors I haven't met yet, I can give out guest credentials on the 401 page.

This Firefox extension adds a logout button:

https://addons.mozilla.org/en-US/firefox/addon/http-auth-enh...

you are doing it right. if you want to use fancy jargon for what you're doing say "I use apache as the controller, the database as the model and php for the view". that's how it's supposed to work since the first version of php/fi. php is primarily a templating engine.

but I disagree concerning register globals. I think it was the single thing that made php the most accessible language. we should bring them back but as a special variable with it's own prefix instead of $