[labrador]

It's late Friday night so this what I really think of PHP: It is the purest form of web programming. You don't need a framework. Spin up a server and just start writing. Experiment. Do crazy things with it, like an art project. Every page is it's own world. Have fun with it. PHP is freedom.

[creamyhorror]

There's nothing like being able to write backend code directly in HTML files, without even having to start a new server process. It's literally just a .php file executed and served to the user.

It starts as the ultimate anti-structure. Nothing, not even MVC. But then you can refactor parts out of it and start moving towards a structure. Very freeing if it's a small one-off page/project and you know what structure works for you.

(Of course, if you need a database and authentication and Scaling and so forth, that's when you start bringing in the heavy artillery (libraries and packages), or switch to a framework.)

[labrador]

I volunteered to help .netart artists in the early 2000's to get their code working. They were able to do some very creative things with PHP that I know they didn't have the coding skills to do otherwise. Like grabbing random images based on keyword searches from poems and creating montages with them. The industrial programmers would shudder in horror at the PHP code they wrote but it did the job. PHP is for the people. It'd be nice if the bureaucratic programmers would keep on making their proper factory factory singletons they learned at University without turning up their noses at PHP in their boxed world

Malvina Reynolds - Little Boxes https://youtu.be/VUoXtddNPAM?t=14

[xtracto]

I remember codeignter fondly from ages ago. It was my first MVC framework, and in php. It was pretty cool.

[throwaway92748]

I used PHP several years ago and are considering trying it again for my side hustles. You basically just push files to a folder and "forget about it"

It just keeps running and auto corrects any temporary load issues because of its stateless nature. I don't have to worry about memory leakage or processes that eventually become unresponsive and needs to be restarted. If the unlikely event that the PHP process crashes, it will just restart automatically and handle the next request as if nothing happened.

Its the ideal solution for side projects, and I am definitely going back now that I don't have time to maintain complicated infrastructure.

PHP was my generation's version of AWS stateless "lamda". Just place a file in the folder, and it will be executed on demand and clean up resources after the request has ended. A server could handle many different websites at the same time. That was basically how we could get cheap webhosting. They just put a bunch of Apache-instances behind a load balancer and used a shared network drive to read the files from

[kunley]

The "push files and forget" mindset is why PHP is a nightmare for operations on a serious production.

To be fair, it shows up as a nightmare from a certain scale. Toy projects might not reach this level..

[1oooqooq]

if you reach a certain scale and still do that, the language is the least of your worries.

[zarzavat]

This is nothing to do with PHP the language. You can have an HTTP server and templating engine in any scripting language. It’s just the way that PHP is distributed is particularly easy. Someone could throw together a “PHPython” from existing components and get the same effect.

[KronisLV]

> Someone could throw together a “PHPython” from existing components and get the same effect.

Python has been around for like 30 years, why isn't that quite the case?

I guess there was mod_python but nobody cared enough: https://modpython.org/

I guess there's now mod_wsgi which is similar to PHP-FPM in some ways: https://modwsgi.readthedocs.io/en/develop/

Yet, even with the actual deployment not being much different (just used Apache as an example here), there's still dependency management, which Python is often described to be pretty messy at, virtual environments or not. With PHP, most of the stuff you need for common use cases often is pre-installed and is just a matter of enabling some plugin in the config.

That said, I deploy most of my stuff in containers, so PHP, Python, Node, .NET, Java and others all become more alike when viewed from the outside.

[JimDabell]

> > Someone could throw together a “PHPython” from existing components and get the same effect.

> Python has been around for like 30 years, why isn't that quite the case?

> I guess there was mod_python but nobody cared enough: https://modpython.org/

Because it sucks! We tried it, it was bad, the Python community left it behind. Maybe if PHP left things that suck behind too then fewer people would say that PHP sucks.

[KronisLV]

The whole point of the parent comment was that it doesn't, at least when you want to be able to experiment and iterate quickly:

> It is the purest form of web programming. You don't need a framework. Spin up a server and just start writing. Experiment. Do crazy things with it, like an art project. Every page is it's own world. Have fun with it.

Why would that be a bad thing? Even when it comes to something like REPLs, everyone always touts being able to iterate more quickly as a good thing, don't they?

Edit: aside from the implications of an in process language runtime, that was discussed in another comment.

[JimDabell]

Why are you talking as if embedding server-side logic in HTML is necessary to experiment and iterate quickly? I can get up and running with a Python project in seconds and can iterate quickly with that.

“This is good because it enables you to iterate quickly” isn’t a good argument when you can iterate quickly regardless.

[KronisLV]

> Why are you talking as if embedding server-side logic in HTML is necessary to experiment and iterate quickly?

Necessary? Not quite.

But having those things be closer together leading to faster iteration? I'd argue that that's definitely true, same as how someone could skip out on writing a bunch of enterprise programming patterns, MVC or even tests, as well as use a language with a dynamic type system, or even write serverless functions. Not that any of that is very maintainable long term, but at the same time nobody would expect that from something that's very much like a REPL.

It's the same as how I like to have a clearly separated front end (typically a SPA) and a back end API (something RESTful) in most cases so that those technologies wouldn't be coupled and the API could be re-used as necessary, except that people who go for the various SSR and templating approaches typically code around me in circles, because they don't have to write as much API client code as I do.

[mgaunard]

Because this method of deployment is not only unsafe but also doesn't scale.

In the age of cloud, you just run your web application as its own server, and just have a proxy that fronts it.

[KronisLV]

> Because this method of deployment is not only unsafe but also doesn't scale.

How is a mainstream web server acting as a reverse proxy for an app server unsafe?

You get the benefits of one common approach to configuration, request logging (and possibly log shipping), rate limiting, compression, path rewriting and so on, while letting the app server handle the actual app and language runtime stuff (whether it's some Python app server, PHP, Java with Tomcat or whatever). You can even serve any static assets right there, alongside your API.

You can either include everything in a container, have separate containers for each process with overlay networking, or just have them run on the OS directly with only the web server binding to whatever ports you want to expose.

As for scaling, none of that prevents you from running anywhere between 1 or a million instances in parallel, with some load balancing (whether it's multiple servers or containers across a cluster). If it's really that bad, throw in HAProxy or something into the mix, alongside whatever cache solution tickles your fancy.

That's besides the point that I could provide a service to everyone in my country on a single rack (redundancy aside), not everyone even needs some mythical sky high scaling target.

> In the age of cloud, you just run your web application as its own server, a just have a proxy that fronts it.

Whether you use your own ingress (there's a lot of good ACME solutions out there) or something that your cloud provider gives you, using a server per app would in many cases be wasteful and there's a bunch of ways to increase the density, especially with the dynamic scheduling most container orchestrators could also give you.

[mgaunard]

mod_php runs in the same process as your http server, with the same rights. It's comically bad, especially in mutualized environments, and the reason why PHP is such a common target for hacks.

[KronisLV]

> mod_php runs in the same process as your http server, with the same rights.

mod_php was great for local iteration or when you wanted a very simple setup (and the same could be said about mod_python etc.), but most people have moved over to PHP-FPM nowadays: https://cwiki.apache.org/confluence/display/HTTPD/PHP-FPM There's probably more recent information somewhere, but this pretty much covers it.

Here's a very simple setup of two separate processes, with Supervisord (this is what runs in my self-contained dev container, but no reason why someone couldn't do something similar with systemd, or on a container cluster, with different users/permissions for each process):

  [supervisord]
  nodaemon=true
  [program:php-fpm]
  command=/usr/sbin/php-fpm -c /etc/php/fpm/php-fpm.conf --nodaemonize
  [program:apache2]
  command=/usr/sbin/apache2ctl -DFOREGROUND

And approx. how the Apache configuration might look:

  LoadModule proxy_fcgi_module "/usr/lib/apache2/modules/mod_proxy_fcgi.so"
  <FilesMatch \.(php|phar)$>
    SetHandler "proxy:fcgi://127.0.0.1:9000"
  </FilesMatch>

Conceptually, that's not very different from WSGI for Python: https://en.wikipedia.org/wiki/Web_Server_Gateway_Interface#S...

But yeah, I agree about the shortcomings of mod_php.

[cess11]

Some aren't going to fall into the clown age trap at all.

[skywhopper]

Oh but if your web server had PHP installed, it really was “easy” in a way that modern web programming is not. Yes, you could replicate it with Python, but actually you can’t, because no one has “thrown together” a PHPython. Nothing today can beat the feeling of being able to just drop a .php file in a directory and have an interactive, dynamic web page up and running

[xigoi]

This is not even a hypothetical. CGI is right there.

[nurettin]

Apache knows how to serve php, it is harder with python.

[creshal]

mod_python was supposed to be that, it's a real shame it never got enough traction.

[nurettin]

Perhaps they should have gone for something more specific, like mod_jinja

[lloeki]

> in any scripting language

Scripting? Ha! We used to do CGI in C when Perl wasn't fast enough. <old-man-yells-at-cloud />

[mrtksn]

Exactly, I used to be much more productive when using PHP because I could simply write some code, put it in a folder and refresh the browser and it would work.

How do you go into production? You put the file in a folder on the Web server. It works everywhere the same.

The code writing part itself is very straightforward and there's nothing counterintuitive as long as you don't try to do something that it's not designed for.

>there's nothing counterintuitive as long as you don't try to do something that it's not designed for.

Maybe that's the key. Instead of trying to write programs with tools that are not made for this but are somehow bullied into doing it, just use the right tools.

For generating HTML based on a request and data in the database, PHP it is. Don't try to make a language made for DOM manipulation process data and generate HTML.

For Web UI, DOM + JS it is. Learn how browser works and write the JS that will modify the DOM as needed which will result in interactive UI. Don't stack abstraction.

[arp242]

> How do you go into production? You put the file in a folder on the Web server. It works everywhere the same.

Well, not really because you have this massive php.ini file with tons of settings and whatnot, and scripts not working due to that was always a common point of failure back when I was using PHP. Also: not having some extension, which are almost always in C and require server installation (which is quite different from many other languages, where the user can usually specify most or all of their dependencies).

Maybe all of this changed? I don't know. But PHP in general has been the most fickle and unreliable environments I've dealt with. Give me any random servers, and I find it very hard to tell if my PHP script will run.

[mrtksn]

Right but all that was handled with stuff like XAMPP or some server control panel because it was all straightforward and if you don't use control panel all you had to do was to edit some .ini file.

That's of course for singe server applications. However, because everything is straightforward and built for purpose and not trying to pretend being something else, more complex systems were still easy to setup and manage.

The joy of coding PHP usually died off with frameworks like Symfony where they built complex abstractions for the pleasure of the "Enterprise" projects with many moving parts.

[arp242]

That's all fine if you're the one in control of the servers, but in reality that's not always the case. And actually even if you're in control, it's just a huge bunch of moving parts that can (and do) fail.

I also have to say that php.ini is probably one reason PHP became so successful in the first place, by having things like safe_mode and such so it could be easily used on shared hosts with ease. All the $2/month shared hosts were offering PHP, not Perl or Python, because of this (and mod_php).

But other settings like that automatic $_GET/$_POST importing ... yeah, that was a lot more misguided. Even error_reporting really should never have been a system setting: always let the code handle these sort of things. And even safe_mode is mostly outdated and useless now, because no one is doing shared hosting any more.

[mrtksn]

I think shared hosting is now called “cloud” :)

Unfortunately all cloud providers I know bank on JS. I like JS but when it is in the browser, on the server it’s a disaster.

[arp242]

Current cloud providers have very different execution environments; the typical shared webhost had one Apache process with mod_php and every account was just a different system account. What you needed as a hosting provider was a way of preventing file_get_contents("/home/someone-else/secret.txt"), which is what open_basedir gave you. And system(nefarious-stuff), which is what safe_mode gave you.

Today that sort of thing is very rare; you will run in a virtual machine or container, and have an execution environment all to yourself.

[jiggawatts]

Many other frameworks copied this approach from PHP.

For example, both ASP and ASP.NET can be developed using Notepad.exe directly on an IIS web server, and you can similarly test changes by simply refreshing your browser.

Personally I'm allergic to this style of development, the "banging on it with a rock until it starts moving" approach tends to result in poor outcomes over the long term.

I much prefer that a compiler go over the entire codebase and check everything when I hit the compile button.

Sadly, this bad habit from PHP still lingers in ASP.NET Core to this day, and causes me endless grief.

Just over the last couple of months, I have encountered the following:

- DEV, UAT, and PRD are out-of-sync with each other and the source code. When I asked the developers why that is, they said they make changes to individual files instead of "building the whole thing", because "that's faster". Okay, they saved the two minutes the pipeline takes to run, great. Now I have to spend a week disentangling the mess.

- I refactor something, hit build, it comes back with all green ticks, I deploy... and the site is broken with HTTP/500 a day later because these scripting-style frameworks don't build the page code until runtime.

- A security vulnerability code scanner was enabled, and it broke the build. Why? Because it actually builds the code, all of it! Except that these frameworks have two sets of page template files that contribute to the "final product": 1) the list of page templates registered with the build system or VS project file, and 2) the list of files physically in the Git repo. Some build steps consider only the former, the web server considers the latter. You can remove a page from a build system, and it'll remain working. It's like removing C code from Linux and still have it turn up in the kernel! That's nuts, and a security nightmare. Cough-xv-cough.

