PHP solves so many problems to do with deployments and scalability automatically.
- You don't need to explicitly install your replacement code and start that server (java -jar .... / node server.js )
- You don't need a systemd unit to keep your server running ( you can deploy as many PHP files as you like and they'll all be "running" )
- You don't have to worry about keeping your server up (the php file).
- You don't need to use Docker because PHP is pretty stable target.
- You're not forced to deploy Kubernetes or Docker swarm to deploy code infront of users.
- You could use Ansible to deploy your PHP but you can probably just use git.
- You can spin up multiple servers and deploy the same file to them all and nginx and php-fpm shall handle concurrency and parallelism for you since each PHP session is independent and stateless.
> You don't need to explicitly install your replacement code and start that server
This is a double-edged sword though. Let's say I have a PHP file that "include"s another one and a request arrives in the middle of such a deployment where the first PHP file has been replaced but the second has yet to be - you now have undefined behavior.
Filesystem-based URL routing is one of the "features" I hate the most in PHP as it leads to countless security issues - simply uploading a file in the wrong place (or sometimes merely with a wrong extension) immediately turns into an RCE.
That's why you do symlink-based deployments with PHP. It works just fine and is also not a problem unique to PHP.
PHP itself doesn't follow filesystem-based routing, your webserver config does. PHP just executes what th webserver tells it to. Most PHP applications written in the last 10 years use a single entry point and are no longer prone to the attacks you are describing.
Yes it's true that proper config can make this problem go away, but the fact that some of the advantages of PHP such as ease of deployment (drop a .php file -> you have a webapp) is a double-edged sword as it encourages a lot of bad practices (that large legacy projects such as Wordpress continue promoting).
It's indeed possible (and quite pleasant) to do proper PHP with a good framework, sane web server config & modern development practices. The problem is that a sizeable chunk of the PHP ecosystem (and very popular projects such as Wordpress) are not doing that.
> - You don't need to use Docker because PHP is pretty stable target.
Not sure I agree with this. Upgrading PHP versions or managing extensions can be _sometimes_ a PITA, using Docker makes it easier. but for simpler apps, sure, apt install php and a few extensions, and you are good to go.
OTOH - a bit off though - I still haven't figured out how to properly build a php stack with Docker. Do I add an nginx instance to each app image? Or should the app container expose only the FPM? If I'd have to do it nowadays, I'd probably go with the second.
here is an example,
https://github.com/visualex/docker-boilerplate-nginx-apache-...
not using FPM but Apache, but you can see how nginx fits into the picture,
you would be doing something like a
fastcgi_pass testsite:9000;
using the names in the referenced repo.
I wanted to emphasise the easiness of PHP in my comment.
You don't need a systemd unit file for your php files whereas you do for your Java app unless you're using a Java container such as Tomcat.
I have typically used system packages to install PHP and nginx and fpm which includes those systemd units
My overreaching point was the ease of using PHP. As a low tech solution.
In the previous era you just FTP your files to the server but you can use git instead which is probably easier than using Ansible. (That's my comparison of FTP vs Git vs Ansible and which is easiest)
Doing zero downtime deployments with PHP is easier than Java (rolling deploys in Kubernetes)
A bunch of these seem like either non-problems with other languages (what language forces you to use kubernetes?), or just “I’m at small scale and therefore don’t need to solve problems that come with large scale”.
> You don't need to explicitly install your replacement code and start that server (java -jar .... / node server.js )
If you just copy your code without explicitly flushing opcache, or having traffic on that server that you are copying your code to, that can lead some interesting issues where your old and new code pieces running simultaniuosly
> You don't need a systemd unit to keep your server running
Actually a systemd unit keeps your PHP-FPM processes running on most of the Linux distributions. But writing a systemd unit config file is like 10 lines
> You don't have to worry about keeping your server up
This is redundant with the point above.
> You don't need to use Docker because PHP is pretty stable target.
First, you don’t need Docker for other languages. Actually a static linked binary (for example Go) is much more portable than a PHP application.
Secondly, good luck for keeping your OS up to date.
> You're not forced to deploy Kubernetes or Docker swarm to deploy code infront of users.
You are not forced to do this with any other languages. I was running Java, Node.js, Python, Ruby, Go applications without any of these (in large scale).
> You could use Ansible to deploy your PHP but you can probably just use git.
You can do this with any other language.
> You can spin up multiple servers and deploy the same file to them all and nginx and php-fpm shall handle concurrency and parallelism for you since each PHP session is independent and stateless.
Haha, thats a good joke.
Once we ran into a PHP-FPM issue where separate FPM pools were running each others (separate) codebase randomly.
And there are sessions, local files and opcache that are all stateful. PHP won’t help you writing safely scalable code at all. That’s up to the developers, regardless of the programming language.
Oh, and PHP-FPM has nothing to do with handling concurrency.
Nginx and php-fpm (and the started php pool processes) together provides simultaneous parallelism and concurrency because each web client can do (edit: multiple) independent things at the same time.
Actually in what concerns Java you don't need to restart anything beyond upload a new WAR file, hardly much different than uploading a bunch of PHP files.
You also don't need docker, application servers were docker before docker was an idea.
I remembered reading and loosely following OSGI model in Java land and used Tomcat and forgot about WAR files.
I like that Erlang programs are robust and even if a program crashes, the BEAM runtime won't take the BEAM process out.
PHP programs don't tend to cause the nginx or php-fpm to crash but just the particular interpretation PHP instance which is replaced with a replacement restarted automatically.
Sure, 10-20 years ago the language was more hacky than anything, but nowadays its a solid choice for backend stuff, with lots of activity, new innovations, good, proven frameworks (Symfony, Laravel) and also lots of people who have experience in it.
I have a few projects running a PHP API with a JS frontend (Vue in my case) and it works pretty nicely. Best of both worlds!
For scripts I use Python, but I like to use PHP for short quick scripts when a database is involved since all it takes is to install php and php-pdo to have a consistent api for db access to get started with, which for python is not the case.
But from time to time I am reminded how bad PHP and outright dangerous can be. Just the other day I had an array like this: ["123"=>"foo", "321" => "bar"] on which I used array_keys expecting to get ["123", "321"] as a result. Surprised why my script was not working the way it was supposed to I found out that the result was actually [123, 321] instead. Yep, PHP casts strings to numbers in this case when it can. I will hit a "gem" like this every now and then, there are plenty of such dumb things scattered in PHP that will bite you the least expected way that makes me stop and think to use something else.
pdo is a common interface layer for databases for php, like jdbc in java or ado.net in C# so I can use the same api for any supported database.
In python technically dbapi standard exists for the same task, but the driver apis annoyingly vary so much between themselves that if i have to i go with sqlalchemy, but it's no longer a lightweight solution
People love to hate on PHP then love to love JavaScript. It's bonkers. PHP is clearly better than JavaScript, it's just that we're all forced to use JS.
I really do not understand this take and have to assume people who say this have not deeply used PHP. It has a large variety of bizzare language features that make JavaScript look downright well-designed.
Examples off the top of my head:
* Lists and dictionaries being the same data type ("array"). This makes it impossible to distinguish between an empty list and an empty dictionary, good luck encoding that JSON.
* Arrays are pass-by-value
* '123' == '+123' evaluates to true
* '0' == '0.000' evaluates to true
* `$a = true; $b = false; $c = $a and $b;`, $c evaluates to `true`
* Closures requiring you to explicitly list every variable from the parent scope you want to use
* References (&$var) have a lot of footguns
* array_key_exists and property_exists taking opposite parameter orders
* stdlib naming in general being pretty bad, with the stated justification being that strlen() was used as a hash function in early PHP versions, so functions were named to achieve an even distribution: http://news.php.net/php.internals/70691
GP didn't say PHP is a good language. GP is saying that many hate PHP while praising JS, which is another impressive pile of crap on many fronts: semantics, standard library, ecosystem.
All those bad things about PHP you've listed go well with Gary Bernhardt's WTF video about JS's inconsistency.
JavaScript is not well-designed however you squint at it, and claims that it's gotten better must come from people that have not used any other language before.
I'm familiar with the Wat talk, the flaws in JS are not nearly as egregious. I'm not saying that JS is well-designed, just that PHP is so badly designed that it makes JS look good by comparison.
I hate both. But to be fair I started hating JS 15 years ago when IE6 support was still important, and I haven't touched PHP in 10 years so it may have improved significantly. I'll still use either if I run into a proper use case for them.
It's a terrible language full of dangerous quirks that require every single line to be carefully crafted with great knowledge or else the "works most of the times but isn't quite what you want here" footguns will get you. And many of those quirks exist right at the surface, no framework can remove those. Sure, it's possible to succeed using php despite all this, but that does not make it a non-terrible language.
Hell no. PHP is awful for background processing. I do DevOps for a bunch of different languages (Node.js, Elixir, PHP, Java) and PHP is always the problem child. Poor concurrency, memory leaks, general RAM bloat, etc.
They didn't say "background processing". They said "backend stuff"—ie, the code that runs on the server that does the processing for stuff the client submits, as opposed to "frontend stuff," which runs on the client itself.
PHP isn't great for persistent background processing because that's not what it's designed for, any more than Python is good as a frontend DOM manipulation language.
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.
I 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.
However php can be used for background processing if done right - but its speed in processing large amounts of data is dogshit. For instance if you wish to iterate massive arrays in one go then python is waaay better. If you wish to iterate each one at a time then that can easily be done via queues and can be parallelised endlessly quite easily.
But one common issue with php devs is that they are religious about the language. Probably because they dont actually understand programming as a whole - not even php itself. They should use the best tool for the task at hand and not be religious about php.
I remember when i was in that dark place i even considered php for gui apps lmao because php was hot hot hot.
There is (almost) /always/ a faster language. As with any stack, the advantage of PHP being used for background processing in a PHP application is you're already using it, so you don't end up having to manage multiple codebases.
I was involved in several large PHP projects which did a lot of background processing (not Google scale, but telco scale) and performance was more than adequate in all cases.
The advantages of running a single codebases far outweighed any potential benefit of a speed increase from switching to another language. (... I say that having been the jerk that actually did rewrite one small component in C and it turned out to be a huge waste of time and effort and just meant something additional the team has had to manage in the almost 20 years since I did it!)
Well ok but it seems like the C app you “wasted time” on lasted 20 years. I bet the rest of that stack either moved away from php or added extra languages.
But yes, the reluctance to use other languages and different codebases was also a common argument in all php teams i worked with. People need to understand that a language is a tool not a religion. If using php for the web layer, python for processing background tasks and nodejs for apis makes sense then do so by all means. PHP devs need to understand that.
The PHP apps i built were for large userbases processing billions of pounds and in one case dollars a year. The language if used right is superb.
It’s the type of dev using it that’s usually not, I am sorry to say that.
> I bet the rest of that stack either moved away from php or added extra languages.
Heh, nah, the rest of the stack is still running. The first line of PHP code that I personally wrote was in 1999 and it's still there; the core CMS was written earlier than that.
It's not doing anywhere near the traffic it used to (it was a reasonably popular video gaming site back in the day; it gets almost zero maintenance & I'm continually impressed it's online and working just as well as it did (... arguably better because it has so much less load :)
> It’s the type of dev using it that’s usually not, I am sorry to say that.
I don't disagree but I also don't think that is a problem unique to PHP at all. Arguably some languages are better than others at keeping developers on the rails in some cases, but you're going to see garbage written in everything eventually.
Memory leaks in PHP? Poor concurrency? Thats new. However what you describe is more of a developer skill problem. Although i’d use other languages for background processing - ie python or nodejs PHP can be pretty solid too but you know, use the right tool for the task at hand. Being religious about a language is a symptom of poor engineering skills - common in the php world, where they tend to use it for everything.
“developer skill problem”. Nice insult there, I’m tempted to respond in kind, but I’ll just point out that PHP doesn’t have much support for async operations of any kind, and all the big frameworks are written in single-threaded “blocking” fashion, so the only way to have parallel processing is to run multiple instances of the program in parallel.
And if you google for “php memory leak”, you’ll get a lot more than 0 results.
Sorry for making it sound as an insult, i should have phrased it differently.
Since php scripts are meant to be run once per request memory leaks are not an issue - any build up gets “reset” once execution ends. There are however shit frameworks that have circular references to objects and do all kinds of crap that builds memory up - easily avoided by parallel queue consumers.
Threading and async are non issues given my statement above, hence me blaming on the dev’s skill and not understanding what the language does.
For instance, you dont normally start a background process with an event loop to handle stuff. You start queue consumers at set intervals that run in parallel, or scripts that process batches of code - thus mimicking parallelism in a classic multi threaded app. This way you reduce the blast radius, are guaranteed that at least some data will always be processed and avoid memory leaks alltogether. No need for “conscious” async since its async by nature.
However there is nuance in everything. Would you be able to provide a specific example of where you end up with such issues so i can better detail an example of how i would approach it?
> php scripts are meant to be run once per request memory leaks are not an issue
Yes, and that’s exactly why I said that PHP is awful for background processing, because there the process ideally runs continuously, or at least as long as there’s data to process. With PHP, I have to continuously re-spawn the processes to keep the memory leaks in check.
If your application is so simple that it doesn’t need to process data outside of the request/response cycle, I’m sure PHP is fine.
And sure, you can compensate for PHPs lack of async processing by spawning more processes, but that makes the RAM bloat problem even worse.
We have scripts that have been running continuously for probably years at a time with none of these issues. The only time they stop is when servers are rebooted for updates.
We actually had a big argument about building them like this for exactly the reasons you mentioned though - the preference for me and some others was to run them as once off's from cron, specifically to avoid the possibility of memory issues.
Our tech lead wanted them to run as services (I think to improve responsiveness primarily). I didn't think it would work as well, but history has proven that it worked fine. I can't say it was better - it took a while to work out the kinks - but these things have been happily running for over a decade with basically zero issues relating to memory leaks, etc. They're not super complicated but not trivial either.
There was never anything really wrong with PHP, just things that - to a computer science student, who just wrote some recursive-descent parser for C++ in OCaML - will seem inelegant to an embarrassing degree. But that doesn't actually matter. The benefits of PHP easily overruled those inelegancies. When you look at the average Ruby/Python/NodeJS project that's been around for more than 10 years, you'll see horrors beyond human comprehension, just like PHP.
I think my problem is not entirely in languages that are not fully typed (although I do prefer them), but rather in languages that are half typed. Either be dynamic or static, not some awkward middle point. Perhaps PHP will get there eventually, but as it is right now is a bit strange to me.
Complexity as a kind of mold culture, growing on the substrate of code and code-like typing, suggests the importance of sterile practice and hygiene, like testing.
It runs everywhere and it's cheap. It's essentially serverless without the expensive, no-cost-limit cloud providers.
I've made a ton of personal projects in php, and I will continue doing so. They're great, they just keep running even when I don't look at them for a long time. Which is exactly what I need.
> There are no generics, and from what I understand for some odd reason will never be even though Hack forked from PHP and managed to add them?
The reason is pretty simple. Hack has a compilation step. PHP does not. Generics in an interpreted language means runtime errors, which are far less valuable and more troubling than compilation errors.
PHP’s loose typing + an offline static analyzer like phpstan will get you roughly the same result without the runtime errors.
In a dynamic interpreted language there is no value of having generics over duck typing or omitting types altogether (and you can narrow down by specifying interfaces). Compiled languages generate a version of your function<T> for every T encountered in the codebase.
For completeness: other compiled languages elide that T and use the types in angulars only to emit errors during compilation. Also perfectly fine, but certainly not any help in absence of static compilation.
i've been freelancer and app creator for more than 10 years.
what's great with php(was) that it just worked. The apps just worked in virtual server for 10 years.
Not anymore. with packet system (composer) +php 7.4...8 and need to have js-frontend everything nothing works anymore. Need to use my time instead of new features to fix build and packet manager problems and these are really difficult to explain to customers.
aahh those easy days with php 5.6 and jquery
It still just works. Every single thing you could do without a package manager in 2009 still works fine without composer in 2023.
All composer adds is the ability to easily use other people's code in your app. And that's not a new thing: people did that in one of two ways pre-2010:
1. They used PEAR/PECL, upon which composer is a massive improvement
2. They copied it from experts exchange, some spammy site like hotscripts.com, or - most often - from the comments section on php.net. The latter was a surprisingly good source but none of this was ever sustainable.
> ...from the comments section on php.net. The latter was a surprisingly good source but none of this was ever sustainable.
Honestly, I wish more documentation out there had comments/discussion at the bottom.
For example, what if would be like to find myself reading about setting up OpenID Connect and having the first (most upvoted) comments on the first page explain things that might not be clear in the docs, analogies that make things easier to understand, or code/configuration snippets for a particular technology.
Somehow the comments in PHP docs were usually like: "after reading the docs, here's what you might want to really know", a bit like those tl;dr apps for manpages: https://tldr.sh/
Things have definitely taken a step back (or at best sideways) since the days of peak PHP popularity in terms of accessibility to new coders wanting to make something simple online. I'd love to see something as simple and portable as Google Docs for coding. There are plenty of proprietary low-code platforms for this, but nothing I know of where you can code with a real language in the browser, but still export the code (like you would export a .doc from Google Docs) to easily run at another cloud location or locally.
PHP as a language and ecosystem is great. Far more suitable for web development than python and trivially easy to scale.
But PHP developers, boy oh boy, are a different story.
My favourite is how they all still debate setter and getters and almost none know the language but only the framework they use and code usually turns into a huge pile of unmaintainable crap. But hey they use ORMs just in case they’ll swap database engines (happens so rarely not even worth mentioning).
In my experience, you're super wrong about the vast majority of PHP engineers
And PHP has wide built-in support for multiple database engines (check out PDO) so this is largely not a part of an ORM.
This leaves the ORM to focus on higher-level work, like how to abstract the differences away regardless of which engine you end up using and focussing on the representation of your data and the API you use to interact with it.
That's pretty powerful and has allowed tools like Laravel and Symfony to suit a super wide range of needs.
But yes, it does also mean that you're not switching your entire language or framework stack when some database technology providers baits-and-switches their licensing - which has been known to happen
The Venn diagram of developers who can't successfully use an ORM, but can write their own sane, well formed, normalized data access layer from scratch using just SQL are two entirely separated circles
Normal people write queries in a bunch of specialised classes. Data access in php is a pdo method call away anyway. But no, php devs need ddd dtos hydration models yml file configs goat sacrifices and a heated religious debate over why php is the belly bottom of web development and indeed the world. Tabs vs spaces.
Such a nice language bastardised by over engineering and reinventing the wheel. Sad.
In a web environment each request is an invocation of a script - sort of, apache spawned a process, nginx used a socket, but generally speaking each request was it’s in own context. You maintain session states in an external storage (disk, db, in memory, etc).
As such errors would be contained within the context of that request, while memory leaks if any would be a non issue since gc is done when the process literarily ends. So that covers that aspect of scaling.
Then all of these external state maintenance dependencies each scale independently. For instance session data can be distributed against endless clusters of redis or nosql instance. Heck some people even used remote file systems for it. Databases would be clustered too - say a couple mysql percona write instances and endless read instances. If that’s not enough then use an intermediary localised storage and queue writes. Or use something like cassandra. Database connections can also be round robin’d since each script would be re executed and connection reopened anyway (can be reused if needed) so they can connect to any server in your cluster. You can also use a database load balancer and sharding, or nosql for fast writes than then get further processed into a relational database.
All in all php webapps can be scaled infinitely. Not as efficiently per instance but fairly straight forward by even average devs with the right guidance.
For some past clients i scaled apps to billions of unique monthly requests with a fairly low effort. Happy to answer any specific question.
Yup. If I were picking up side work, I'd be very wary of PHP projects - not because of the language, but because I'd be afraid of inheriting a tremendous, unreadable, unmaintainable mess.
That's not to say that it doesn't happen in other languages, but I've never seen PHP code written by a stranger that didn't make me squirm.
And the odd part is that frameworks were meant to provide structure and make code easier to maintain.
Last time, long time ago, when i touched a php symfony project i ended coding yml instead of actual php because _everything_ was in a config file - hundreds of packages and libraries just because the dev couldn't be bothered to issue calls to native php functions. Hilarious. However i did make a killing in training teams in design patterns and coding practices to help them maintain quality.
And almost always my advice was to write framework agnostic code (treat the framework as if it were just a dependency). Worked nice. Clean little specialised classes, no config maintenance madness, i also enforced running code linters and smell detectors on each commit and push. Gave up on the language when i noticed that _literarily_ all teams had the exact same issues, the exact same topics of debate and the exact same flamewars.
At some point, we have to go beyond linguistic relativism, and admit that some languages are inherently flawed - when we observe that everyone who uses it struggle with the same problems. It's like the opposite of the "happy path", or "falling into a pit of success". Some languages guide the user toward poorly built software.
Yeah that’s likely true. The reason i like it as a language is that if you do know your design patterns and good engineering it is rather powerful, and the core language has plenty of nice little features. Prior to framework madness and a worker (person that works, not background process) mindset that plagues the php world it allowed for some fun creativity. I remember fondly how fun it was to solve design problems only to learn later on that hey, these are design patterns that other people in other languages use. Was nice to know i had the right “mindset”. It helped me become a better engineer in other languages ironically. I ate slept and dreamt design patterns. But thinking of it it’s because the language so easily becomes a mess that you need to constantly reinvent software programming just to keep things on track.
Therefore all in all i think, for me, php belongs to history, and without wanting to insult anyone, i try and avoid any debated with a pho developer - it simply gets stuck in a bike shedding endless loop.
I'm right there with you, I also grew as a programmer writing lots of PHP. There are many things to like about it, such as the ease of deployment. And how forgiving the language is, especially for beginners - which in retrospect was great for exploration, building my own abstractions and design patterns, but the flip side is that a ton of terrible code has been written because the language lets you.
As I gained more experience, I've become wary (and weary) of how a language or framework can mis-guide programmers into messy code that's difficult to grow and maintain. But then again, as long as the work gets done and money gets made, perhaps it doesn't matter much to some people. For myself, I want to take pride and pleasure in the work, and there are other languages with better design and developer experience.
Living with some of the hellish code that exists in the wild (and honestly terrible code that I've written myself) has been a great learning experience, making me a better programmer. It's important to be sensitive to code smell, noticing how it's going in the wrong direction and what can happen in the long term, understanding how it happens, what can be done to prevent it - and better yet, how a language (syntax, patterns, tooling, ecosystem) can be designed to guide oneself and others so that good code can be written "naturally" by following best practices that are built into it.
- You don't need to explicitly install your replacement code and start that server (java -jar .... / node server.js )
- You don't need a systemd unit to keep your server running ( you can deploy as many PHP files as you like and they'll all be "running" )
- You don't have to worry about keeping your server up (the php file).
- You don't need to use Docker because PHP is pretty stable target.
- You're not forced to deploy Kubernetes or Docker swarm to deploy code infront of users.
- You could use Ansible to deploy your PHP but you can probably just use git.
- You can spin up multiple servers and deploy the same file to them all and nginx and php-fpm shall handle concurrency and parallelism for you since each PHP session is independent and stateless.