PHP is the Hyundai Elantra of programming. It used to be popular because of low adoption costs but was the butt of jokes for a long time because of its questionable design and poor reliability. But like the Elantra, it has come a long way and is actually decent these days.
As an example, since 2023, the standard base level Corolla has an automated suite of driving assistance technologies that blow away anything Mazda offers even at their highest level of expense.
There is only one car that passed testing for automatic emergency braking from 62mph to a dead-stop (future standard) - the Toyota Corolla.
Toyota Corollas are exceptionally well-engineered cars. The thing is, they're engineered for convenience, reliability, and affordability. Toyota explicitly eschews bells and whistles that seem impressive but would add complexity to the car, because complexity usually brings cost and unreliability with it. So you get a car that is boring to drive, boring to ride in, but fulfills the car's primary purpose (getting you from point A to point B, cheaply and safely) extremely well.
Likewise, Java is also extremely well-engineered. If you've ever looked in the internals of the JVM or the class libraries, there is a lot of thought and a lot of advanced technology that went into it. But it's engineered to be boring. It's made so that the average programmer at a big company can be productive without screwing things up too much.
The only reason I'd say that Go might be a better analogy is because Go is also extremely well-engineered, but it's engineered to be reliable when used by average programmers at big companies. There are still quite a few footguns in Java around multithreading and exception handling. Go just says "We'll use CSP for concurrency, which is already battle-tested, and we'll make every programmer handle every error case explicitly even though it's lots of boilerplate code, because if you don't make engineers think about it they get it wrong." That's a pretty apt analogy to the Corolla, which is also pretty concerned with making sure that semi-skilled mechanics and unskilled drivers need to explicitly think about what they're doing because otherwise they get it wrong.
It does exactly what a transportation device needs to do, and it does them quite well. However, neither excitement nor flavor were in the design criteria.
The cluster flashes CONSTANTLY. It flashes to tell you there's a speed limit change. It flashes to tell you there's a crosswalk. It's a cacophony of alerts that lead to immediate fatigue and make all alerts meaningless.
The car beeps constantly. It beeps to tell you the speed limit changed (which happens multiple times per minute in many places). Often in places where the speed limit change isn't signed, but implied -- every interchange on the highway, the limit dips for a side road, then increases again after you pass the side road. It beeps persistently to tell you you're over the speed limit by 1kph, and keeps beeping for at least 5 or maybe 10 seconds.
It tugs at the steering wheel constantly, when it thinks you're too close to a white line. I got news for ya, in countries with narrow roads, you're ALWAYS near a white line. It tugs you towards an oncoming bus because you're cheating too far towards the opposite shoulder. It tugs you towards passing vehicles because you dared make room for faster traffic to go by (see this a fair bit in eastern europe).
Too many of my recent rentals have been Toyotas, usually hybrids (RAV4, Corolla Cross, Corolla).
Give me the Mazda.
I agree if we were talking about Java 8 (and I have no doubt a lot of people are still unfortunately using that), but I wouldn't mind a modern Java setup as much as I would have in the past.
Of the two, Mazda3 would be the "less frills, cheaper, works", especially in 2025.
I also don't recall a period of lack of trust for corolla due to design/repair ability; My great uncle always talks about his "first real, new car" being a 69 corolla that was a workhorse. That paved the way for the JP takeover by the late 80s.
Can you tell me which car is Python, so I can add it to my shopping list?
The Hummer H3. When the Hummer came out it did a few things exceptionally well — better than anything else — although there were plenty of areas (speed, aesthetics) where it was crap. It was popular, so they made a later version riding on the name that was incompatible with the original mission, hoping that the folks who had aspired to the first version would continue along; and somehow it worked.
Toyota is incapable of making a fun car - it’s just not in their DNA. That’s why all of their current sports cars are made by other companies (Subaru and BMW).
I would say it was more like the bicycle. Cheap, no license, even a kid could be suddenly zooming around town with no ceremony, no red tape, minimal investment.
I haven't used it in well over a decade, but still remember fondly how great it was as a gateway drug to bigger and better things.
(Do one thing, but do it well; sounds familiar?)
It just moved the work somewhere else, generally an Apache config on a shared host. The user could very often just dump some PHP files in place and they'd be served up, but if you had to set up a new host then it was as fiddly as anything else.
This pattern also meant dropping everything the docroot, using .htaccess to hide things, having different behaviour depending on the global php.ini. All architectures had to be mashed into a request/response cycle (and anything more complex was no longer just drop the files in). It was a very long way from the idea of reproducable builds.
I agree it was popular, but not really for the right reasons.
Thanks God most of us didn’t have to deal with that enterprise crap for long, and in my case it was thanks to PHP too.
I think that’s the root of much of the horror. No one would bat an eye at using PHP to add little bits of server-side content here and there. It’s great for that! But then you see the giant castles of non-Euclidean horror built with it, and people pointing to them and saying “see what you can built with that weird screwdriver?”, and parts of the castles randomly fall off and kill their owners. No! While that’s impressive, it doesn’t exactly inspire confidence in the screwdriver, or in the people who keep using it to build things larger than it was clearly able to do well. But heaven help you if you point out that there are saner screwdrivers. “You’re just being close minded and out of touch! We added another handle to it and removed the razor blade so it’s much better now!”
Maybe so, but wow, it’s still one hell of an odd screwdriver.
As I remember it all the early languages that let you write code inline with the HTML were proprietary such as server-side Javascript built into Netscape's web server, ColdFusion, ASP, etc.
PHP was the first of these that was open source and basically competent which made it my #1 choice for making web applications in 2001. Compared to many other languages (say cgi-bin) it was pretty fast without a build step and had enough resource management that hosting firms could offer cheap PHP hosting plans which made world-changing open source products like Wordpress deployable.
It got long in the tooth quickly because people realized that to make quality web applications you had to have a part of your framework (a "router") which could serve different pages based on the inputs. For example, if you are doing server-side error handling on a form you either display a form that says "successful" or you re-display the form with error messages. You certainly can write PHP that does that if you have some discipline, but once you introduce a router you might as well write your "views" with some kind of templating system and after ruby-on-rails every language got frameworks, typically Sinatra-like, which were about as comfortable as PHP and that pushed you into having some discipline.
It wasn’t until Rails rolled around that I built anything resembling a “real” web app, though. The structure and convention it brought made it much more approachable than PHP, because all the examples of more involved PHP at that point were chaos-spaghetti that was a challenge to tease apart and use as an example for learning.
What does it do better than other languages? The article mentions features that sound like parity with other modern languages, but nothing that stands out.
Shared nothing architecture. If you're using e.g. fastapi you can store some data in memory and that data will be available across requests, like so
import uvicorn, fastapi
app = fastapi.FastAPI()
counter = {"value": 0}
@app.post("/counter/increment")
async def increment_counter():
counter["value"] += 1
return {"counter": counter["value"]}
@app.post("/counter/decrement")
async def decrement_counter():
counter["value"] -= 1
return {"counter": counter["value"]}
@app.get("/counter")
async def get_counter():
return {"counter": counter["value"]}
if __name__ == "__main__":
import uvicorn
uvicorn.run(app, host="0.0.0.0", port=9237)
Non-php toolchains, of course, offer the same upsides if you hold them right. PHP is harder to hold wrong in this particular way, though, and in my experience the upside of eliminating that class of bug is shockingly large compared to how rarely I naively would have expected to see it in codebases written by experienced devs.
Edit: Oh, you showed an example against Python! Now I get it!
1. Easy deployment - especially on shared hosting 2. Shared nothing between requests means easy concurrency AND parallelism 3. Mixing with HTML means you do not need a separate template language
Not everyone will see the third as an advantage, and many web frameworks, including PHP ones, prefer a separate, more restrictive, template language. It can be a footgun, but it is very convenient sometimes.
While I never actually wanted it, #2 was kinda cool spiritually. Same with CGI or a Cloudflare edge worker.
Like many other things, PHP makes it easier to do the wrong thing than other languages which make you do the same thing correctly.
Besides the shared nothing architecture mentioned by sibling:
- A more mature community and ecosystem for open source packages e.g. basics like following semver
- One single clear option for package management, which is also by far best in class
- Simply better performance except maybe compared to javascript
While the rest of the options may tick one of the above boxes, none of them ticks all 3.
I still don't think PHP is a good idea for a greenfield project or anything, but they have done a good job of hiding all the footguns.
I also really don’t like the language. I’ve never warmed to it.
But I think it will still be around, as a principal backend language, for the next fifty years.
I feel like this graph says it all: https://w3techs.com/technologies/history_overview/programmin...
I call it "The Fishtank Graph," for obvious reasons.
They've apparently written their own web crawler that attempts to infer what language is used based on a bunch of, unspecified, heuristics. I wonder if at least some of the problem is that it is very easy to see if site uses PHP and much harder to see if a site uses a python backend and a such most python using sites just aren't being counted.
I totally believe the graph, if only for things like WordPress, and a number of other infrastructure-level tools.
I know that the porn industry is still big on PHP. There was a post here, some time ago, that linked to a PornHub programmer, talking about their IT stack, and it was all PHP.
It's a boring workhorse. The "boring" part is attractive to IT pros.
Maybe because most websites are Wordpress websites.
I've never really used it but it would have been somewhat useful to know why anyone would choose this language for a greenfield project in 2025, given the choices available. The reasons given are pretty unconvincing to me.
My 2nd to last quarter I had to cram 20 difficult units because of some requirement I had somehow missed. Part of that was a 5 unit web development project/lecture course. Our project was to build an ecommerce site. We were introduced to several paradigms of how to build end to end, PHP being one of them - and as other commenters have noted, what I particularly liked was its ease of deployment.
However, the class at the end pushed everyone towards vanilla JS, which I have never had much success working with and to be honest kind of loathed it. I could not deploy the site with it on the school servers - apparently I wasn't the only one.
So, I looked carefully at the rubric and realized only 20% of it was code evaluation. The rest was site design, and one massive chunk of the grade was simply just getting it deployed by the deadline.
So, I wrote it in php because I knew 1000% it would work and I could get it running on time. The TA wanted to fail the project, but since only 20% of the grade was code, I got a B-. Almost everyone failed because only a few people could get it deployed at all.
I'd love to work on modern PHP projects but don't know where to start or what even is out there, people just scoff at it because it looks horribly ugly and its history of security flaws.
Granted, the specific directions of the criticisms aren't quite the same, but there's definitely a decent analogy in there.
I don't know much about particular models, but perhaps a better make to pick as an apt analogy for PHP would be Hyundai: formerly a brand with fairly widespread reliability issues, that cleaned them up a lot more recently, and now a very solid pick.
It also includes breaking changes in point releases which is a nonsensical maintenance strategy - this is in stark contrast to the reputation of stability in a Corolla.
While PHP may have some strengths, it immediately fails this particular comparison.
Segfaults in PHP are highly unusual. The language definitely has warts, but it's extremely well tested and usually doesn't crash in production, unless you're using unstable extensions or pre-release versions.
> It also includes breaking changes in point releases which is a nonsensical maintenance strategy
There are lots of projects out there that do not follow semver for their releases; that doesn't mean it isn't stable in itself. Having said that, every PHP release at least has proper change logs so you can safely migrate to a new version.
It's one of the main reasons that frameworks exist today. 99% of DEVs are not security conscious enough, and would leave gaping holes in their code. No input validation, SQL injections, trusting data posted to code without validation, on and on.
If you were continuously hacked no matter the update, likely the code was the issue not PHP. Or of course, your servers were backdoored at that point.
A framework often protects from much of this.
(as someone who's maintained a lot of different vehicles for years and a lot of programming languages this doesn't even quite cut it. PHP is a lemon car).
I've written more shell scripts than any other language for close to a decade now. The reason is simple: I'm not writing web apps. I mostly do system programming (that is to say, tasks needed to build or maintain a system or are generally user-focused yet non-interactive). You don't need more than a shell script for most of that.
My contemporaries will, of course, pooh-pooh a shell script on general principle. If it's not using a more "advanced language" it must be unreliable or unmaintainable or ugly. Yet the practical experience of writing programs in multiple languages over years leads me to the same conclusion: literally any language will do. You could use BASIC for system programming. You could use ASM. It will work. People will argue over whether one language is "better" than another, but who cares if it's better or not? If it works it works. But that's because nearly any language works for that kind of program. Other kinds of programs need advanced features, so you need a more advanced language. But for simple tasks? It doesn't matter.
To go back to the car analogy: you can use literally any car to pick up groceries. You can't use any car to pick up 3,000lbs of sandbags.
If we were scientists and not craftspeople, none of these discussions would be relevant. We'd pick up the tool designed for our specific purpose and not bicker over our personal preferences or idealistic principles. But our languages, and our approach to using them, is anything but scientific. We're just a bunch of tradies talking shit at the water cooler.
"Use this other language I know for the backend, it's the [reliable car model]. It's the {Latin, Swahili, English} of the programming world. It's JVM, it's PHP, it's Python, it's Ruby, it's C#'"
I feel that after a decade of jumping between systems, TypeScript is now the "good enough" language. We have to use it on the client. Now we can use it on the server.
The weird side-projects vibes node libraries had in the 2010's have matured into fully supported production systems in the 2020s.
And I've never been happier. It's a fine choice for the backend, and it's not really optional on the frontend. Which is important: like a lingua franca, TS/JS is not optional in a web app. This is not an attribute which PHP shares.
Most people will tell you to use pm2 to start copies of the server. Well pm2 looks like a hack cobled together. And pm2 has conflict of interest with their paid pm2 server. There's incentive to keep pm2 free version limited.
Other's will tell you to use many docker containers. Seems a bit overkill for some applications.
Why can't it have a simple, mature, built-in multi-threaded server like .NET Kestrel or Go http?
PHP was not well designed. No one learning to program should choose it as a first language. That fact that people did choose it was because it was free, easier than Perl and cheap/easy to deploy (in the shared hosting era).
You are better off starting with a typed language like C#/Java/Kotlin (for OO-first) or OCaml/F# (for FP-first) or even Golang.
PHP sets you back if chosen as a first language.
That’s Lisp. It was made for brain-level problems before AI was cool. It didn’t disappear, it just kept doing its thing while the rest of the world stacked layer after layer of frameworks and hype. It’s not trendy. It’s not dead. It’s just too powerful for most people to even know what to do with. It won’t write your todo app, but if you’re trying to build something wild that actually thinks a little, Lisp is still sitting there, waiting.
The CMS frameworks have also improved quite a bit.
The improvements in PHP include big performance gains - PHP 7 was a huge improvement over PHP 5 and now PHP 8 also includes a JIT), improvements in the language such as a type system, object orientation, improved error handling etc.
PHP 8 is a lot faster (about 3x) faster than Python.
https://sailingbyte.com/blog/php5-to-php8-modern-programming...
Basically what they did is they had repeated codemods (changes to the entire codebase with automated tooling) that bit by bit moved PHP closer to Java. More and more static typing, generics, all the common Java ADTs (Vector, Map, Set, Pair, etc.), bytecode+JIT execution, etc.
Essentially instead of rewriting the codebase to a better language they just changed the language itself. Which makes sense since PHP is a much smaller codebase than the Meta backend.
PHP as a language? Definitely getting better but still not great. Doesn't support async, the stdlib is awful, data structures are quite rudimentary (no tuple, no list, no map, just a weird array type mixing maps and lists), the old extension system sucks.
But the ecosystem? Damn. I see many people here saying that Typescript is definitely the mature choice for the backend. Honestly, I wanted to believe it, but I disagree. The level of productivity with Laravel is absolutely insane. You have everything you need out of the box and you can launch something so fast it's almost unreal.
Typescript doesn't have that. Maybe it's because of a different mentality in this ecosystem (you should build your blocks yourself), but nothing comes close. The closest would be Adonisjs but it doesn't seem to gain traction.
You don't choose a language to build your web project. You choose a stack. A framework. I definitely prefer python but Django has way less features than Laravel and I don't really enjoy using it. Typescript on the backend was a thing I wanted to believe in (because sharing types between the front and back is a great idea), but I feel like I have to reinvent the wheel, or at least choose 20 different wheels to do something quite simple.
Is Ruby such a great language, or do people just love being productive with Rails? It seems to me that the usage of Ruby without Rails is quite low (I could be wrong).
People choose and stick with stacks, not just languages. And I couldn't find something equivalent to Laravel elsewhere. Give me an equally productive stack and I'll happily drop PHP.
The things that held PHP up in the early days, especially it being just dead simple to deploy, are not as big a deal in 2025 as they were in 2005. Shared hosting, while it still definitely exists, is kind of a dying model. Most modern dev I see these days even in PHP is nginx/PHP-FPM and containers, which is really not that terribly different from any other web framework. Even Wordpress, these days I recommend anyone who truly wants to go down that path to find a hosted Wordpress provider rather than trying to do it themselves.
Personally? I would never start a greenfield project now using just PHP. I don't know many people who would.
But PHP + Composer + Laravel? Laravel did for PHP what Rails did for Ruby, and what React/Vue/etc did for JS. Composer gave PHP real package management. It cannot be understated how important it was to have a framework and package manager to take care of all of the thoroughly unpleasant parts. That way you can focus on building the app, not reimplementing things you've done so many time before.
I've mentored for a lot of PHP GSoC projects. I always force the students to use PHP binaries from the late 90s or early 2000s (the sweet spot IMHO). Those versions are typically simpler in design/implementation, built to last, and-- for the relatively minor bugs you find-- there are lots and lots of workarounds you can find all over the web.
I do understand the conveniences that make people choose the latest version. But these GSoC students are typically working on projects where things like personal health data must be kept secure on public facing servers. For those cases, being able to understand the engine-- and even change it out manually, if needed-- is paramount to security.
In short, those earlier versions were designed by engineers to last. And if you know how to patch the runtime you can essentially drive them forever.
And... scene. :)
What is the significance of 'scene'?
Generally - we live in a world with lots of fantastic programming languages, so I would never choose PHP for a greenfield project if I had a choice, and I would not pursue professional opportunities with legacy PHP codebases except in very special circumstances.
I think the main issue for PHP nowadays is the curse that it had many issues (especially security-wise) in the past and so many folks believe that the PHP of today is still the PHP of the past, when in actuality, it's evolved into a pretty dope programming language/environment with some pretty decent features. It seems like this is something that the PHP community can't shake no matter how hard they try.
That's why it's so popular in those circles. If you want really solid selfhosted platform for publishing/ecommerce you can't avoid it.
For SPA web apps or anything realtime… sure there are probably better choices. But many agencies transition to making small apps with devs already knowing PHP then it's not bad choice.
PHP is boring and poorly designed. Maybe more like some of the very old Eastern European cars.
https://rakujourney.wordpress.com/2024/09/15/can-raku-replac...
If you are wondering, Raku can replace PHP literally…
"PHP".subst(/PHP/, 'Raku').say; #Raku
The Toyota Corolla would not be what you think it is if "Altima people" historically went out and bought them in droves and many would do well to think about comparable effects on other classes of product (Adobe Flash anyone?).
PHP is more like a Lime scooter. Trivially easy to start with, gets going quickly, significant chance of causing brain damage.
I’m resistant to using php, because I really don’t want to have heavy server resources, but if I were building an app that used heavy server resources anyways, I would be open to php.
I've not been out of work for my entire 20 year career and there were always lots of jobs around.
Many other people I know that used other languages struggled a lot more over the years.
It's interesting how clearly 80% of the developers in the community clearly have 0 clue about modern PHP. People mention shared hosting, code in html files, CGI and bad security defaults. To be clear these things have been dead in the PHP world for 10+ years, but most developers here have used it once in 2005 and haven't seen how it looks like in the modern ecosystem.
It's as if whenever the topic was Java, the discussion would center only around the devs working with Java 1.8.
Likely, the rest of the discussion on HN is of the same level, but I have a harder time spotting the errors.
We'd like 'thereotical fundamental aesthetics that strongly predict beautiful and useful programs' to be the thing to judge languages on and well, nope, never.
None of that matters until people start making stuff. And people making stuff with the language which in turn equals more people making stuff with the language is the primary metric.
e: (my only real experience with java is spring boot)