PS: It's possible for ASP.NET Core to be configured to both compile every page on publish and support hot-reload and automatically include every file in the build if it's physically in the folder structure. This really ought to be the default, but isn't... to pander to ex-PHP devs or something.

[mrtksn]

>I'm allergic to this style of development, the "banging on it with a rock until it starts moving" approach tends to result in poor outcomes over the long term.

I was sold on this too, that's why I left PHP for sexier stuff and never regained my productivity. As it turns out, most of the time I don't have a complete idea on what I'm doing but instead I have a direction and banging on it with a rock until it starts moving *in the right direction* is very productive because the design happens at the same time with the development.

My PHP code was complete "garbage" but it worked as expected and made me money and/or satisfaction of building things. Later I improved my coding skills and become much more aware of patterns and structures and found myself optimising the code instead of the product, destroying my productivity because as it turns out computers don't actually care or reward you for beautiful code. All that matter is, what that code is doing regarding the expectations of the humans who benefit from it.

[throwaway92748]

I worked with PHP XX years ago, and we didn't have that problem. I think that once you have access to a machine, it will always be possible to make direct changes. It's just that PHP made it easier, and in some cases it was also acceptable that the prod environment was temporarily broken until the developer undid their changes. You would just mess up a single page (or route).

Example 1:

I developed internal tools on a single server. The way I would do it was to have a personal folder on the server that I could use for development. Then I would commit the files to CVS which was the used for "deployment" to the main "production" folder. This worked well for me.

