7 ms·

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

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.

zarzavat 2y ago
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.
- nurettin 2y ago
  Apache knows how to serve php, it is harder with python.
  - creshal 2y ago
    mod_python was supposed to be that, it's a real shame it never got enough traction.
    - nurettin 2y ago
      Perhaps they should have gone for something more specific, like mod_jinja
- KronisLV 2y ago
  > 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/ 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/ 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.
  - mgaunard 2y ago
    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.
    - cess11 2y ago
      Some aren't going to fall into the clown age trap at all.
    - KronisLV 2y ago
      > 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 2y ago
        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.
- skywhopper 2y ago
  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
- lloeki 2y ago
  > in any scripting language Scripting? Ha! We used to do CGI in C when Perl wasn't fast enough. <old-man-yells-at-cloud />
- xigoi 2y ago
  This is not even a hypothetical. CGI is right there.
fartfeatures 2y ago
[flagged]
- solumunus 2y ago
  You sound young, and I would wager you’ve inherited this opinion rather than formed it through experience.
creamyhorror 2y ago
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.)
- xtracto 2y ago
  I remember codeignter fondly from ages ago. It was my first MVC framework, and in php. It was pretty cool.
- labrador 2y ago
  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 https://youtu.be/VUoXtddNPAM?t=14
wouldbecouldbe 2y ago
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
mrtksn 2y ago
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.
- jiggawatts 2y ago
  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.
throwaway92748 2y ago
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 2y ago
  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 2y ago
    if you reach a certain scale and still do that, the language is the least of your worries.
guidedlight 2y ago
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 2y ago
  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 2y ago
    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 https://www.w3schools.com/php/php_mysql_select.asp
    - cess11 2y ago
      W3Schools being consistently shit for decades doesn't really reflect badly on PHP specifically.
      - JimDabell 2y ago
        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 2y ago
taneq 2y ago
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.

zarzavat 2y ago

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.

nurettin 2y ago
Apache knows how to serve php, it is harder with python.
- creshal 2y ago
  mod_python was supposed to be that, it's a real shame it never got enough traction.
  - nurettin 2y ago
    Perhaps they should have gone for something more specific, like mod_jinja
KronisLV 2y ago
> 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/ 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/ 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.
- mgaunard 2y ago
  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.
  - cess11 2y ago
    Some aren't going to fall into the clown age trap at all.
  - KronisLV 2y ago
    > 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 2y ago
      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.
skywhopper 2y ago
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
lloeki 2y ago
> in any scripting language Scripting? Ha! We used to do CGI in C when Perl wasn't fast enough. <old-man-yells-at-cloud />
xigoi 2y ago
This is not even a hypothetical. CGI is right there.

fartfeatures 2y ago

[flagged]

solumunus 2y ago
You sound young, and I would wager you’ve inherited this opinion rather than formed it through experience.

creamyhorror 2y ago

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

xtracto 2y ago
I remember codeignter fondly from ages ago. It was my first MVC framework, and in php. It was pretty cool.
labrador 2y ago
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 https://youtu.be/VUoXtddNPAM?t=14

wouldbecouldbe 2y ago

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

mrtksn 2y ago

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.

jiggawatts 2y ago
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.

throwaway92748 2y ago

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 2y ago
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 2y ago
  if you reach a certain scale and still do that, the language is the least of your worries.

guidedlight 2y ago

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 2y ago
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 2y ago
  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 https://www.w3schools.com/php/php_mysql_select.asp
  - cess11 2y ago
    W3Schools being consistently shit for decades doesn't really reflect badly on PHP specifically.
    - JimDabell 2y ago
      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 2y ago

taneq 2y ago

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.