My PHP Problems(dantleech.com)
dantleech.com
My PHP Problems
https://www.dantleech.com/blog/2024/02/18/my-php-problems/
157 comments
I've been writing PHP for a quarter century, but I've never become a "whiz" at it.
But I regularly write fast, robust, secure backends, in a day or less (less, if possible. I don't actually like working in PHP).
Despite the torrents of hate from this community, it is still pretty much the backend king.
Here's the "Fishtank Graph."[0] It kind of puts things in perspective.
[0] https://w3techs.com/technologies/history_overview/programmin...
But I regularly write fast, robust, secure backends, in a day or less (less, if possible. I don't actually like working in PHP).
Despite the torrents of hate from this community, it is still pretty much the backend king.
Here's the "Fishtank Graph."[0] It kind of puts things in perspective.
[0] https://w3techs.com/technologies/history_overview/programmin...
I agree that it still owns a massive chunk of the backend market. 20-something years in, and it's still difficult to shake.
However, I would take the numbers on the site you linked with a big grain of salt. Detecting which backend technology powers a site without direct evidence is nearly impossible. PHP may be high up the list since it and its associated stack leak the most metadata.
However, I would take the numbers on the site you linked with a big grain of salt. Detecting which backend technology powers a site without direct evidence is nearly impossible. PHP may be high up the list since it and its associated stack leak the most metadata.
I've totally copied php http headers into non-php backends just to see what happens. It costs nothing and gets a trifle more security.
(Not really but it makes me giggle at least)
(Not really but it makes me giggle at least)
[deleted]
I've always found those statistics to be a bit odd, given how popular other languages are, especially the likes of Python.
Not only that, but since .NET Core and the new versions of .NET running just fine on Linux distros, I'd expect their usage to go up, not down.
Curious. Actually, their disclaimer page seems to suggest that setups with a decoupled SPA/API might not be detected correctly: https://w3techs.com/disclaimer
Not only that, but since .NET Core and the new versions of .NET running just fine on Linux distros, I'd expect their usage to go up, not down.
Curious. Actually, their disclaimer page seems to suggest that setups with a decoupled SPA/API might not be detected correctly: https://w3techs.com/disclaimer
> the likes of Python
I've spent 15 years writing serious code and never ran into Python all that much until I went back to engineering school. I don't think a lot of people use it for their backend code, at least in my experience. But wow are there lots of stats and science people using it exclusively--it's completely ubiquitous in academia and research (though R is making headway).
I've spent 15 years writing serious code and never ran into Python all that much until I went back to engineering school. I don't think a lot of people use it for their backend code, at least in my experience. But wow are there lots of stats and science people using it exclusively--it's completely ubiquitous in academia and research (though R is making headway).
I'm pretty sure that Python is the language of choice for AI stuff. I think even Apple's ML stuff is based on Python.
yeah you're right, I guess I lump that into "academia and research" as opposed to "software engineering" where PHP... exists
> I've always found those statistics to be a bit odd, given how popular other languages are, especially the likes of Python.
Think about how many Wordpress installs there are, not to mention Wiki's and forums.
Think about how many Wordpress installs there are, not to mention Wiki's and forums.
Second that, PHP is still default for hosting providers. I get basic hosting for free on OVH with domain that has PHP by default. So even if I am .net dev on my job I still have some personal stuff in PHP because it is default and I cannot change it for that managed hosting env.
At my previous job, we had micro services in Java that did most of the work. The frontend was a thin layer of PHP that focused on SSR, but PHP is the only detectable tech from the outside
Surprised to see Scala running almost as many website backends as JavaScript. In my mind, it faded in popularity long ago.
The survey methodology is biased toward old technologies, from the era where you sent HTTP headers that advertised the stack you were using. Modern stacks often hide that info. (It's also biased toward techs used in blogs, since when it detects a tech used on blog.example.com, that tech is counted for example.com)
Also it biases towards smaller organizations which don’t follow security guidelines saying that you should disable those banners. There’s a real breadth versus depth discrepancy here.
Perhaps the Scala ecosystem is where Haskell nerds all decided to settle into?
I upvoted you and vouched u/rizky05 because I think they raised an important point.
> It is powerful indeed. But PHP syntax feels unelegant and making me write unnecessary ceremony. It feels different when I write typescript code, every character I type fits like lego.
> Especially when my codebase grows so much. Navigating PHP project is like thrown in forest without a map, you can always look up the sun to find your way.
“Elegance” is something that gives people warm fuzzies, I think this is why there are so many Rust advocates (I am one), when pieces fit together nice or can be refactored cleanly and tests are first-party it is nice.
However there have always been “hacky” and “proper” languages, because doing something hacky that works also feels great.
Python is a hacky language, it’s easy to go to 0-100 very quickly. C++ however requires time and precision to make things proper, so people avoid it and few things are made comparatively in C++ unless it's infrastructure software that people spent a lot of time writing.
Maintainability be damned, sometimes you really just need to throw something together.
The curse of things that work is that they will be expanded upon and kept around for too long.
Unfortunately: PHP works, and is an excellent hack-language for the web. Which means there’s a lot of code that becomes “production grade” that should really have never been intended to live forever in the first place.
> It is powerful indeed. But PHP syntax feels unelegant and making me write unnecessary ceremony. It feels different when I write typescript code, every character I type fits like lego.
> Especially when my codebase grows so much. Navigating PHP project is like thrown in forest without a map, you can always look up the sun to find your way.
“Elegance” is something that gives people warm fuzzies, I think this is why there are so many Rust advocates (I am one), when pieces fit together nice or can be refactored cleanly and tests are first-party it is nice.
However there have always been “hacky” and “proper” languages, because doing something hacky that works also feels great.
Python is a hacky language, it’s easy to go to 0-100 very quickly. C++ however requires time and precision to make things proper, so people avoid it and few things are made comparatively in C++ unless it's infrastructure software that people spent a lot of time writing.
Maintainability be damned, sometimes you really just need to throw something together.
The curse of things that work is that they will be expanded upon and kept around for too long.
Unfortunately: PHP works, and is an excellent hack-language for the web. Which means there’s a lot of code that becomes “production grade” that should really have never been intended to live forever in the first place.
PHP can be super hacky and super structured, within the same file, and it's your choice. You can have tests, static analysis, etc etc, or not. Or you can start without and then adding it as the project mature, without having to necessarily switch to another language.
I'm working on my own startup that started as a side project and it was super hacky at the beginning, but by sticking to PHP (and thanks to PHP continuous improvements) I was able to refactor little by little and make the codebase way more structured and easier to maintain.
I'm working on my own startup that started as a side project and it was super hacky at the beginning, but by sticking to PHP (and thanks to PHP continuous improvements) I was able to refactor little by little and make the codebase way more structured and easier to maintain.
As a vaguely-related anecdote, I wrote a super-hacky PHP script in highschool 20 years ago, it gained some popularity based on being open-source and easy-to-install (PHP’s #1 strength for sure) - and to this day I am still spending a significant chunk of development time refactoring based on ideas that eg Typescript and Rust have out of the box (eg using PHPStan to emulate a language with typed arrays)
(I keep wishing that I could rewrite it in a “better” language, but there is no other language that is even in the same ballpark when it comes to “any random user can upload this .php file to any random web host and expect it to work”)
(I keep wishing that I could rewrite it in a “better” language, but there is no other language that is even in the same ballpark when it comes to “any random user can upload this .php file to any random web host and expect it to work”)
You can write any kind of code in any language, but going against the grain of that language tends to go badly. Even if your style works for you, if it's not what the ecosystem expects you'll have trouble using libraries, you'll have trouble onboarding new hires, ....
> when pieces fit together nice or can be refactored cleanly
This is a trade-off that makes sense to embrace in some contexts, and I do believe that web is one of them. The more nicely your pieces fit together the harder it'll be to break them apart. You can only refactor cleanly once you are aware of all the requirements, but those requirements are usually constantly changing in the context of web and so your pieces fitting together a little too nicely means that you now have to refactor a lot more code.
This is a trade-off that makes sense to embrace in some contexts, and I do believe that web is one of them. The more nicely your pieces fit together the harder it'll be to break them apart. You can only refactor cleanly once you are aware of all the requirements, but those requirements are usually constantly changing in the context of web and so your pieces fitting together a little too nicely means that you now have to refactor a lot more code.
This matches my experience of PHP. The questions/advice on stackoverflow and blog posts are also geared towards people who just want to get something done, which helps a lot if that's your goal.
Go is the only other programming language I've had this experience with - picking it up with a goal in mind and succeeding in doing something more quickly than I might have with a familiar language.
Go is the only other programming language I've had this experience with - picking it up with a goal in mind and succeeding in doing something more quickly than I might have with a familiar language.
I remember someone on SO saying "Go isn't a programming language, it's a DSL for writing networked services", and, well, if we can squint and call Go that, we can definitely call PHP a DSL for dynamic webpages.
You don’t even really need to squint that hard.
That’s what it started as.
It’s entire process model (instantiating the world for each request then tearing it all back down, not having any shared state) is fairly unlike most other general purpose languages.
PHP inverts the usual assumption that “this code file is primarily code” on its head—it assumes any file it’s given contains other data until it finds the special open/close tags signifying a section that contains code. (Allowing you to embed it within HTML easily.)
The runtime handles things like GET/POST variables natively and has a special way to expose them. Ditto for file uploads.
The standard library isn’t extensive but contains a ton of functionality that revolves around managing web requests. (Managing HTTP headers, setting and reading cookies, ...)
Etc, etc.
That’s what it started as.
It’s entire process model (instantiating the world for each request then tearing it all back down, not having any shared state) is fairly unlike most other general purpose languages.
PHP inverts the usual assumption that “this code file is primarily code” on its head—it assumes any file it’s given contains other data until it finds the special open/close tags signifying a section that contains code. (Allowing you to embed it within HTML easily.)
The runtime handles things like GET/POST variables natively and has a special way to expose them. Ditto for file uploads.
The standard library isn’t extensive but contains a ton of functionality that revolves around managing web requests. (Managing HTTP headers, setting and reading cookies, ...)
Etc, etc.
I'd say any sufficiently elaborated template language becomes Php.
Damn that would be a pretty elaborate template language
I’ve been using Go in this capacity quite a lot recently, replacing Java code I had previously been using for these kinds of tasks. And have been pleasantly surprised how straightforward the code is.
Especially now with generics support. I’ve been able to quickly write little meta functions for things like translating Kafka events to a channel of structure and spin up a number of go routines to handle them by making REST calls. The code is concise, clean, and simple, without being overly clever.
Especially now with generics support. I’ve been able to quickly write little meta functions for things like translating Kafka events to a channel of structure and spin up a number of go routines to handle them by making REST calls. The code is concise, clean, and simple, without being overly clever.
It's such a perfect match for the HTTP protocol. You drop a file on a server and you're good to go. My toy VPS is full of useful scripts that I use on a daily basis. Most of them are literally one big file with all of the code, no external dependencies. Caddy proxy the request into PHP-FPM and send back the response, no bullshit.
Of course this is not what we see at production-grade software, but I really enjoy the fact that the language was designed with the HTTP protocol in mind. It's really unique in this sense.
Of course this is not what we see at production-grade software, but I really enjoy the fact that the language was designed with the HTTP protocol in mind. It's really unique in this sense.
On the other hand, vanilla PHP effectively "hides" HTTP from the programmer. I taught myself PHP in middle school and high school as my first programming experience, and had no concept of a thing called "HTTP" for a very very long time. I knew the pieces of it that PHP gave me. I knew what $_POST, $_GET, $_SERVER, $_HEADER, set/getcookie(), were and how to manipulate them, and I knew the rules (setting a header after "echo" made it complain), but I didn't understand how that all hung together as a thing outside PHP called HTTP.
When I did learn about HTTP, it was very easy, since I already knew it without knowing I knew it, so maybe that's in favor of your point, but there's much to be said for the actual understanding that I didn't have at first. When I started interviewing people for PHP entry-level jobs, asking about HTTP was one of the ways I gauged how well applicants understood their work at a conceptual level.
When I did learn about HTTP, it was very easy, since I already knew it without knowing I knew it, so maybe that's in favor of your point, but there's much to be said for the actual understanding that I didn't have at first. When I started interviewing people for PHP entry-level jobs, asking about HTTP was one of the ways I gauged how well applicants understood their work at a conceptual level.
This mirrors my experience exactly - it took me an embarrassingly long time to learn about http and what it means to be stateless.
It also took learning other languages to understand how PHP is so unique in how tied to HTTP it is (rebuilding its entire universe every request).
(these learnings happened when moving beyond the PHP-based CMS style of development - agency style work on my case - to make more custom software).
It also took learning other languages to understand how PHP is so unique in how tied to HTTP it is (rebuilding its entire universe every request).
(these learnings happened when moving beyond the PHP-based CMS style of development - agency style work on my case - to make more custom software).
yes, and the fact that you can just put inline HTML outside of PHP tags is so useful and convenient
LOL
The fact that I can't tell if this comment is sarcasm or snark or serious says a lot.
PHP mixed with HTML was one of the "bad ideas" that hurt PHP. It was a bad practice that got out of hand.
Now why no one bats an eye at node/react doing this very thing and calling it JSX is beyond me but...
The fact that I can't tell if this comment is sarcasm or snark or serious says a lot.
PHP mixed with HTML was one of the "bad ideas" that hurt PHP. It was a bad practice that got out of hand.
Now why no one bats an eye at node/react doing this very thing and calling it JSX is beyond me but...
> Now why no one bats an eye at node/react doing this very thing and calling it JSX is beyond me but...
Hey don't drag Node into this, you aren't forced to do any of that.
React to me feels like SPA developers discovering the idea of PHP and thinking they invented it. This shouldn't be surprising, since React came from Facebook, and Facebook historically is a PHP shop.
Mixing your business logic and presentation is a bad idea, but it's very attractive when you don't have the informative scars
You might say, doesn't Facebook have the scars to avoid designing React? Well, when you have a hammer, everything looks like a nail.
PS: I would suspect the down voting is just the "LOL", otherwise it's a fair comment.
Hey don't drag Node into this, you aren't forced to do any of that.
React to me feels like SPA developers discovering the idea of PHP and thinking they invented it. This shouldn't be surprising, since React came from Facebook, and Facebook historically is a PHP shop.
Mixing your business logic and presentation is a bad idea, but it's very attractive when you don't have the informative scars
You might say, doesn't Facebook have the scars to avoid designing React? Well, when you have a hammer, everything looks like a nail.
PS: I would suspect the down voting is just the "LOL", otherwise it's a fair comment.
> You might say, doesn't Facebook have the scars to avoid designing React? Well, when you have a hammer, everything looks like a nail.
This is accurate, and I never thought of it that way.
> PS: I would suspect the down voting is just the "LOL", otherwise it's a fair comment.
I did laugh out loud because I did not know WHAT to make of the comment. As someone who buttered my bread on PHP when everyone hated it, it was a sign of how times have changed!
This is accurate, and I never thought of it that way.
> PS: I would suspect the down voting is just the "LOL", otherwise it's a fair comment.
I did laugh out loud because I did not know WHAT to make of the comment. As someone who buttered my bread on PHP when everyone hated it, it was a sign of how times have changed!
Why is it a "bad idea"? I'm genuinely curious.
It works great, it's fast and you don't have to learn a new templating language or dialect every 2-3 years. Or try to figure out how to do trivial things like loops in loops.
I don't quite get the use of templating engines in PHP because PHP is a templating engine itself.
It works great, it's fast and you don't have to learn a new templating language or dialect every 2-3 years. Or try to figure out how to do trivial things like loops in loops.
I don't quite get the use of templating engines in PHP because PHP is a templating engine itself.
Templating systems produce output based on a template and a set of data. PHP produces output based on imperative code that can do anything. While you can certainly adhere to your templates only consuming data (ie some kind of view model), it's actually awkward to do, as PHP files don't take parameters, so you need to use a convention of having your "template" files provide functions and call them, but functions are global so you now need to name them uniquely to avoid collisions. If templates are meant to be pluggable, this is much more difficult because you have two templates that are supposed to be interchangeable, with identifiers for calling them that are different[1]. There are a lot of properties of template systems that PHP does not actually have.
[1] It's so much worse than this... You can use some horrible hacks like undefining a well-known function that each template implements, but this would only work one level deep without also adding a mechanism for "calling" a template, and at that point you are making a template system on top of PHP.
[1] It's so much worse than this... You can use some horrible hacks like undefining a well-known function that each template implements, but this would only work one level deep without also adding a mechanism for "calling" a template, and at that point you are making a template system on top of PHP.
> as PHP files don't take parameters
$_SERVER, $_POST, $_GET.
The rest is not the PHP3 I recognize to be honest, let alone the modern stuff. Remember include() literally just included the code right there, inline, so you could include in functions and gain the function's scope:
$_SERVER, $_POST, $_GET.
The rest is not the PHP3 I recognize to be honest, let alone the modern stuff. Remember include() literally just included the code right there, inline, so you could include in functions and gain the function's scope:
function render($data) {
switch ($data['foo']) {
case 'bar': include('bar.inc'); break;
case 'baz': include('baz.inc'); break;
}
}
All of those variables are global, there's no way to establish an interface between the caller and the callee without using functions. You could certainly have a shared understanding of what variables have been injected into a global, but this is awkward, and requires you to do cleanup after each template instantiation to avoid leaking values between templates, which can cause subtle bugs.
> Remember include() literally just included the code right there, inline, so you could include in functions and gain the function's scope:
I've talked about this approach elsewhere in thread, it is not nestable without building a way to "call" templates on top of require/include, and when you do that you'll need to undefined the render function to do it as well, which creates additional complexity. At that point, the original premise of just using raw PHP isn't very true, because you are now building a framework or templating system around it.
Also, you have to contend with the magic "render" function not being globally defined by something. It's messy.
> Remember include() literally just included the code right there, inline, so you could include in functions and gain the function's scope:
I've talked about this approach elsewhere in thread, it is not nestable without building a way to "call" templates on top of require/include, and when you do that you'll need to undefined the render function to do it as well, which creates additional complexity. At that point, the original premise of just using raw PHP isn't very true, because you are now building a framework or templating system around it.
Also, you have to contend with the magic "render" function not being globally defined by something. It's messy.
> there's no way to establish an interface between the caller and the callee without using functions
Um. Can you give me an example to pad that out a bit?
> and requires you to do cleanup after each template instantiation to avoid leaking values between templates
In my render() example, isn't that "reaching the end of the function"? (Edit: Wait, you're only talking about the superglobals, right?)
Um. Can you give me an example to pad that out a bit?
> and requires you to do cleanup after each template instantiation to avoid leaking values between templates
In my render() example, isn't that "reaching the end of the function"? (Edit: Wait, you're only talking about the superglobals, right?)
> Um. Can you give me an example to pad that out a bit?
Your example of using a render() function is already an example of this. You can parameterize render() to provide data to the template from the caller without utilizing untyped globals, and without having to clean the globals up after the template has rendered.
> Wait, you're only talking about the superglobals, right?
Yes. Globals are globals. PHP's super global distinction isn't really relevant to whether you are tainting the execution environment when you pass data to a script.
The point is, as I elaborate elsewhere, PHP is very awkward to use as a proper templating system.
Your example of using a render() function is already an example of this. You can parameterize render() to provide data to the template from the caller without utilizing untyped globals, and without having to clean the globals up after the template has rendered.
> Wait, you're only talking about the superglobals, right?
Yes. Globals are globals. PHP's super global distinction isn't really relevant to whether you are tainting the execution environment when you pass data to a script.
The point is, as I elaborate elsewhere, PHP is very awkward to use as a proper templating system.
>functions are global so you now need to name them uniquely to avoid collisions
I hear this here, and elsewhere I hear that PHP has evolved into a decent language. Both can't be true.
I hear this here, and elsewhere I hear that PHP has evolved into a decent language. Both can't be true.
The discussion thread here may underrepresent OOP PHP.
Large software in PHP usually uses namespaces instead of declaring functions at the top-level scope.
And most projects except for legacy ones lean towards objects and classes over plain functions.
Namespaces allow non-global functions without a wrapping class already, IIRC. Looking up though, there seem to be special cases (legacy behavior, making everything at the top level global) when using namespaced files with include() statemtents, if I read the docs correctly.
Dumping pure functions as static members into wrapper classes was not uncommon when I used PHP.
But primarily, a lot of code was heavy on dependency injection and inversion of control, Symfony being the leader of this coding style maybe.
TFA also seems to be about class-oriented programming, but not the heavy design-pattern style mentioned above.
The linked TUI CLI parser looks like a nice and lean PHP OOP example.
Namespaces allow non-global functions without a wrapping class already, IIRC. Looking up though, there seem to be special cases (legacy behavior, making everything at the top level global) when using namespaced files with include() statemtents, if I read the docs correctly.
Dumping pure functions as static members into wrapper classes was not uncommon when I used PHP.
But primarily, a lot of code was heavy on dependency injection and inversion of control, Symfony being the leader of this coding style maybe.
TFA also seems to be about class-oriented programming, but not the heavy design-pattern style mentioned above.
The linked TUI CLI parser looks like a nice and lean PHP OOP example.
Function names are scoped to the current namespace. This means that for local closures it is usually better to define functions as variables
$closure = function(){};
instead of
function closure(){}
$closure = function(){};
instead of
function closure(){}
Its not true at all.
A few reasons:
1. It's a loaded foot gun. PHP was notorious for 1000 line files with HTML and SQL all mixed together. (I speak from personal experiences on this)
2. Templating languages are "portable" (In theory). Have a mixed env of PHP and Java... there were templating languages that would work for both teams, it took a step out of scalability.... XML and XSLT were the promise land on this one, but we fucked all that up. Portability is a big deal. We're still slinging CSV files for a good reason.
1. It's a loaded foot gun. PHP was notorious for 1000 line files with HTML and SQL all mixed together. (I speak from personal experiences on this)
2. Templating languages are "portable" (In theory). Have a mixed env of PHP and Java... there were templating languages that would work for both teams, it took a step out of scalability.... XML and XSLT were the promise land on this one, but we fucked all that up. Portability is a big deal. We're still slinging CSV files for a good reason.
1. I've seen enough terrible things in my time, but you can make a mess in any language using any number of frameworks. And it's been a hot minute since I've seen one of those 1000+ line PHP+SQL+HTML+JS+CSS monstrosities in any serious environment.
Improper use of templating engines or trying to use templating engines that aren't up to the task can give you headaches just as well. Sadly no amount of frameworks or templating engines can stop a bad programmer from writing bad code, in the end we're craftsmen who need to learn how to use our tools.
2. This could be a valid use case, but a rather rare one. XML+XSLT is something that sounds fantastic on paper, but as anyone who actually worked with it knows it ranges from a big disappointment to an absolute nightmare.
Improper use of templating engines or trying to use templating engines that aren't up to the task can give you headaches just as well. Sadly no amount of frameworks or templating engines can stop a bad programmer from writing bad code, in the end we're craftsmen who need to learn how to use our tools.
2. This could be a valid use case, but a rather rare one. XML+XSLT is something that sounds fantastic on paper, but as anyone who actually worked with it knows it ranges from a big disappointment to an absolute nightmare.
> Sadly no amount of frameworks or templating engines can stop a bad programmer from writing bad code,
It's not a matter of whether the code is bad or not, but how bad.
The entire point of frameworks is to add guard rails to help you stay disciplined and avoid cutting corners on separation of concerns.
Using PHP as a template language tempts developers to violate SOC every day.
It's not a matter of whether the code is bad or not, but how bad.
The entire point of frameworks is to add guard rails to help you stay disciplined and avoid cutting corners on separation of concerns.
Using PHP as a template language tempts developers to violate SOC every day.
If you need guard rails to keep you from performing database manipulations in your views you have other problems to worry about. And if anything people are cutting corners on SOC in the M and C part of MVC, not the V part.
Also I don't see how using a loop or conditional in PHP is any different from using one in a templating engine, aside from the overhead of the engine and added annoyance of debugging another language in your project.
Also I don't see how using a loop or conditional in PHP is any different from using one in a templating engine, aside from the overhead of the engine and added annoyance of debugging another language in your project.
> If you need guard rails to keep you from performing database manipulations in your views you have other problems to worry about.
Those problems are called "junior developers", and I think we'd all like to avoid them, but that's not very sustainable.
Perhaps we can fix the education problem, but given that folks just do a boot camp and head into the market, prospects aren't looking good.
> Also I don't see how using a loop or conditional in PHP is any different from using one in a templating engine, aside from the overhead of the engine and added annoyance of debugging another language in your project.
The problem is convention, or lack thereof. Without convention, who's to say where that database call should live? Frameworks, which tend to use templating languages for this reason, tend to make that convention clear to all teammates.
I want to mention that this doesn't mean you can't use PHP as the programming language for your templates as long as the conventions are clear, but PHP is poorly suited to being a template language for reasons I've posted elsewhere in this thread.
Those problems are called "junior developers", and I think we'd all like to avoid them, but that's not very sustainable.
Perhaps we can fix the education problem, but given that folks just do a boot camp and head into the market, prospects aren't looking good.
> Also I don't see how using a loop or conditional in PHP is any different from using one in a templating engine, aside from the overhead of the engine and added annoyance of debugging another language in your project.
The problem is convention, or lack thereof. Without convention, who's to say where that database call should live? Frameworks, which tend to use templating languages for this reason, tend to make that convention clear to all teammates.
I want to mention that this doesn't mean you can't use PHP as the programming language for your templates as long as the conventions are clear, but PHP is poorly suited to being a template language for reasons I've posted elsewhere in this thread.
>>> If you need guard rails to keep you from performing database manipulations in your views you have other problems to worry about.
Its a one off... Its just an internal tool... This is a prototype... It's a hot fix...
I know better, I have done it. It is only with dumb luck that they didn't end up as products. Some people dont know that they should not or that it isnt a place they should try to "get away" with it. These things grow and then turn into products and someone has to clean them up.
Source: I made a lot of money turning PHP "projects" into "software".
> Also I don't see how using a loop or conditional in PHP is any different from using one in a templating engine
One of these things is Turing complete. The other is not.
Templating languages have their own laments: see yaml configs used to create "workflows", "environments" and "servers" via templating.
Its a one off... Its just an internal tool... This is a prototype... It's a hot fix...
I know better, I have done it. It is only with dumb luck that they didn't end up as products. Some people dont know that they should not or that it isnt a place they should try to "get away" with it. These things grow and then turn into products and someone has to clean them up.
Source: I made a lot of money turning PHP "projects" into "software".
> Also I don't see how using a loop or conditional in PHP is any different from using one in a templating engine
One of these things is Turing complete. The other is not.
Templating languages have their own laments: see yaml configs used to create "workflows", "environments" and "servers" via templating.
I've seen Python that was almost as bad as PHP. At one company, a guy actually complained that he didn't want to use multiple files, third-party packages, or anything outside of the stdlib. He'd write everything inside of a single "main.py" that ran as an AWS Lambda, which he often edited live in the console. When I first saw this, I thought I had landed on another planet.
At another job, another guy built some massive abstract-factory-factory-layer in Python, a class hierarchy 4 or 5 layers deep. 5000+ lines in a single file. It was almost impossible to debug.
Both of these are better than some C++ code I once saw. 10,000+ lines in a single file. In that file, there was a function with a 3000+ line case statement, which was mostly copy-pasta'd from other parts of the code (not in that 10K line file.)
I have seen plenty of PHP code that smelled like a nuclear dumpster fire, but you can write trash in any language.
At another job, another guy built some massive abstract-factory-factory-layer in Python, a class hierarchy 4 or 5 layers deep. 5000+ lines in a single file. It was almost impossible to debug.
Both of these are better than some C++ code I once saw. 10,000+ lines in a single file. In that file, there was a function with a 3000+ line case statement, which was mostly copy-pasta'd from other parts of the code (not in that 10K line file.)
I have seen plenty of PHP code that smelled like a nuclear dumpster fire, but you can write trash in any language.
> I don't quite get the use of templating engines in PHP because PHP is a templating engine itself.
Do you write safe templates in PHP ?
Do you write safe templates in PHP ?
Yep. Linters help. And are lighter than other templates engines (eg Blade, Twig) and give me static analysis.
> react doing this very thing and calling it JSX
In PHP, “HTML" is string concatenation; in React, “HTML" is an HTML-flavoured bit of syntax sugar over HTML-generating functions (and you are still welcome to call the functions yourself, if you want your HTML-generation code to avoid looking like HTML). Aside from looking kind-of similar if you squint, I’d say the differences and pros and cons are fairly significant (For example the IMO worst thing about the PHP approach, the ease of shooting yourself in the foot with XSS holes, is a non-issue in JSX).
In PHP, “HTML" is string concatenation; in React, “HTML" is an HTML-flavoured bit of syntax sugar over HTML-generating functions (and you are still welcome to call the functions yourself, if you want your HTML-generation code to avoid looking like HTML). Aside from looking kind-of similar if you squint, I’d say the differences and pros and cons are fairly significant (For example the IMO worst thing about the PHP approach, the ease of shooting yourself in the foot with XSS holes, is a non-issue in JSX).
I built the Swytch Framework to exactly hit these spots. As far as I know, it’s the only templating system out there with contextual escaping (you write html, it parses the html using a streaming parser, escapes output, then writes it out).
I use it exactly for rapid dev of stupid ideas. I’m not sure if I’d use it in a production environment because it is quite slow.
I use it exactly for rapid dev of stupid ideas. I’m not sure if I’d use it in a production environment because it is quite slow.
> Now why no one bats an eye at node/react doing this very thing and calling it JSX is beyond me but...
Indeed.
Indeed.
It did make total sense at the time. Consider we are talking a time where you had static html.
It is obviously good to be able to automate generating web pages based on say the state of a database. As this gives you up-to-date pages without someone having to manually build them.
And if that - automatically build web-pages from a database - is your goal and your current state of the art is static pages, then creating a language you can interject into your static pages, to build the page dynamically is a no brainer.
It is obviously good to be able to automate generating web pages based on say the state of a database. As this gives you up-to-date pages without someone having to manually build them.
And if that - automatically build web-pages from a database - is your goal and your current state of the art is static pages, then creating a language you can interject into your static pages, to build the page dynamically is a no brainer.
In defense of the PHP community, things like Symfony attempt to create some sanity when it comes to separation of concerns. Unfortunately, when people talk about PHP they inevitably talk about raw, framework less PHP and act like it's as sensible as something structured and disciplined like Ruby on Rails or ASP.NET MVC.
> PHP mixed with HTML was one of the "bad ideas" that hurt PHP. It was a bad practice that got out of hand.
So what, JSPs are just the same. In the end what matters is the speed to Get Things Done, and there's utterly nothing competing with PHP, closely followed by Tomcat+JSP as you can use the insane amount of interfaces with just about everything that the Java world has.
So what, JSPs are just the same. In the end what matters is the speed to Get Things Done, and there's utterly nothing competing with PHP, closely followed by Tomcat+JSP as you can use the insane amount of interfaces with just about everything that the Java world has.
> PHP mixed with HTML was one of the "bad ideas" that hurt PHP. It was a bad practice that got out of hand.
PHP receives its share of criticism, and HTML lives on relatively unscathed.
So if mixing PHP/HTML is a problem, you'd probably throw out the PHP and keep the HTML.
Also, isn't this use case PHP's origin? A dev wanted some programmable HTML?
PHP receives its share of criticism, and HTML lives on relatively unscathed.
So if mixing PHP/HTML is a problem, you'd probably throw out the PHP and keep the HTML.
Also, isn't this use case PHP's origin? A dev wanted some programmable HTML?
> Now why no one bats an eye at node/react doing this very thing and calling it JSX is beyond me but...
Because it's not "this very thing". HTML around PHP is output directly to stdout. JSX is just syntax for literals.
Because it's not "this very thing". HTML around PHP is output directly to stdout. JSX is just syntax for literals.
> PHP mixed with HTML was one of the "bad ideas" that hurt PHP. It was a bad practice that got out of hand.
If you think of PHP as prototype-only, mixing tags and HTML is very convenient, like it is with the other thousand templating tools. And obviously it's more a problem of XSS through badly sanitized inputs more than the mix in itself, blah blah blah
It's PHP in production a bad practice that got out of hand.
If you think of PHP as prototype-only, mixing tags and HTML is very convenient, like it is with the other thousand templating tools. And obviously it's more a problem of XSS through badly sanitized inputs more than the mix in itself, blah blah blah
It's PHP in production a bad practice that got out of hand.
You're getting downvotes, but that genuinely puzzled me the first time I saw JSX. ("This looks a lot like 'include("form.php")' in old-school PHP. What am I missing?")
Turns out I wasn't missing much. I've mentally pegged it as an example of "the pendulum swings" - thin client vs thick client, centre vs edge, tight coupling vs loose coupling, etc.
Turns out I wasn't missing much. I've mentally pegged it as an example of "the pendulum swings" - thin client vs thick client, centre vs edge, tight coupling vs loose coupling, etc.
Discerning developers avoid PHP for the reasons you mention, and yet it powers a frightening percentage of the Web.
React is popular for the same reason as PHP. I can only hope the industry corrects for this soon, because I challenge you to find a startup building raw PHP in 2024, yet nearly all of them build with React.
React is popular for the same reason as PHP. I can only hope the industry corrects for this soon, because I challenge you to find a startup building raw PHP in 2024, yet nearly all of them build with React.
Any online resources you used to get yourself on the right track or as a starting point to get running?
Try running through https://bootcamp.laravel.com/blade/installation if you've never worked with PHP at all before, and want to see what modern PHP feels like.
Thanks!
In a lot of ways, PHP represents developer productivity maximalism. It's neither pretty nor safe, but there is a lot that other communities could learn by studying popular PHP libraries.
It is powerful indeed. But PHP syntax feels unelegant and making me write unnecessary ceremony. It feels different when I write typescript code, every character I type fits like lego.
Especially when my codebase grows so much. Navigating PHP project is like thrown in forest without a map, you can always look up the sun to find your way.
Especially when my codebase grows so much. Navigating PHP project is like thrown in forest without a map, you can always look up the sun to find your way.
Loved this article, those were all great points that I have faced on my daily job at a PHP shop.
A breath of fresh air in amids of thousands of "ew, such a bad language" and "a fractal of bad design", the latter being incredibly outdated and still referenced from time to time.
I love PHP, it was my first language and it's one hell of a productive ecosystem to be in. Laravel is an excellent choice for rapid prototyping and Symfony is probably one of the best web frameworks for enterprise projects. Paired with coroutines extensions such as Swoole/OpenSwoole/Swow it puts one hell of a fight performance wise with more modern languages.
A breath of fresh air in amids of thousands of "ew, such a bad language" and "a fractal of bad design", the latter being incredibly outdated and still referenced from time to time.
I love PHP, it was my first language and it's one hell of a productive ecosystem to be in. Laravel is an excellent choice for rapid prototyping and Symfony is probably one of the best web frameworks for enterprise projects. Paired with coroutines extensions such as Swoole/OpenSwoole/Swow it puts one hell of a fight performance wise with more modern languages.
I agree.
Also Laravel is one of the best web frameworks for rapid prototyping :)
Indeed.
Also, I have been looking for GraphQL implementations for other server-side languages recently and I have yet to encounter a schema-first implementation that comes close to what the Lighthouse layer for Laravel can do.
That is really productive.
Also, I have been looking for GraphQL implementations for other server-side languages recently and I have yet to encounter a schema-first implementation that comes close to what the Lighthouse layer for Laravel can do.
That is really productive.
Why would you want to use graphql? In my experience, it’s pretty terrible for real-world use-cases.
Lighthouse is sophisticated and productive. I only use it in fully-authenticated contexts but because it is schema-first with good ORM bindings and excellent annotation support, I barely write any logic that isn't a mutation, an accessor or a permissions gate. The occasional top-level query resolver. Beyond that it is the graphql schema and the models.
And it gives me the opportunity to separate out the front end concerns in a way I could explain to someone else.
Apollo has been a bit of a pickle on the front-end, mind you. That's a decision I'd revisit.
But generally it has meant a flexible API interface and leads to nice low latency UIs.
Check it out:
https://lighthouse-php.com
And these really good third-party auth mutations for Passport:
https://lighthouse-php-auth.com
And it gives me the opportunity to separate out the front end concerns in a way I could explain to someone else.
Apollo has been a bit of a pickle on the front-end, mind you. That's a decision I'd revisit.
But generally it has meant a flexible API interface and leads to nice low latency UIs.
Check it out:
https://lighthouse-php.com
And these really good third-party auth mutations for Passport:
https://lighthouse-php-auth.com
Funny, my opinion of Apollo on the front end is that it's the bees knees (specifically vue-apollo using the composition API), but it's the PHP graphql backend that I'm stuck with (Symfony API Platform) that I really wish I could ditch in favor of something like Lighthouse.
And I _hate_ Eloquent, but I'm that jealous of all the goodies in Lighthouse's graphql dialect. You pretty much can't use directives at all in API Platform :(
And I _hate_ Eloquent, but I'm that jealous of all the goodies in Lighthouse's graphql dialect. You pretty much can't use directives at all in API Platform :(
Ah cool! I hadn't seen this before!
I'd only seen fairly raw GraphQL from like 4-5 years ago, when you had to write your own auth, resolvers, deal with n+1 queries, etc. This is actually really nice and solves a lot of the issues I was thinking of.
I'd only seen fairly raw GraphQL from like 4-5 years ago, when you had to write your own auth, resolvers, deal with n+1 queries, etc. This is actually really nice and solves a lot of the issues I was thinking of.
Right. People keep telling me that code-first is better but there is no way all those complex APIs are easier to use than just spitting out some JSON from an endpoint.
Schema-first feels more manageable.
I'm not going to say I haven't had to do that a _bit_ here, when I've got into quite advanced things.
(e.g. sometimes you might want to dynamically provide the values from an enum, or write your own decorators, or you might want a custom top-level resolver.)
It's built on the WebOnyx reference implementation, so there's some help out there.
But it's amazing how much code I haven't had to write, and being the sort of person I am with difficulties controlling focus, I absolutely love the schema-first approach. It interacts well with Eloquent scopes, with the ordinary API gate system, with policies and validations.
It's actually weird how good it is. You still have all the same issues you have with GraphQL generally (like limiting graph traversals to things a user is authorized to see), but you have so many tools.
Schema-first feels more manageable.
I'm not going to say I haven't had to do that a _bit_ here, when I've got into quite advanced things.
(e.g. sometimes you might want to dynamically provide the values from an enum, or write your own decorators, or you might want a custom top-level resolver.)
It's built on the WebOnyx reference implementation, so there's some help out there.
But it's amazing how much code I haven't had to write, and being the sort of person I am with difficulties controlling focus, I absolutely love the schema-first approach. It interacts well with Eloquent scopes, with the ordinary API gate system, with policies and validations.
It's actually weird how good it is. You still have all the same issues you have with GraphQL generally (like limiting graph traversals to things a user is authorized to see), but you have so many tools.
Another nice thing about schema-first is that clients can start interacting with a mock server from day-0, and both sides can build out the implementation independently according to the spec. It really speeds things up on larger projects (IMHO).
Working on FrankenPHP, we get a lot of issues from the Laravel people (mostly in regards to octane + worker mode), and I've been getting into more and more Laravel to support these folks and understand what is going on in the SAPI. I've really started to understand the attraction lately. Previously, I worked at Automattic for quite a while and learned the WordPress side of PHP, then worked with Symfony in a corporate setting, so I've yet to get into Laravel in the commercial world, but I'm thinking I probably will for my next job.
Working on FrankenPHP, we get a lot of issues from the Laravel people (mostly in regards to octane + worker mode), and I've been getting into more and more Laravel to support these folks and understand what is going on in the SAPI. I've really started to understand the attraction lately. Previously, I worked at Automattic for quite a while and learned the WordPress side of PHP, then worked with Symfony in a corporate setting, so I've yet to get into Laravel in the commercial world, but I'm thinking I probably will for my next job.
Also: I have removed the little bit of snark in my reply above -- it shouldn't have been there and I apologise. Rough brain-day making me jumpy but there's no excuse!
Dude. We've all been there, no offense taken. I probably could have taken a few seconds to explain my experience instead of just assuming everyone else has had the same experience.
have a look to http://strawberry.rocks for Python.
I've still to find a better code first implementation too
I've still to find a better code first implementation too
This is one I did look at and then forgot about -- thanks!
Huh? This article is talking about very similar issue to the fractal of bad design. Down to repeating specific ones like json_decode(null). Most of the fractal post still applies. The themes of surprises and consistency are strong in both.
I agree that the language evolved since then, but the main categories are still not solved in the language. Nice frameworks just hide those well.
I agree that the language evolved since then, but the main categories are still not solved in the language. Nice frameworks just hide those well.
The thing that I think PHP developers hate most about the Fractal of Bad Design article is hearing it from full-stack JS developers. They really do not have the moral high ground.
PHP has improved since in a way that is rarely considered when reposting it, but JS has some deep language horrors of its own still, and many novel JS horrors like NPM have emerged largely since the Fractal article was published.
As the King sang, so eloquently: o/~ clean up your own backyard o/~
PHP has improved since in a way that is rarely considered when reposting it, but JS has some deep language horrors of its own still, and many novel JS horrors like NPM have emerged largely since the Fractal article was published.
As the King sang, so eloquently: o/~ clean up your own backyard o/~
As someone who writes PHP and JS professionally every day, I think they're leagues apart.* Sure, people love to look down on JS, but its fundamentals are much stronger than PHP's.
PHP is no longer a terrible language- recent editions have made leaps and bounds on language features, and the ecosystem around Symfony is great. But on a weekly or monthly basis I run into something that makes me want to head-desk.
JS's recent(ish) language improvements like `let` and ESM have been much more fundamentally significant than PHP's IMO, where we're still stuck with bad scoping and Java-brained class autoloading.
*Not leagues apart in terms of productivity. I can certainly get a lot done with PHP. I mean leagues apart at their foundation, the basic concepts at work in the language. Most of that can be ignored until it rears up to harass you. Here's a great example of something similar to an issue that bit me last month:
https://stackoverflow.com/q/3307409
PHP is no longer a terrible language- recent editions have made leaps and bounds on language features, and the ecosystem around Symfony is great. But on a weekly or monthly basis I run into something that makes me want to head-desk.
JS's recent(ish) language improvements like `let` and ESM have been much more fundamentally significant than PHP's IMO, where we're still stuck with bad scoping and Java-brained class autoloading.
*Not leagues apart in terms of productivity. I can certainly get a lot done with PHP. I mean leagues apart at their foundation, the basic concepts at work in the language. Most of that can be ignored until it rears up to harass you. Here's a great example of something similar to an issue that bit me last month:
https://stackoverflow.com/q/3307409
> As someone who writes PHP and JS professionally every day, I think they're leagues apart.
As someone who’s written a lot of php and JavaScript, I think the same thing but in the opposite way. JavaScript just can’t compare when it comes to designing a complex OO system.
As someone who’s written a lot of php and JavaScript, I think the same thing but in the opposite way. JavaScript just can’t compare when it comes to designing a complex OO system.
I actually think the opposite is the case. let is nice, but javascript has no typing whatsoever. The PHP type system isn't perfect (with a lack of generics being the biggest pain point), but in javascript you just have to annotate and pray (or use typescript and compile it back to javascript, hoping people interface with your code correctly). And PHP has a dedicated string concatenation operator, which has helped it avoid horrors like '2' + 2 = 22 that javascript has to offer. Javascript will just straight up let you add properties to any object on purpose or by accident, which is useful for polyfills but also fucking horrible for bug avoidance and an invitation for less restrained individuals to make true abominations.
All of those things I see as productivity issues, not language fundamentals. TypeScript solves types in JS for me the way Laravel solves superglobals in PHP.
Adding properties to an object is fine IMO. Arbitrary properties and prototypes are, to me, a much cleaner system than PHP's somewhat confused mix of array, object and class. The lower you go in JS the more unity of concepts there is, whereas the lower you go in PHP the more hacks you discover.
All of the above said, I would prefer a string concatenation operator to overloading +. JS template literals mostly solve that for me in practise. And what I really actually want is an equivalent of Haskell's <> or mconcat, which concatenates anything monoidal - strings, lists, etc.
Adding properties to an object is fine IMO. Arbitrary properties and prototypes are, to me, a much cleaner system than PHP's somewhat confused mix of array, object and class. The lower you go in JS the more unity of concepts there is, whereas the lower you go in PHP the more hacks you discover.
All of the above said, I would prefer a string concatenation operator to overloading +. JS template literals mostly solve that for me in practise. And what I really actually want is an equivalent of Haskell's <> or mconcat, which concatenates anything monoidal - strings, lists, etc.
In php 8.3, there is a new json_validate function! Stuff changes, it just takes a bit of time. Luckily, the core maintainers have been putting out steady releases every year and old versions are being deprecated on a rolling 3 year cycle. It doesn't solve the historical problem, but hopefully it enforces better habits for the ecosystem moving forward.
Nitpicking on trivialities is pointless.
Rather, point out the fact that Symfony is a framework that relies entirely on all sorts of magic behavior, and at the same time it is entirely undocumented.
One of the most horrible programming experiences I've ever experienced.
PHP is a nice language, but the community is insane.
Rather, point out the fact that Symfony is a framework that relies entirely on all sorts of magic behavior, and at the same time it is entirely undocumented.
One of the most horrible programming experiences I've ever experienced.
PHP is a nice language, but the community is insane.
Just out of curiosity, when was the last time you worked with Symfony?
The framework has changed massively after the earliest versions (1~3). These days it's very similar to Java's SpringBoot. After scaffolding all you get is a thin layer with the HTTP abstraction, configuration support, reflection-based Dependency Injection and a testing framework (PHPUnit).
Since the framework is component-based you pull dependencies as you need them. I find the documentation really good and honestly I don't see much magic in it, it's an event-based web framework. Laravel and it's facades on the other hand is very magical.
The framework has changed massively after the earliest versions (1~3). These days it's very similar to Java's SpringBoot. After scaffolding all you get is a thin layer with the HTTP abstraction, configuration support, reflection-based Dependency Injection and a testing framework (PHPUnit).
Since the framework is component-based you pull dependencies as you need them. I find the documentation really good and honestly I don't see much magic in it, it's an event-based web framework. Laravel and it's facades on the other hand is very magical.
Symfony is not great, but most people utterly misuse it so you end up with spaghetti and ground mud. That being said, Symfony is the most popular framework I know of that liberally uses goto statements.
I haven't worked very much with Symfony but I've never seen a goto. In fact, the last time I've seen a goto statement was maybe 15 years ago in a mIRC script.
Where are those goto statements? I'm asking out of curiosity to check them.
Where are those goto statements? I'm asking out of curiosity to check them.
The nice thing with GitHub, is that it’s literally a search away:
https://github.com/search?q=repo%3Asymfony%2Fsymfony+goto&ty...
I highly recommend learning how to use it.
https://github.com/search?q=repo%3Asymfony%2Fsymfony+goto&ty...
I highly recommend learning how to use it.
> These days it's very similar to Java's SpringBoot.
That's not a positive. Spring Boot is impossible to use for anything except an unmaintainable abomination, since the whole thing runs on undocumented magic.
That's not a positive. Spring Boot is impossible to use for anything except an unmaintainable abomination, since the whole thing runs on undocumented magic.
It is actually documented, surely you must be confused?
You have the docs with extensive examples, you have a free book, and the whole framework is typed and all configuration options and the individual components referenced: https://symfony.com/doc/current/index.html
And if you use PhpStorm with the Symfony plugin almost everything gets intellisense.
You have the docs with extensive examples, you have a free book, and the whole framework is typed and all configuration options and the individual components referenced: https://symfony.com/doc/current/index.html
And if you use PhpStorm with the Symfony plugin almost everything gets intellisense.
I don't use PhpStorm.
Also, random code snippets that may or may not work is not documentation, much less is it a reference.
Also, random code snippets that may or may not work is not documentation, much less is it a reference.
I don't get it, what more from the docs do you need?
I think his complaint is that a lot of the Symfony docs don't simply say what things are/do, they instead inform via examples. Which means you have to parse the examples first to understand what's going on.
Yes, "documentation" implies a curated and complete reference, not a collection of code snippets that may or may not apply to your current problem and version of Symfony.
(No, random posts oт Stackoverflow and generative AI responses aren't a replacement for documentation either.)
(No, random posts oт Stackoverflow and generative AI responses aren't a replacement for documentation either.)
But ... there is all that, right there on the documentation page, just ... scroll?
https://symfony.com/doc/current/index.html
https://symfony.com/doc/current/index.html
Honestly I don't see it that way.
The blog author makes solid points that I agree. Meanwhile AFOBD just make fun of stdlib inconsistencies and of language quirks, most of which were fixed throughout the years.
AFOBD is so incredibly outdated that this paragraph is still there: "PHP is naturally tied to Apache. Running it separately, or with any other webserver, requires just as much mucking around (possibly more) as deploying any other language.".
The blog author makes solid points that I agree. Meanwhile AFOBD just make fun of stdlib inconsistencies and of language quirks, most of which were fixed throughout the years.
AFOBD is so incredibly outdated that this paragraph is still there: "PHP is naturally tied to Apache. Running it separately, or with any other webserver, requires just as much mucking around (possibly more) as deploying any other language.".
Some of the points are outdated, but the soul of the article, that those stdlib inconsistencies and language quirks as you called it, lead to terrible design and a lot of surprising footguns, is still quite true. Laravel is a good framework and it is because it hides a lot of PHP from the user.
I see the advancements in php and I think I could go back by now but I know that 90% of comapnies recruit you to fix some wordpress 4/php 5 bugy and custom plugin infested site that should just be made from scratch but because there is no money and "just quickly fix it in 1 workday" gives me php ptsd once again.
This is absolutely a problem.
It's now a powerful, fast, flexible platform with a load of amazing libraries and tools -- graphql, webhooks, databases, all sorts. There's an amazing level of recent PHP support out there you can host on.
And then there are the terrible applications, written from inadequate specs, in a hurry, by people who just aren't developers. And they are embedded, and people want them fixed.
You have to have a knack for, and some enjoyment from, that work.
The worst I have encountered is a Wordpress site built by some people who did not know Wordpress could do several important things, so they'd subverted the loop, ignored where they could hook, and embedded wordpress outside the loop to do stuff, which was a nightmare.
The second worst was, it must be said, a Laravel app, but that problem wasn't the PHP so much (though it had been written in a hurry with an awful lot of duplication that we could have refactored out), it was the unreliable assumptions made about MySQL default result ordering.
Which is actually the secondary problem here: people who make bad PHP decisions usually make bad SQL, email and HTTP decisions too.
If building your own thing from scratch, or starting a new project, etc., PHP is a blast now, actually. But the very old things... not so much.
It's now a powerful, fast, flexible platform with a load of amazing libraries and tools -- graphql, webhooks, databases, all sorts. There's an amazing level of recent PHP support out there you can host on.
And then there are the terrible applications, written from inadequate specs, in a hurry, by people who just aren't developers. And they are embedded, and people want them fixed.
You have to have a knack for, and some enjoyment from, that work.
The worst I have encountered is a Wordpress site built by some people who did not know Wordpress could do several important things, so they'd subverted the loop, ignored where they could hook, and embedded wordpress outside the loop to do stuff, which was a nightmare.
The second worst was, it must be said, a Laravel app, but that problem wasn't the PHP so much (though it had been written in a hurry with an awful lot of duplication that we could have refactored out), it was the unreliable assumptions made about MySQL default result ordering.
Which is actually the secondary problem here: people who make bad PHP decisions usually make bad SQL, email and HTTP decisions too.
If building your own thing from scratch, or starting a new project, etc., PHP is a blast now, actually. But the very old things... not so much.
Yes, back in the "old days" of PHP you could ignore ordering and grouping on MySQL and it would pretty reliably give you back things in a stable "order of insertion" order where there was ambiguity.
Of course that was never guaranteed and subsequent optimizations and changes have really removed that ability to ignore order in many situations. Plus, MySQL also changed to actually check if you're doing GROUP BY properly by default.
MySQL was always a big part of the PHP story so it's fitting they've followed similar arcs of improvement and growing pains over the years.
Of course that was never guaranteed and subsequent optimizations and changes have really removed that ability to ignore order in many situations. Plus, MySQL also changed to actually check if you're doing GROUP BY properly by default.
MySQL was always a big part of the PHP story so it's fitting they've followed similar arcs of improvement and growing pains over the years.
PHP is probably like Excel, in that is is really helpful from a raw productivity standpoint to be good at it, but you really don't want other people to know that you're good at it.
IME, that also makes PHP worth it for shell scripts. It's miles better than the common baseline that's bash/perl... but once word gets out, people will ask you to rewrite their 30 kLOC sh monstrum into something readable...
Mmm. It really depends on whether you have the scope to start your projects and stay in control.
idk, when I want productivity I go with nodejs these days. lodash for some quick data crunching and pg or mariadb for db access using promises simply beats native php functions. with express you can spawn a http server in under 10 lines, while with php you need to setup apache/nginx or docker.
at some point in the past PHP was the most productive tool for some quick & dirty coding, but not anymore for me.
at some point in the past PHP was the most productive tool for some quick & dirty coding, but not anymore for me.
I recommend checking out FrankenPHP, where you can spin up a production php server with a single cli command, or compile your php into a self-executable binary.
I’m a contributor over there.
I’m a contributor over there.
Not my experience. You will see some legacy code but that is to be expected in any coding job.
Wordpress is kind of it's own ecosystem. I have been a PHP dev for years and never touched any Wordpress code.
Most jobs recruit for specific frameworks like symfony or laravel.
Wordpress is kind of it's own ecosystem. I have been a PHP dev for years and never touched any Wordpress code.
Most jobs recruit for specific frameworks like symfony or laravel.
I might be a minority, but i truly enjoy PHPs syntax a lot. No other language i use gives me the same joy.
Modern PHP is great, the past & some fundamental decisions are automatic tech debt that i can live with. It'd be great if PHP 8.3 gets forked with no backward compatibility, removing all the old PHP as a template engine designed functions that nobody needs & release under a new name. I just can't find the same type of joy in writing code as i do when writing PHP. But some things are truly annoying. Just not enough for me to switch or start the fork myself.
Modern PHP is great, the past & some fundamental decisions are automatic tech debt that i can live with. It'd be great if PHP 8.3 gets forked with no backward compatibility, removing all the old PHP as a template engine designed functions that nobody needs & release under a new name. I just can't find the same type of joy in writing code as i do when writing PHP. But some things are truly annoying. Just not enough for me to switch or start the fork myself.
On a few occasions I've done a few weeks of refactoring the php source toward creating just such a fork, but decided it was just going to be too much work over time for too little benefit for too few people. And that's true of pretty much all "legacy-free" forks: it's fun to rip out all the legacy crap, but you're left with an incompatible language in the end, at which point you're probably better off starting with a different language entirely.
Anything of your refactorings public to check out?
> but you're left with an incompatible language in the end, at which point you're probably better off starting with a different language entirely.
Yes, but which one?
No matter which one i try, in the end, i am always close to rewriting it with php. Eg as many good things go has, i don't enjoy the syntax as much as phps. I could live with it, given the advantages. But i can't get over it, that most of my code seems to be error checking. Sure, that's probably a good thing for serious work. But that's just not where the joy in programming lies for me. Most cases phps try-catch feels much, much more elegant / fun to write (not comparing the efficiency of the outcome).
I do love the fact i end up with a single executable. And php without framework requires much more overhead, which is also annoying. And i am done with php frameworks.
> but you're left with an incompatible language in the end, at which point you're probably better off starting with a different language entirely.
Yes, but which one?
No matter which one i try, in the end, i am always close to rewriting it with php. Eg as many good things go has, i don't enjoy the syntax as much as phps. I could live with it, given the advantages. But i can't get over it, that most of my code seems to be error checking. Sure, that's probably a good thing for serious work. But that's just not where the joy in programming lies for me. Most cases phps try-catch feels much, much more elegant / fun to write (not comparing the efficiency of the outcome).
I do love the fact i end up with a single executable. And php without framework requires much more overhead, which is also annoying. And i am done with php frameworks.
I'm afraid I burned it down to the ground, but the last attempt never got me much past reorganizing the headers and ripping out ifdefs for all non-posix systems (bye bye windows support). These days I'm interested in more green-field languages like unison, though I'm still trying to think of something to write in it (or any inspiring language, really).
Interesting. I haven't even heard about unison. Just skimmed the website and it looks interesting. Thanks for mentioning it!
This is a bit too much of an apples vs oranges. Use cases for PHP (easy to develop, maintain websites) are different from those for Go and Rust.
Obviously, PHP came from a place of great inconsistency, and the remains are still there, including the popularity to rant on it. PHP is getting significantly better though, and while a long one, I hugely prefer this route over something more abrupt like python 2-3. The first 3 or so points are valid, but annoyances at best. For the points about closures, statements, inline classes etc., they are just features from other languages that aren't in PHP.
Obviously, PHP came from a place of great inconsistency, and the remains are still there, including the popularity to rant on it. PHP is getting significantly better though, and while a long one, I hugely prefer this route over something more abrupt like python 2-3. The first 3 or so points are valid, but annoyances at best. For the points about closures, statements, inline classes etc., they are just features from other languages that aren't in PHP.
PHP buttered my bread for over a decade. I bear it no ill will, and this article was a lot of nostalgia.
The "living on a prayer" comment on serialization brought back memories. It made me acutely aware that I use this pattern in go, and there it "just works". I now have a note to go see what Valinor, PHPStan, Psalm, Serde are because they sound godlike.
The "living on a prayer" comment on serialization brought back memories. It made me acutely aware that I use this pattern in go, and there it "just works". I now have a note to go see what Valinor, PHPStan, Psalm, Serde are because they sound godlike.
I still have contracts in Cold Fusion. PHP is not remotely the worst web templating language out there in active use...
Good for PHP that it's getting more and more traction (attention) lately. Bad press is still press & PHP is quite not bad nowadays, when you start from scratch.
I've been working with PHP for the last couple months or so for the first time in over a decade. I can't say I've enjoyed it. Feels very tedious always having to look up, say, whether the needle comes first or the haystack in a list of arguments. But it runs pretty darn fast, I'll give it that.
Many editors have tools that show language functions and their parameters as you type, so you don't have to subject yourself to that tedium if you don't want.
Oh agree as a daily php writer. The core libs are all over the place for arguments. Doing something that's so elegant in perl results in a mishmash of weird array rules, too helpful built-ins that act weird like isset
It's one way for string functions and the other way for array functions. I have a little post-it on my monitor for it.
> This is a subjective post about things that annoy me, some of the points are invalid and for sure people with far more context and brain power than I have have considered them. It is also to be expected that I take for granted things that would annoy other people.
Great disclaimer, since most of the points raised in this article seem very nitpicky to me. This is understandable considering that OP's PHP work is about creating a language server and some benchmarking tool, both of which are definitely not the main use-case for this language. I bet your average PHP dev has no idea about the things mentioned in this article, nor are they interested in improving them.
Great disclaimer, since most of the points raised in this article seem very nitpicky to me. This is understandable considering that OP's PHP work is about creating a language server and some benchmarking tool, both of which are definitely not the main use-case for this language. I bet your average PHP dev has no idea about the things mentioned in this article, nor are they interested in improving them.
I work on the same team as the author. I appreciate PHP in general, particularly because it contributes significantly to covering expenses (earning a six-figure income in Europe). While there is undoubtedly room for improvement in the language, this post highlights some valid points that we encounter in our day-to-day work on the 'large E-Commerce project' briefly mentioned at the beginning.
I hope that discussions like these raise awareness within the PHP community and eventually lead to solutions. Considering the impressive initiatives the PHP foundation has recently undertaken, I am confident that the language is evolving in the right direction.
Certainly, there are still individuals in the PHP world who may not grasp the essence of this post. In some tech interviews, I've encountered people stating that they 'don't know PHP, only Laravel.' I don't oppose Laravel (or WordPress or any other framework); I just want to emphasize that some individuals may not appreciate the underlying technology. Reflecting on my early days of programming, there was a tendency to exclusively focus on learning jQuery, neglecting the importance of understanding JavaScript.
I hope that discussions like these raise awareness within the PHP community and eventually lead to solutions. Considering the impressive initiatives the PHP foundation has recently undertaken, I am confident that the language is evolving in the right direction.
Certainly, there are still individuals in the PHP world who may not grasp the essence of this post. In some tech interviews, I've encountered people stating that they 'don't know PHP, only Laravel.' I don't oppose Laravel (or WordPress or any other framework); I just want to emphasize that some individuals may not appreciate the underlying technology. Reflecting on my early days of programming, there was a tendency to exclusively focus on learning jQuery, neglecting the importance of understanding JavaScript.
[deleted]
I just launched an app that I've been using with my friends to collect and share memes. PHP on the backend and vanilla JS on the front end. Made a PWA out of the thing with some manifest and now I have something that I'm really proud of, that was put together in one week. If I see a funny meme I can just share it with my PWA and it will post it for me.
I'd love PHP to have proper primitives for working with binary data / buffers. You still have to use strings for that. Those strings are immutable, so performance will suffer.
In JS, there are pretty decent APIs for that. Just copy them, they work good. There is an extension, but you have to build it from source and doesn't cover all of it.
Same goes for container data types. All you've got is array. No sets, no hashmaps, ordered sets, sorted sets. Array is just all of this at the same time. There's also an extension for that, but its API is... not optimal. I wonder how much faster some programs could be if the array wasn't used as the universal data type.
If one could use composer to install PHP extensions, that would be awesome. I fiddled around with WASM as a language for universal PHP extensions that can be loaded via composer, but there does not seem to be a lot yet.
Same goes for container data types. All you've got is array. No sets, no hashmaps, ordered sets, sorted sets. Array is just all of this at the same time. There's also an extension for that, but its API is... not optimal. I wonder how much faster some programs could be if the array wasn't used as the universal data type.
If one could use composer to install PHP extensions, that would be awesome. I fiddled around with WASM as a language for universal PHP extensions that can be loaded via composer, but there does not seem to be a lot yet.
The beauty of PHP is that you're always seeing $$$ signs
For "functions that return false", use thecodingmachine/safe which wraps those nasty builtins with ones that throw exceptions. PHP's gotten a lot better lately, but it's always going to need library fixes like that for its awful legacy builtins.
I like this library and promote that wherever I can, but the safe library was even mentioned in the post:
> I love the smell of false in the morning, but despite that I do wish that all PHP’s built-in functions threw exceptions. We have the famous safe library which does just that! But if you’re like me then you don’t like coupling huge amounts of code in perpetuity to an external library.
> I love the smell of false in the morning, but despite that I do wish that all PHP’s built-in functions threw exceptions. We have the famous safe library which does just that! But if you’re like me then you don’t like coupling huge amounts of code in perpetuity to an external library.
I just wrap the ones I actually need that for and put them in traits (sometimes multiple related per trait). So it's internal, small footprint, and really needs 0 maintenance. This is also good for e.g. json_* when you want to provide app-wide defaults.
Ah, I'd completely missed that. As for depending on an external library ... get used to it. Writing PHP without any external deps is strictly for one-off scripts -- and rarely even then.
The first point is kind of silly: You can make rust-style constructor functions if you want, and have a private constructor to enforce the behavior.
Although it does require some boilerplate, which may seem like pointless extra work.
Although it does require some boilerplate, which may seem like pointless extra work.
I think this was not the point, see:
> [...] only to realise there the class has a private constructor or that there are static constructors which I should be using [...]
> [...] only to realise there the class has a private constructor or that there are static constructors which I should be using [...]
“Langauges such as Rust and Go do not have this problem, mainly because they don’t have the new keyword!”
Oh but they do. You should spend some time with those languages so you can do a proper comparison.
Go has had new for a while now.
Oh but they do. You should spend some time with those languages so you can do a proper comparison.
Go has had new for a while now.
Go may (also in my understanding, it's not actually a keyword, but close enough?), but Rust does not.
Oh, excuse me, Box::new :D. At least in rust it’s an explicit method call instead of implicit.
but it's a convention right ? there's nothing special about `new` IIRC
Yeah, whether it’s explicit method call or an implicit macro, something is being called. A constructor, a new method, that’s what I was getting at. Saying you dislike the implicit new is valid because you can’t visually see the call where in rust you can. In go, we often take the NewFactory approach even though there’s a new. It’s easier just to return the reference knowing it will out live the stack call.
That's correct.
[deleted]
I respond to every point below.
In sum, the native functions should take iterators anywhere it can take arrays.
Every other valid criticism he makes and many more I can wrap in the simple statement that: psalm needs to become the runtime type system which is hopefully and appears to be the (maybe distant) future.
In the meantime you have 40% and quickly growing of those features in your IDE and 100% in your CI so it’s not a huge deal.
Main takeaway for people who haven’t looked at PHP in 10-15 years or since the fractal article and would take the length of this post, which they don’t understand, to say “yep dumb php again” no.
—————
Constructors Only had this confusion once with my UUID library and it took me 3 seconds to remember the formula.
"In attribute land this becomes:" I've never seen any code or library that uses attributes like this nor do I understand why you would. The only purpose would be static analysis, let's say with psalm, and that's just not how you use attributes in psalm. He says generics are tricky: in psalm they're trivial. The real problem is the best IDEs are still working on getting the integration right.
Nested attributes strikes me as an extreme edge case that would only come up in some meta-level tooling you're making for the language which is the provided example. However in this special case presumably this can be accomplished through an extension, xdebug for example does this.
Serialization he says is a problem then says, it's a solved problem (there are many such accepted ways to solve this) but then says it still annoys him so not sure?
"No Variadic Promoted Properties" I'd like to hear the use case for. I've done very complex things in PHP and never needed this construction. A property can't have a static single type but then also consist of a collection of random types, in this case it would just be an array. It looks like another feature that is solved by psalm.
Iterator to Array: Preserve Keys he says he doesn't know if it's wrong.
Iterators vs. Arrays this is easily fixed by using the popular Functional library versions of these functions which I agree should be the default.
Short closures cannot have statements" I have to convert between them so I kind of get it but would say this is an intentional choice. You can substitute a method call if you really want this.
"Statement Blocks in General" That would be nice when and if it's very simple though having them anywhere could turn the language into kind of a mess to read considering what those blocks could contain.
Functions that return false - basically everyone agrees on this, it's a conversion that's iterated on with each release and will just take time. The specific example he provides I have wrapped with an exception thrower for just this reason and never use the default.
Inline Classes - he says he doesn't know if it's a good idea. I'd say no, having a reliable file system convention between codebases is a plus not a minus.
In sum, the native functions should take iterators anywhere it can take arrays.
Every other valid criticism he makes and many more I can wrap in the simple statement that: psalm needs to become the runtime type system which is hopefully and appears to be the (maybe distant) future.
In the meantime you have 40% and quickly growing of those features in your IDE and 100% in your CI so it’s not a huge deal.
Main takeaway for people who haven’t looked at PHP in 10-15 years or since the fractal article and would take the length of this post, which they don’t understand, to say “yep dumb php again” no.
—————
Constructors Only had this confusion once with my UUID library and it took me 3 seconds to remember the formula.
"In attribute land this becomes:" I've never seen any code or library that uses attributes like this nor do I understand why you would. The only purpose would be static analysis, let's say with psalm, and that's just not how you use attributes in psalm. He says generics are tricky: in psalm they're trivial. The real problem is the best IDEs are still working on getting the integration right.
Nested attributes strikes me as an extreme edge case that would only come up in some meta-level tooling you're making for the language which is the provided example. However in this special case presumably this can be accomplished through an extension, xdebug for example does this.
Serialization he says is a problem then says, it's a solved problem (there are many such accepted ways to solve this) but then says it still annoys him so not sure?
"No Variadic Promoted Properties" I'd like to hear the use case for. I've done very complex things in PHP and never needed this construction. A property can't have a static single type but then also consist of a collection of random types, in this case it would just be an array. It looks like another feature that is solved by psalm.
Iterator to Array: Preserve Keys he says he doesn't know if it's wrong.
Iterators vs. Arrays this is easily fixed by using the popular Functional library versions of these functions which I agree should be the default.
Short closures cannot have statements" I have to convert between them so I kind of get it but would say this is an intentional choice. You can substitute a method call if you really want this.
"Statement Blocks in General" That would be nice when and if it's very simple though having them anywhere could turn the language into kind of a mess to read considering what those blocks could contain.
Functions that return false - basically everyone agrees on this, it's a conversion that's iterated on with each release and will just take time. The specific example he provides I have wrapped with an exception thrower for just this reason and never use the default.
Inline Classes - he says he doesn't know if it's a good idea. I'd say no, having a reliable file system convention between codebases is a plus not a minus.
I realize it's an opinion blog, but can't help but notice that the author insists on comparing local compiled languages with PHP, a primarily server side interpreted language. Your static compiled binary program will continue working after a system upgrade, but your mish-mash PHP is going to break probably once per year.
That said, I'll comment on the code style this author wants to use. It's flashy, confusing, and unnecessary. This person wants to show proficiency with the language by using all its features. That's not how you write good, readable code. Come up with some personal standards for yourself and stick to them. Stop mixing every possible style. You're increasing cognitive load.
Continuing on, you want to use all the latest features of the language. That's great, but why are you trying to skin the cat three different ways in the same program? Pick one way and forget the others. If you can't fit all your code into short closures the rest will look like shit and confuse everyone else. I see this all the time with JS guys mixing bracket and dot notation. I feel like there is probably medication that can help with that.
Then we get to the fact that you want everything to throw exceptions. Like file_get_contents. No. Just no. You're not supposed to rely on that function to tell you if the file is there. That's what file_exists does. If you've made it to file_get_contents and you don't know if the file is even there, you're doing PHP wrong. You can use that function with a URL and eval to execute remote code. You're not supposed to swing it around like a broken bottle.
That said, I'll comment on the code style this author wants to use. It's flashy, confusing, and unnecessary. This person wants to show proficiency with the language by using all its features. That's not how you write good, readable code. Come up with some personal standards for yourself and stick to them. Stop mixing every possible style. You're increasing cognitive load.
Continuing on, you want to use all the latest features of the language. That's great, but why are you trying to skin the cat three different ways in the same program? Pick one way and forget the others. If you can't fit all your code into short closures the rest will look like shit and confuse everyone else. I see this all the time with JS guys mixing bracket and dot notation. I feel like there is probably medication that can help with that.
Then we get to the fact that you want everything to throw exceptions. Like file_get_contents. No. Just no. You're not supposed to rely on that function to tell you if the file is there. That's what file_exists does. If you've made it to file_get_contents and you don't know if the file is even there, you're doing PHP wrong. You can use that function with a URL and eval to execute remote code. You're not supposed to swing it around like a broken bottle.
Going from zero to functional web backend in less than 3 hours for a language I'm almost totally unfamiliar with made me understand just why this got so gosh darn popular. I thought building out a Flask application was fast, but PHP's initial experimentation loop is just on another level, criticisms be what they may.