Example 2:

We also had a customer facing website where this practice was not allowed. We had proper build pipelines that created RPM packages which was installed by hand on the production machines.

My point is that there were many ways of avoiding editing the files directly in "production", even back when PHP ruled the world.

[jiggawatts]

“The problem didn’t happen to me” doesn’t mean the problem doesn’t occur. It’s like speeding.

PS: I saw a developer take out an 80K user enterprise because they tried to change the look and feel of a login page live on the prod server. They didn’t know any better because they were used to editing pages in live systems. That bad habit resulted in about a million dollars of lost work.

Oops.

[1oooqooq]

that shop could be using the latest academic language with full guarantee syntactic checks and perfect compiler and testing... you would still have the same problems.

[jiggawatts]

I've found that you can steer any group of people towards the pit of success instead of the pit of failure.

[wouldbecouldbe]

The issue is that’s what it was.

However due to all the shit from developers PHP slowly became a half assed copy of Java. Instead of understanding what it was.

Node is the new php

[guidedlight]

I agree. However those ‘crazy things’ you can do with PHP very easily cause security defects.

Mixing server side and front end code is bad news. I think following many PHP-MySql tutorials will result in SQL injection vulnerabilities. Not good.

[0xDEADFED5]

i have nightmares from PHP, too, so i get where you're coming from. but i think you'd have to go back at least a decade to find tutorials that bad

[JimDabell]

Not an SQL injection, but I opened Google in a private browsing window, searched for “php mysql tutorial”, and it brought me to the W3Schools tutorial, which has multiple other vulnerabilities relating to how PHP just dumps its output into HTML unescaped without a second thought. At a glance, I see obvious XSS and open redirect vulnerabilities.

https://www.w3schools.com/php/php_mysql_select.asp

[cess11]

W3Schools being consistently shit for decades doesn't really reflect badly on PHP specifically.

[JimDabell]

It’s the top hit for “PHP MySQL tutorial”. This is what PHP newbies are learning from.

The same tutorial with Django wouldn’t have the same problem because Django auto-escapes strings you dump into HTML. These vulnerabilities only exist in this tutorial because PHP treats its output as HTML by default not text, so you need to put in extra effort to be secure.

[cess11]

Django is a framework. If you want to compare against it you'd look at Laravel tutorials.

[taneq]

I still use php for random small scripting. Text processing, that sort of thing. Its great because you can iterate on the code on the command line and then if you want to use it again, slap some HTML around it and stick it on the server.