Recently got a freelance Wordpress job after like 10 years of inactivity in that segment, I was surprised by how good PHP has become. I am hoping that it'll continue in this direction.
I've used PHP since the early 2000's (I started with PHP 4, I think). The language has improved vastly since then. When combined with the Laravel framework, you've got a first-class platform for building web applications.
The point of php was to not be ”good”, but to be practical. A simple way to add some logic to html.
Write a few lines, upload it, boom it works. Quick and easy.
There is a place for typed & strict languages and a place for pragmatic ones.
But php got shamed for it so badly they got into an identity crisis, for the last decade it’s slowly been trying to become Java and do everything correct.
Same with Wordpress, before I could just make a plug-in with one php file & a few lines. Now I have to create a separate npm project and build for every tiny change
PHP got shamed for these things because people built complex, and over time unmaintainable, systems in it.
Mind you, the "old ways" still work - you can still write a few lines, upload it, boom it works. Projects around PHP might have developed different ways of working, but that's because of problems in the old way - and that's not a fault of PHP, it's a plus that things move in a more maintainable and type-safe direction. You even reap some benefits when doing a "write a few lines, upload it, boom it works" workflow.
That's not to say PHP isn't been overcomplicating itself & hasn't fully embraced why it's so succesfull and improved that part: it's easy & practical.
How can it be even easier? For instance even simpler hosting? With things like vercel, and app engine PHP isn't necessarily the simplest choice in hosting sites anymore.
> That's not to say PHP isn't been overcomplicating itself & hasn't fully embraced why it's so succesfull and improved that part: it's easy & practical.
Do you have specific examples for things where PHP has been overcomplicating itself? Most complex things seem to actually make things easier for newbies (e.g. typing can be a great help).
And as a legacy dev you can just ignore all of those new things. You do not have to use lavarel or any of the latest, greatest frameworks or features. Your code from 15years ago will just work as well.
You can still make a Wordpress plugin with one php file and a few lines? If you want an npm project and build chain you can have that, but you can absolutely still build a Wordpress plugin with a functions.php file and nothing else
The old way yes, but if you want to integrate with a block them you can't. The Gutenberg thing is overcomplicated, which is why it's not really taking off.
Gutenberg has been a nightmare from the beginning. Saving structured data into the post HTML field severely limited the benefits of migrating content into blocks. Last time I checked, getting block data via the REST API wasn't officially supported, so making a headless site requires extra plugins.
When you reach that point you may as well be using ACF, as it's so much simpler and doesn't require rebuilding frontend scripts anytime anything changes.
> But php got shamed for it so badly they got into an identity crisis, for the last decade it’s slowly been trying to become Java and do everything correct.
PHP was a dumpster fire. It's not "pragmatic" to have trivial SQL injections everywhere that are difficult for non-experts to fix. It isn't "pragmatic" to have user hostile error messages. It isn't "pragmatic" for different parts of your standard library to disagree about core design principles. It's a hundred different recipes from around the globe just thrown into a blender for a few seconds in the hope the result will be "fusion cuisine" when it's barely even food.
I wrote a whole bunch of PHP ~15 years ago for money, and before that I wrote some for the comedy site friends and I ran in the 1990s, I also had the misfortune of picking up a card in my scrum the other month where I had to modify some PHP. It's changed. It hasn't changed anywhere near enough to justify itself.
I would rate PHP3 era PHP as a 0/10 maybe just use static HTML instead, and modern PHP is maybe 3/10 where it's better but it's just not better enough to use if you could pick something else.
At that point, I ask myself whether it's possible to interface strongly-typed PHP with Java. Like, either a PHP frontend for JVMs (just like Kotlin and whatnot), or run Java code inside PHP in a run-and-throw-away model.
Almost everything but async/threads that I use in Java stuff has an 1:1 mapping.
In theory, it sounds pretty interesting. PHP's ethos is quite different though - e.g. PHP's "arrays for everything" vs Java's "specific types for every case". Also, the absence of generics in PHP is a huge difference.
At least the PHP-in-JVM side shouldn't be that complex to do then... a LinkedList<Object> should be enough to match PHP arrays functionally. The largest challenge in a PHP-in-JVM project probably would be re-implementing its large stdlib as a wrapper around native Java.
I think that's more a framework/library philosophy than anything else. When I dabbled with PHP + symfony, I worked with some of the most clean APIs I've seen to this date.
PHP core has very few datatypes. And many are really just Arrays. Not just "under the hood" but through public interfaces.
The best example to show this is that you can `foreach()` over an object. It wasn't a deliberate feature but rather an artifact of how objects are "syntactic sugar over Arrays" and how Arrays are really just hashtables.
And it becomes problematic with the many exceptions that all the functions operating on Arrays have. Almost all important functions' documentation (edit: on arrays) goes something like "if the array key is a string, it will act like X, if it is a number it will act like Y". With some going like "if one of the keys is a string it will X, otherwise it will Y". And Y and X being rather different in return values, errors and such.
I can understand that PHP has a really strong preference for strings - HTTP is only and all strings after all - but the mess around arrays is real, dangerous, and has bitten me, my companies and many of my clients many times over. For decades.
PHP was, and perhaps still is despite stiff competition from frameworks like Next.js, the ultimate backend-for-frontend (BFF) solution. It's a server-side, super-flexible layer ideal for connecting various components and delivering static HTML with JavaScript enhancements.
While there's nothing inherently wrong with using PHP for tasks Java already handles well, given Java's proficiency in its domain, it's not always necessary to replicate these functions in PHP.
However, there's a tendency to undervalue PHP-based applications, often labeled as 'home.php-style' apps. It's true they can become unwieldy and unmaintainable if not properly managed. Adhering to good practices is essential, but it's also important to remember not every project needs a complex solution like bootstrapping a Laravel project for a simple task list. Everything comes with its own set of trade-offs!
I think it just boils down to your dev pool. If you already have Java devs, why bother establishing PHP as a new language in your company? Certainly, you can't justify paying them less than your Java devs...
Let's face it, a major advantage of PHP nobody talks about is that devs are cheaper.
I don't mean this all in a bad way, I have seen PHP used in high quality code-bases for websites of medium sized companies. But you are limited to input/output operations. However, there is also an advantage to this, as the PHP devs I have seen are more prone to trying out new tools and not reinvent the wheel in source code.
Also, I want to shout out to the guys making Sulu CRM. Loved working with it, too bad it's PHP and symfony only.
You are technically right about changing files of course, but remember:
- PHP speed is all about caching. Changing a file means rebuilding (all) caches.
- PHP debugging is nothing worth bragging about. Java is way more powerful and the jvm supports runtime reload of methods as well.
This also goes together with the fact that most php devs are println devs (from what I have observed).
And then there are other things like maintenance of old php applications is a major headache because on mac old php versions just disappear in brew. And new PHP releases like to break A LOT.
Is relying on OS bundled PHP version really a thing? I have not once in my 12 years of working in this field experienced anyone relying on the default OS installation of PHP. Most PHP lives in shared hosting platforms that are managed, and needier apps in a VPS where the PHP is also set-up, or in Docker, where again, it's set up.
> the PHP devs I have seen are more prone to [...] not reinvent the wheel in source code*
I have the opposite experience:
Because PHP and package management is relatively new (Composer is from 2012, compared to CPAN's general availability in 1995), I haven't seen more wheel-reinventing than among PHP programmers.
Even the standard library seems to be reinventing its own wheels. I'm looking at you, mysql_real*_escape_string.
But then you'd have to write in largely untyped PHP (yes, I know PHP now has some types, but it's not the level of other languages) and not a better language like e.g. TypeScript or Rust.
The only missing thing about PHP types is generics (array<int> and similar) and non-explicit coercions, which can be fixed with `declare(strict_types=1)`. Other than that, all types checks are enforced at runtime, unlike Typescript.
It's not just having types, other libraries have to support them too. Python has type hints but some libraries support them while some don't. While this is true in TypeScript as well, the vast majority of the most used packages have TS types. And I also want my types to be checked at compile time, not runtime. For runtime, I'd just use Zod.
Doesn't TypeScript get compiled into JavaScript? I thought TSC actually does a compilation, hence the name, TypeScriptCompiler? But anyway, this also exists for PHP. Psalm (https://psalm.dev/) or PHPStan (https://github.com/phpstan/phpstan) both offer static type checking.
TS tries to keep syntax the same as JS. So tsc usually is just stripping types and, depending on settings, transpiling newer JS features to older versions.
Programming languages tend to fall on a spectrum of "whip-up-ability". The faster you can prototype in a language, the more god-awful spaghetti you can produce.
> However, there's a tendency to undervalue PHP-based applications
I don't think there's that. In every thread about PHP, many people come in to explain this (edit: this = how good PHP is for use-case X, or how good it is holding up). Every time.
"We" all know PHP has its very well-fitting sweet spot. Its use-cases where it shines.
I do think, though, that the list of use-cases and the size of the sweet spot is not as big as the usage of PHP makes it out to be.
What I mean is: there are many situations in which PHP is the best solution. But in many places where PHP is employed, it is not the best solution (anymore).
Being someone who spent a lot of time in the WordPress space and is building a pretty complex PHP app now, I think I see the whole movement of "server-side React" as a subset of developers doing everything they can to not learn PHP. I think I'd have more grace for them if they also didn't have multiple frameworks to not learn CSS. I know it's petty and I'm painting with a broad brush, but it can feel frustrating when so much of parts of web culture insist on using the same hammer instead of exploring the toolbox.
EDIT: All that to say, I get it, and for my part I'll try to tone it down. Thanks for listening to this old(er) guy rant.
Yes, I think there's a weakness, maybe especially with younger developers, to keep all development in just one language.
A current example for me is SQL vs ORMs. I feel like I'm more productive building SQL queries in my application (ideally using a query builder API), than using an ORM. Because SQL was created to be a language for manipulating relational data, and thus does the job better than the indirection introduced by an ORM framework.
Rails is a framework, PHP is a language. A more apt comparison would be Ruby vs PHP, or Rails and any number of PHP frameworks like Symfony, Laravel, etc.
I have asked many times why there are not more successful framework with the same design and execution model as PHP, but with a more popular programming language like Ruby or Python or, and never gotten a really satisfactory answer.
It indicates the namespace where Override exists, which in this case is root level. \Namespace\Class is how namespaces in PHP work. If no \ is specified, it assumes Override is in the same namespace as the class it is being used in, and it would thus fail because it isn't.
In almost any way. Sane data structures, a coherent namespaced stdlib etc etc. Like just how painful is it to do websockets in PHP? It requires all sorts of dependencies etc. PHP is just a mess with some lipstick, and to be honest it looks like they want PHP to be a Java clone.
How big are the performance gains? I've got a big block of legacy code so I'm not as interested in the new coding features. But if it brings better performance I'll install it.
Iirc PHP >= 7 brought huge performance gains out of the box, and for those that really need it you can do additional work like preloading static files (but that’s likely beyond your scope).
We've seen real change in rhetoric in web space. It seems like PHP (through Laravel in particular) is so back into being vogue. And that brings me joy.
HTMX, Laravel, Livewire, alphine.js are all the things that are what these insane JS SPA frameworks aren't. Simple and intuitive.
PHP doesn't care about the young coders' vogues. Just like SQL doesn't care about the NoSQL crap. It's still here and is going to be for the next few generations.
I was giving the major FE frameworks an honest try until they all started to move to server components. Blackpill moment. “Wait a minute…rendering HTML on the server…I THINK I’VE DONE THIS BEFORE (with a lot less boilerplate insanity)”
I'm a JS guy and I'm convinced this way of orchestrating the UI from the server is really the future of full stack dev.
At least to solve 80-90% of use cases. There are still some situations that require client side components with APIs but it's really a minority. Doesn't make sense to focus all your efforts into a complex solution that is appropriate for a minority of use cases.
Only ever seen it praised in these threads specifically about PHP on HN. Where everyone who uses it says how amazing it is, and oddly enough, has no negatives to talk about.
PHP doesn't have many negatives. Even the go-to negatives aren't really. Many cite "rebuilding the environment everytime" as a con, but it's a pro in terms of horizontal scaling/load balancing. I for one would like PHP to have generics. It doesn't have that and plausibly will never have it (without a superset like TypeScript for JS).
I coded php for years. Generally speaking, php teams (using smarty + composer) are faster. They don't have the ci/cd drama of java. PHP is made for the internet (unlike python) and is fast (unlike rails). It also doesn't suffer version drama (python2 vs python3).
I started using PHP for work back in the PHP 4 days when I started my career.
As I grew in my abilities, appreciation for more advanced OOP concepts, and stricter typing, so did PHP, we kind of evolved together over the years. However, I'd be hard pressed to choose PHP for a green field project today.
I wonder if I'd have just started off immediately using something like Java if I would have been as effective? Early PHP's sloppiness (paired with early javascript) gave me a lot of flexibility and allowed me to learn things more deeply.
I do lots of greenfield PHP these days, and honestly I don't see why people would not consider it. It's an extremely pragmatic language and ecosystem to ship things with. By the time I set up a Java project, I'd already have a WIP made with PHP. Modern PHP is strictly typed as well, and actually quite similar to Java, except much faster to actually make things with.
I started around PHP 4 as well, mostly as a hobby, and I think 5 was around the corner when I started really working in the field.
I’d take PHP for a new project in a heartbeat if the shoe fit. My last real PHP project was Laravel+Inertia+Vue and it was a really great workflow for me and my team.
PHP is so great. And there are many libraries that go far beyond just websites. What I miss are sole good libraries for NLP - especially for more languages than English.
Or do I just don't know them?
106 comments
[ 2.3 ms ] story [ 171 ms ] threadWrite a few lines, upload it, boom it works. Quick and easy.
There is a place for typed & strict languages and a place for pragmatic ones.
But php got shamed for it so badly they got into an identity crisis, for the last decade it’s slowly been trying to become Java and do everything correct.
Same with Wordpress, before I could just make a plug-in with one php file & a few lines. Now I have to create a separate npm project and build for every tiny change
Mind you, the "old ways" still work - you can still write a few lines, upload it, boom it works. Projects around PHP might have developed different ways of working, but that's because of problems in the old way - and that's not a fault of PHP, it's a plus that things move in a more maintainable and type-safe direction. You even reap some benefits when doing a "write a few lines, upload it, boom it works" workflow.
That's not to say PHP isn't been overcomplicating itself & hasn't fully embraced why it's so succesfull and improved that part: it's easy & practical.
How can it be even easier? For instance even simpler hosting? With things like vercel, and app engine PHP isn't necessarily the simplest choice in hosting sites anymore.
A Vercel for PHP would be awesome.
Do you have specific examples for things where PHP has been overcomplicating itself? Most complex things seem to actually make things easier for newbies (e.g. typing can be a great help).
Because it was very accessible for people to get into it without being you know, a 10 year programming veteran at least.
Now all those newbies are out creating 400 npm dependency projects heh
Sure. Wouldn't it be nice to allow these people to write better code without having to change their language?
When you reach that point you may as well be using ACF, as it's so much simpler and doesn't require rebuilding frontend scripts anytime anything changes.
PHP was a dumpster fire. It's not "pragmatic" to have trivial SQL injections everywhere that are difficult for non-experts to fix. It isn't "pragmatic" to have user hostile error messages. It isn't "pragmatic" for different parts of your standard library to disagree about core design principles. It's a hundred different recipes from around the globe just thrown into a blender for a few seconds in the hope the result will be "fusion cuisine" when it's barely even food.
I wrote a whole bunch of PHP ~15 years ago for money, and before that I wrote some for the comedy site friends and I ran in the 1990s, I also had the misfortune of picking up a card in my scrum the other month where I had to modify some PHP. It's changed. It hasn't changed anywhere near enough to justify itself.
I would rate PHP3 era PHP as a 0/10 maybe just use static HTML instead, and modern PHP is maybe 3/10 where it's better but it's just not better enough to use if you could pick something else.
And it's not like it's no longer possible to write quote-unquote "bad" PHP -- if nothing else, PHP is backwards-compatible to a fault.
Almost everything but async/threads that I use in Java stuff has an 1:1 mapping.
Something like https://github.com/mridoni/llxvm
I think that's more a framework/library philosophy than anything else. When I dabbled with PHP + symfony, I worked with some of the most clean APIs I've seen to this date.
The best example to show this is that you can `foreach()` over an object. It wasn't a deliberate feature but rather an artifact of how objects are "syntactic sugar over Arrays" and how Arrays are really just hashtables.
And it becomes problematic with the many exceptions that all the functions operating on Arrays have. Almost all important functions' documentation (edit: on arrays) goes something like "if the array key is a string, it will act like X, if it is a number it will act like Y". With some going like "if one of the keys is a string it will X, otherwise it will Y". And Y and X being rather different in return values, errors and such.
I can understand that PHP has a really strong preference for strings - HTTP is only and all strings after all - but the mess around arrays is real, dangerous, and has bitten me, my companies and many of my clients many times over. For decades.
[1] http://quercus.caucho.com/
https://www.peachpie.io/
https://www.peachpie.io/usecases
good to see that php's upholding the tradition of putting the K in Quality ;)
While there's nothing inherently wrong with using PHP for tasks Java already handles well, given Java's proficiency in its domain, it's not always necessary to replicate these functions in PHP.
However, there's a tendency to undervalue PHP-based applications, often labeled as 'home.php-style' apps. It's true they can become unwieldy and unmaintainable if not properly managed. Adhering to good practices is essential, but it's also important to remember not every project needs a complex solution like bootstrapping a Laravel project for a simple task list. Everything comes with its own set of trade-offs!
Let's face it, a major advantage of PHP nobody talks about is that devs are cheaper.
I don't mean this all in a bad way, I have seen PHP used in high quality code-bases for websites of medium sized companies. But you are limited to input/output operations. However, there is also an advantage to this, as the PHP devs I have seen are more prone to trying out new tools and not reinvent the wheel in source code.
Also, I want to shout out to the guys making Sulu CRM. Loved working with it, too bad it's PHP and symfony only.
Do you mean "less prone"?
Edit text file on server, refresh page in browser, see your changes.
That's really difficult to pull off with Java.
You are technically right about changing files of course, but remember:
- PHP speed is all about caching. Changing a file means rebuilding (all) caches.
- PHP debugging is nothing worth bragging about. Java is way more powerful and the jvm supports runtime reload of methods as well.
This also goes together with the fact that most php devs are println devs (from what I have observed).
And then there are other things like maintenance of old php applications is a major headache because on mac old php versions just disappear in brew. And new PHP releases like to break A LOT.
I have the opposite experience:
Because PHP and package management is relatively new (Composer is from 2012, compared to CPAN's general availability in 1995), I haven't seen more wheel-reinventing than among PHP programmers.
Even the standard library seems to be reinventing its own wheels. I'm looking at you, mysql_real*_escape_string.
You're presenting this as if it's a feature. I think that's a good summary of PHP and its culture's relation to types.
With great flexibility comes great responsibility
I don't think there's that. In every thread about PHP, many people come in to explain this (edit: this = how good PHP is for use-case X, or how good it is holding up). Every time.
"We" all know PHP has its very well-fitting sweet spot. Its use-cases where it shines.
I do think, though, that the list of use-cases and the size of the sweet spot is not as big as the usage of PHP makes it out to be. What I mean is: there are many situations in which PHP is the best solution. But in many places where PHP is employed, it is not the best solution (anymore).
EDIT: All that to say, I get it, and for my part I'll try to tone it down. Thanks for listening to this old(er) guy rant.
A current example for me is SQL vs ORMs. I feel like I'm more productive building SQL queries in my application (ideally using a query builder API), than using an ORM. Because SQL was created to be a language for manipulating relational data, and thus does the job better than the indirection introduced by an ORM framework.
I think Elixir with Phoenix and LiveView can give PHP a run for its money. But PHP is a beast.
HTMX, Laravel, Livewire, alphine.js are all the things that are what these insane JS SPA frameworks aren't. Simple and intuitive.
I'm a JS guy and I'm convinced this way of orchestrating the UI from the server is really the future of full stack dev.
At least to solve 80-90% of use cases. There are still some situations that require client side components with APIs but it's really a minority. Doesn't make sense to focus all your efforts into a complex solution that is appropriate for a minority of use cases.
you're going to get a mix of yes and no depending on what you're trying to do. lots of things have been deprecated over the years.
They're still disabled by default on FreeBSD - my PR is pending, and the patch has been in testing in ports for a while: https://github.com/php/php-src/pull/12288
I wonder if I'd have just started off immediately using something like Java if I would have been as effective? Early PHP's sloppiness (paired with early javascript) gave me a lot of flexibility and allowed me to learn things more deeply.
I’d take PHP for a new project in a heartbeat if the shoe fit. My last real PHP project was Laravel+Inertia+Vue and it was a really great workflow for me and my team.
Yeah, great. Now I have two problems.
> downloadable binaries on Windows
I am on Linux.
> Official docker images on dockerhub
Yeah, great. Now I have two problems.
> Not sure where you saw those 9 pages
In the official documentation, https://www.php.net/manual/en/install.unix.php