Java is more akin to the Corolla. Utterly insipid (by design), lacking in refinements compared to competitors like the Mazda3, and made for people who just see it as a way to get from point A to point B.
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.
This is very ignorant of a modern Corolla in a lot of ways.
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.
I think it's a pretty good analogy - the only programming language that I think might be a better one would be Go.
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.
> Toyota Corollas are exceptionally well-engineered cars. The thing is, they're engineered for convenience, reliability, and affordability.
Say that to the half a dozen recalls my 2007 Toyota Corolla had. The constant sensor issues. And a slew of other issues, like the very well know chain issues.
Well engineered is something that really does not fit with my 2007 Corolla. Yes, my 1992 Corolla was a tank, but not the "modern" 2007 version.
> affordability?
You mean the 33.000 euro that a base model Corolla now costs??? I think people have been living in the old corolla's mindset from the 90's because modern Corolla's are expensive cars.
Worst of all, its not even the good hybrid. A BYD SUV with 1080km actual road range, with full loaded electronics, solar roof, the works was 36.000 euro here. When a not big hatchback is that expensive, vs a freaking SUV...
If I want to buy a car today, preferably electric, that is like the corollas of the 90s, what should I buy? Not having customer hostile features like DRM or anti repair anti features is a part of this.
This just isn't the case anymore, Toyota isn't that company.
Right now they're just producing cars that are better engineered and it isn't because their pieces are conservative. Their technology isn't lagging, in fact, it's ahead in this particular area of COMMODITY cars.
Even that being granted, Toyota is an integrator. They don't have vertical control of their supply chain. They're not as far ahead or different from other companies, they just have different priorities and a larger war chest to draw from.
Luxury cars are ahead but that isn't in contention.
I'd also argue that Go is the better analogy because it also eschews bells and whistles that would add complexity to it. While Java the language was indeed intended to be fairly unexciting, the JVM came with a bunch of complexity that took quite some time to tame (e.g. it took a while for JITing to really get the performance to a reasonable point, and GC longer still).
The modern Corolla, like most competitive cars, is a good, safe, high-quality, reliable car. These qualities aren't at odds with being "insipid". The Corolla interior feels utilitarian, its features are spartan, and the driving dynamics are... behaved.
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 Corolla has better implementations of modern features than the Mazda3, it's simply not as flashy.
As someone who owns and drives a 2024 Mazda 3 PP daily, and test drove and compares notes with my neighbor who dailies a 2024 Corolla XSE Hatch, I don't think this characterization is accurate at all. I have nothing against the Corolla, but the Corolla is lacking in /many/ ways compared to the Mazda3.
One simple example is that my Mazda3 has a heads up display that puts car safety system data, turn-by-turn navigation (from android auto or apple carplay or built-in nav), speed data, and vehicle data into the HUD so I never need to look down at the dash.
Another example is that while the Mazda3 has a touchscreen in the center console, there are physical controls for every functionality with good tactility and Mazda has chosen to disable the touchscreen once you exceed 5MPH (by default), ensuring you aren't distracting yourself using a touchscreen while on the highway.
As to all those automated safety systems, most of those are government mandated and every car has them. I do agree that Toyota does a better job than most manufacturers, but to my knowledge there is not a single system on my neighbor's 2024 Corolla that isn't also on my 2024 Mazda3...
Where the Corolla wins in my opinion is actually its simplicity. The Mazda3 has too much effort in its interior, but also somehow not quite enough, and it ends up with it being very comfortable to drive except it sometimes has rattles in panels, which is not a very premium experience. The Corolla has a much more basic interior, very bog standard, but it's also flawless in executing being bog standard.
As far as driving dynamics, it's no contest, the Mazda3 is significantly better. The only Corolla with great driving dynamics is the GR Corolla, but that's really a completely different sort of car.
In context, it appears they are using the word “refinement” to refer to enthusiast taste. They’re not saying Toyotas are crude vehicles. Your opinion notwithstanding, their statement is very supportable, both in industry reviews and in both brands own value proposition.
I just had a rental Corolla in Europe. It had a lot of driving assistance features, and they're all absolute dogshit (and, I think, mandated by EU regulators). It's a pain in the ass to turn them all off every time you start the car, and I don't know how any drives these cars with them enabled.
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).
So, the interesting thing about this is that I've heard it before but I didn't really understand it until I drove with my father-in-law, who drives like a mental patient.
His cluster was flashing constantly, warning him of imminent doom. And it was warning him correctly, because he was accustomed to driving incorrectly.
Of course, he hadn't been in an accident in some time - but this was more thanks to luck of the draw, his ability to ride the razor's edge, and other people's attentiveness.
I own a modern Toyota and I am never hassled by the safety features.
I own it because I just don't care about cars and it's that car.
| His cluster was flashing constantly, warning him of imminent doom. And it was warning him correctly, because he was accustomed to driving incorrectly.
In the cars I've driven, the cluster flashes all happen regardless of how you drive. The speed limit changes and crosswalk indications and so on, will always trigger. (Unless you disable them -- however, in a foreign country, where I don't understand the customs quite as well, I was willing to tolerate the annoyance to reduce my odds of running afoul of the local constabulary).
The one exception is the speed limit indicator continues to flash if you dare exceed the posted (or, sometimes imagined) limit.
It’s possible that my car (NA market 2023 Nissan EV) just isn’t as “vocal”, but as a relatively new driver I’ve found myself changing my habits to not anger the machine. These days it rarely gripes at me.
Arguably some of them are useful (speed? as much as I hate to say it).
I don't think the "don't drive anywhere near the edge of the lane" is a good practice. There are lots and lots and lots of good, pro-safety reasons to come near the edge of a lane, or even cross over it, and I'm not sure it's helpful to train drivers to stay in the geometric center of the lane. For example it's one of the things I hate about autopilot the most, the car tries too aggressively to center itself.
No, I'm aware of both involved technologies the implementations.
I test drove the Mazda3 for my kids and it had some faux-luxury accoutrements but fundamentally it was an inferior car: the technology implementation was worse.
Mazda hasn't invested in drivetrain implementations so they license Toyota's.
Mazda hasn't invested in ADAS software so they barely try.
Mazda hasn't invested in a decent suspension implementation so their 3 line uses some god-awful torsion beam garbage that feels completely unrefined and consumer.
> Mazda hasn't invested in drivetrain implementations so they license Toyota's.
??? Mazda has their own drivetrain development, there is nothing in a Mazda3 that is shared with a Toyota. The only company sharing drivetrain with Toyota is Subaru and BMW via their joint ventures on the BRZ/GR86 and the Z4/Supra.
> Mazda hasn't invested in a decent suspension implementation so their 3 line uses some god-awful torsion beam garbage that feels completely unrefined and consumer.
Mazda uses a torsion beam rear suspension on the Mazda3, that is true. While independent and multi-link suspensions /can/ be superior handling, it relies on having adjustability in the suspension arms to allow you to set your geometry to match your expected conditions and the tires you're using, which is to say that it's basically irrelevant in a commodity road-going vehicle, most of which offer no adjustment in the rear or toe-only adjustment. I say this as someone who raced cars as a hobby, and invested the time/effort/money to learn at least as much about suspension design as someone who did an undergrad in MechE, modeled my racecar's suspension in software, and worked with a shop to develop and produce custom suspension arms with full adjustability to match my ideal geometry.
Despite the technically "worse" torsion beam suspension in the rear of the Mazda3, it handles better than a Corolla XSE on a curvy road.
EDIT: I stand corrected, Mazda licenses the RAV4 Hybrid drivetrain for the CX-50 Hybrid crossover. Which is of course super-relevant to the Mazda3, a totally different vehicle, which almost anyone who cares about the drivetrian buys with the 2.5L turbo motor and PP so they get AWD, but hey who's counting.
Modern Java is quite good these days, no? Type inference, fibers, text blocks, records...
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.
Pretty funny you mention Java 8 as a negative example, I remember it being widely heralded as a step in the right direction that was a long time coming and a breath of fresh air.
The JVM and its ecosystem are the best thing about the Java platform. Not the language, i dont even use it anymore and i am nearly 100% JVM based. But even then its still not horrible. it's just that there are better options like Scala.
Great analogy, horrible example in the analogy heh. (Hate to nitpick)
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.
Java is more like the Honda. It's literally everywhere, ultra reliable, sufficiently boring technology that people can't stand to look at it because it simply makes no statement about anything, and despite all attempts to replace it or dethrone it, it continues to excel and grow.
> 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.
A Mercedes Benz sprinter. It’s being used for everything. From simple delivery to nerdy camping. Not the fastest, but has loads of modularity and can work as a daily, work truck or leisure.
I'd say the sprinter is more like Fortran. You use it when you need to move around lots of stuff and although it's quite fast on its own, you would drive it neither for fun nor when you only have a few things to move around.
I drove a 2009 Corolla SE for 3 years of my life. Its _only_ redeeming quality was that maintenance and repair bills were minimal. Besides that, it was sluggish on the highway, handled like a shopping cart, unstable at 140 km/h, and had an interior that would never let you forget that you’re poor.
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).
PHP did well for ONE reason: it was really, really, really easy to deploy. This was, of course, underestimated by programmers in the know, but I remember first getting into web dev, and I could start putting real programs (!!!) on the web, in minutes!
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.
Can't upvote this enough. Zero friction is like superconductivity: a huge, qualitative jump. If doing the key thing is trivially, absurdly easy, people will readily excuse whatever shortcomings the product may have, be it a specialist tool like Docker, or a mass-audience service like Twitter.
Yep. I was doing Perl CGI scripts at the time, and you often ran into deployment issues somewhere along the line of uploading the scripts via FTP, making them executable, and setting the permissions on any files that needed to be written. Building PHP into the web server instead of external CGI scripts eliminated a lot of that, so it was more likely to just work without some back-and-forth with a web admin to get things setup right for CGI to work. It wasn't the language, but the way it was deployed.
Yes! This was huge. You could go from coding to uploading to refreshing your application as fast as you could perform those actions. And don’t forget, with Perl CGI, you had to output the right Content-Type header (and two carriage returns) at the top of your outputted page content for the browser to even parse it correctly.
of all the reams of php snark the internet has produced, one line has stuck in my mind - "any fool could write php, and many did". both because it was funny, and because that lowered barrier to entry is actually a good thing. I want "any fool" to be able to program and if php supports that goal, more power to it.
PHP is so hard for me to describe. I used it a lot in the late 90s when we were migrating off mod_perl because it was a great way to add dynamic data to otherwise static pages, and no one really knew how to develop large sites yet. We were making it up as we went along. But ye gods, the language was bad. “A poor craftsman blames his tools” and all that, but imagine a screwdriver with 2 handles and 3 tips projecting at random angles. Sure, you could assemble an IKEA desk with it, but would you want to? And would you look suspiciously at anyone who claimed to love that weird screwdriver when the equivalent of a Snap-On was available for free from the same place they got the weirdo?
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.
Its HTML-inline nature is the entire reason I ever used it. At some point in the early 2000s I came across PHP’s include, which felt like the piece of HTML that’d always been missing. Suddenly I no longer had to manually keep all that header/nav/footer code in sync across N pages! Magical.
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.
The author makes a fair point that the language is no longer the fractal of bad design it was in 2009, but doesn't make the case for starting a green field project with it in 2025.
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.
This is often the fastest way to solve your immediate problem, at the cost of making everything harder to reason about. PHP persists nothing between requests, so all data that needs to persist between requests must be explicitly persisted to some specific external data store.
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.
I hadn't really thought about PHP through this lens. But it's so much a part of where it came from as a preprocessor for text. It was a first-class part the stateless design of the OG internet. Now everyone wants all things persisted all the time, and leads to crazy state problems.
I think the advantages are pretty much what they always were.
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.
I think #1 has been outdated for a long time. FTP or copying files through CPanel hasn't been more convenient than workflows like `fly deploy` where you don't even need to know about a remote file system nor about a server that's already running. And php-fpm being called by nginx is also more complicated than just "node script.js" or running a compiled Go binary.
While I never actually wanted it, #2 was kinda cool spiritually. Same with CGI or a Cloudflare edge worker.
People who manually copy files are not going to use anything more sophisticated. It was not what I had in mind and I do not think its a fair comparison, nor is a pricey and proprietary platform.
These days I imagine people are more likely to be using git pull or rsync anyway.
> And php-fpm being called by nginx is also more complicated than just "node script.js" or running a compiled Go binary.
Apache with mod_php is still an option AFAIK. It is also definitely easy to find everything pre-configured on share hosting. Then there is FrankenPHP.
Might not be the easiest option for everyone, but it is going to be for some people.
I think 1 is a myth. It’s easy to deploy as long as you don’t care about atomic updates, like the newly uploaded version of foo.php importing bar.php which hasn’t been uploaded yet. Solve that, say with a DAG of which files to upload in which order, and it’s no longer easier than anything else.
Like many other things, PHP makes it easier to do the wrong thing than other languages which make you do the same thing correctly.
I worked at a place that did git pull as the release process - it was a big site but I never heard of there being any issues (though the code was on life support so no huge changes were happening).
They switched to blue/green deploys for the new site (which I suspect was done at the server level, not with symlinks or the like).
No, but it's moving the goalpost quite a bit. "Just copying a bunch of files around" is definitely easier than, say, deploying a new Docker container containing a Python app or a Rust or Go binary, etc. But neither is it nearly so robust.
Maybe. You could probably get pretty far with atomically moving a symlink so that the filesystem view always looks at either all the old or all the new files.
However, even that doesn't handle in-flight requests that have their view of the files swapped out from under them. Yes, that's a small time window for an error to happen, but it's definitely not instantaneous.
The safer solution would be to update the server config to point at the new directory and reload the webserver, but now you're way past just uploading the new files.
That's not quite right. Imagine some (horrid) code like:
$conn->query('SELECT * FROM giant_table ORDER BY foo LIMIT 1');
require 'old.php';
such that there's a significant interval between the request being spawned and it later including another file. The duration of the query is the opportunity for 'old.php' to go away, which would cause a 500 error.
The difference is that you can have 2 ports listening at once and can close the first once it's drained of connections.
There's no fundamentally safe way to upgrade a bucket-of-files PHP app without tooling complex enough to rival another language's deployment.
I don't believe thats how PHP works (atleast not anymore). When the request is made the code is first compiled to opcodes and only after that's done the opcodes are run. In most production environments these opcodes are even cached so even if you delete the project it will run.
In any case you would have to hit some few milisecond window in this opcache generation to break single request but even that might be unlikely thanks to how filesystems read files?
So if there's a 10 second gap between the start of execution and the 'require' line being reached and evaluated, then any incompatible changes to the file being required within that 10 seconds will cause an error.
That's a perfectly reasonable approach, so long as you understand why it's a risky operation and can tolerate the consequences, including customers seeing errors in their browser. If that's OK for your use case, then rock on! If you can't tolerate that, then you have to have switch to a more complex upgrade system, like blue-green deploys behind a load balancer or such. In other words, the deployment method of a Rust or Go or Python or Java app.
In a sense thats blue-green deployment just on filesystem level? PHP is always run behind proxy/webserver (mostly ngnix nowdays)
But you are right there is no reason why you couldn't have two instances of the php app runing and switch between them. For some reason the PHP deployment services i've used seem to use the filesystem approach and i doubt it's laziness or incompetence.
I'd content that it's out of ignorance, and I don't mean that in a mean or nasty way. I've heard lots of pushback from PHP devs that it's way easier to update than sites written in other languages are, but I think it's genuinely due to a lack of understanding of why those languages recommend other upgrade processes. Those processes solve real, genuine problems that also affect PHP, but they're dismissed as overkill or enterprisey or overly complicated.
And all that may be true for a trivial website. If you've written a personal project with 10,000 hits per year, YOLO. Go for it. The odds of it affecting one of those users is vanishingly tiny, and so what if it does? But if you're hosting something like a Wordpress site for a large company with lots of traffic, it's crucial to understand why "just rsync the files over" is not an acceptable deployment method.
Sorry but we were not talking about “rsyncing the files over”. We are talking about what services that i've used like Forge or Ploi do where you deploy project into separate folder and then switch symlink. You can even roll it back.
I have a feeling you want to dunk on poor dumb PHP developer but like Forge is by the people who created Laravel. I believe they would put some thought into it. Maybe just maybe small chance of one bad request is not such a bad deal.
It is literally exactly the same issue, just with slightly less of an error window. I don't think those devs are poor and dumb, but I do think it's likely they've been working in environments where production errors are more tolerated than in other environments.
> Maybe just maybe small chance of one bad request is not such a bad deal.
If your company is OK with that, seriously, sincerely, right on! Keep doing this and move on to other problems.
I had thought about it and you are just pulling my nose.
If you have very long database query and you update your app in middle of it using blue-green load balancer you get to same production error. It is the same thing just implemented slightly differently because of PHP characteristics allow this and with different systems you have to use different strategy.
So yeah have good feeling about us PHP devs having bad deployment strategies.
There's a lot of bad code around, and I think the protections of a (good) static type system are likely of particular use in that scenario. I'd be interested in reading a test of that prediction if anyone has done it (but not interested enough to do it myself).
Honestly the author doesn't even make a great case that PHP has improved since 2009. His arguments mostly seemed to be "don't use the old busted way, there's a better way now". But if you have to go out of your way to remember to not use the old busted way, sooner or later you will shoot yourself in the foot. Having good defaults matters, and the author seems to ignore that.
I think you're underestimating how hard it is to shoot yourself in the foot when using the PHP language defaults and the defaults for any modern PHP framework - it's genuinely hard to do.
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 think you're underestimating how hard it is to shoot yourself in the foot when using the PHP language defaults and the defaults for any modern PHP framework - it's genuinely hard to do.
Agreed. I remember happily starting a couple of new PHP projects in the last decade and the frameworks felt like working in any other programming language.
I’ve used PHP for more than 20 years. It’s my “go-to” language for the backend. I’m not a server programmer, and PHP is fast, well-supported, and, if you’re a decent programmer, you can write robust, secure, performant servers in it.
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 wonder where this graph gets it's data from. Scala sitting at 4.6 percent and python at 1.2 percent is not what I would expect, but my perception of the industry could be totally off.
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 think that we tend to have personal biases, depending on the context of our relationships and professional cultures.
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.
The PHP thing is believable, I'm just still stuck on scala vs python based on my observations from working in the industry and being part of the hiring process for both of these languages. Perhaps it's because I work in B2B SAAS where these products aren't always necessarily exposed to the public internet.
I've also used it for about 20 years now. Surprised you haven't warmed up to it. It's perfectly fine. I still use it for scripts from time to time even though I prefer TS now because it's got some good stuff built-in.
The article loses impact due to the way the author keeps self-conciously mentioning how the "PHP haters" are wrong instead of just explaining the possible usecase for PHP better.
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.
I often wish it weren't the case as much. There's a massive cassum the size of the Grand Canyon between the majority of JS devs and good JS devs that understand the language, and have a good grasp of software craftsmanship. And that doesn't mean stuffing JS based projects with "Enterprise" patterns that don't make sense in the platform being used.
JS devs who started around or just after covid are everywhere. JS devs with 10+ years of experience are a small fraction of the market at this point. JS devs with any number of years of experience who also understand JS (or even just CS in general) well are a minute fraction of JS devs.
I fell in love with PHP in kind of a funny way (and looking at my career now, was probably an indicator I was destined for what I do now) because it saved me during college.
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.
Having always referred to Java as the Honda Civic of language-ecosystem, I take offense to this claim that PHP is the robust, cheap, and reliable workhorse.
Functional and reliable, but often maligned by Real Car People for being boring and underwhelming.
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.
Yeah. I had a 1990 Corolla from its best selling car in the world period and it was functional reliable and designed with a lot of care even if it was a simple design compared to fancier stuff.
PHP is a DeLorean. I think I encountered 10 segfaults in it within 1 year which is a complete joke. This was only two years ago.
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.
> I think I encountered 10 segfaults in it within 1 year which is a complete joke.
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.
I will never give PHP any serious thought. Back in the mid 2000s I started an app hosting company as a side-gig. I started out hosting FogBugz (bug tracker) because Fog Creek Software only offered it as a self-hosted option. I had zero problems for 9 months - it was a Microsoft ASP based app (IIRC). Then I decided to host a helpdesk app called HelpSpot. At the time it was a one-man startup and he didn't offer a SaaS option either so he was happy to send customers my way. The software itself was fine (and it's still around) but it was a PHP-based system and no matter how up to date I kept the servers, the PHP servers got hacked over and over due to PHP's complete disregard for security at the time. My claim to fame is I hosted Twitter's first helpdesk. I got tired of getting home from work and having to rebuild servers almost weekly, so I "sold" my fledgling little sidegig for $2k. Screw PHP.
While it certainly could have been PHP, the amount of poorly coded PHP back then was more often the issue.
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.
I have plenty of other issues with PHP that haven't been addressed in 20 years. There are plenty of other better tools out there. You don't have to choose them, and I don't have to choose PHP.
But when the only issues you can actually name are 20 years old and based on one specific implementation, rather than PHP as a language, it doesn't reflect poorly on PHP. It reflects poorly on your critical thinking skills—or, at the very least, your ability to persuasively argue.
But you call it out as "garbage", claim that you—personally—have "plenty of other issues" besides the ancient history you specifically cited, but do not elaborate and expect us to just take your word for it.
You're asking us to value your low opinion of it, but you're not giving us any good reason to do so.
Look, it's ok - you guys love PHP and I'm sure it has some merits. I still have my same old opinion of it. Just like I can't change a bunch of people's opinion on C#/.NET because it's from Micro$oft. We can agree to disagree.
Emphatically no. PHP is the ford escort of programming (needing regular maintenance, rather insecure but easy and simple to drive and control). Unlike the Toyota Corolla which is really REALLY reliable, consistent and much much more secure.
(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 think the author means the Nissan Versa of programming. Corollas are quite a bit more expensive and hold value longer. But both are very useful.
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.
Having used many of the 'Toyota Corollas' to build web apps, do any others feel a little pang of frustration that, here in 2025, teams have the choice of using TypeScript on both the client and the server and choose not to?
"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.
In my anectodotal experience, PHP is much, much more performant, even before I moved to Frankenphp - which is so much better than Express, it isn't even a joke.
And PHP is much easier to read and handle when the project gets larger. And more secure, as you aren't forced to rely on all these NPM packages (we use Composer, but nothing like the way we used NPM. PHP really comes with almost anything you need built in - and even if you use Laravel its still not a pyramid).
I have read through all the comments, and I really don't get it - I use Node and PHP a lot, and quite a bit of Python. Not to much experience with Go or Rust, but some with Java.
IMO, There is nothing that competes with PHP in speed, security (for web stuff at least), or ease of writing for the web.
My main gripe with TypeScript (and node/JS) on the backend, is that it's not trivial to scale horizontally. You start node and it's a single event loop.
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?
Its unclear if Typescript has comparable backend ecosystem. For JVM you can find reliable, somehow well documented, widely used library for most of backend stories: driver for that database, SOAP-XML lib with support of niche security protocols needed for integration with some finance/healthcare institution API, logging, monitoring, etc.
But you kind loose the simplicity of these other languages. Like not needing a complex build setup, the unreliable dependencies. Compare to Django, Ruby on rails and Laravel. JavaScript doesn't have anything as feature complete
The Corolla was simple but very well designed; it's manuals were used in classes teaching car mechanics.
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.
It teaches you the value of getting things done in a simple and straight forward way. I'm working with people who have grown up with Java and it shows. They tend to overcomplicate everything.
Dude, you’re totally right. Common Lisp is the Bagger 288 of programming. It's this absolute unit of a machine, designed to literally eat mountains. And when the first mine shut down, it didn’t retire or rust away. They drove it across Germany at 2 miles an hour, moving villages and flattening everything in its path. People came out just to watch it roll by like it was some kind of steel god. Eventually it got a new job at another mine, still doing work nothing else could touch.
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.
I have programmed using Php for at least 25 years. While PHP did start off being quite poorly designed for security, newer versions of Php and also the PHP frameworks like Laravel, Yii etc have become quite sophisticated over the years and is a really good alternative to frameworks like Rails etc.
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.
I always found Hack interesting. It's PHP slowly transformed step by step into something closer to Java (Java isn't as bad as new grads claim, compared to PHP it's actually great). It's pretty much exclusively used at Meta.
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.
I dabbled in Hack and HHVM several (almost 10 now??) years ago but haven't kept up. My understanding was that PHP8+ now includes the improvements that Hack brought, making the leap to Hack less interesting/valuable. Is that not the case?
I'm quite surprised that the article doesn't mention Laravel.
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.
My day-to-day work now is mostly Python and Vue, but PHP was my bread and butter for almost 20 years and to this day probably still probably one of my favorite languages just because I am still so familiar with it. There's something to be said for knowing all the traps and rough spots, and knowing how to avoid them.
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.
There's few programming environments I hated more viscerally than PHP. Yes, it got the job done. But thank God I never had to maintain that giant kludge of duct tape and elastic bands.
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.
Even after years of not building anything substantial with PHP, it still maintains a soft spot in my heart. I remember how it felt writing PHP code ~15 years ago and feeling so productive. I felt that I could do anything with it. Then the Laravel framework came around and made that experience at least an order of magnitude better.
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.
The corolla is wonderfully designed for its main purpose- a cash cow in its segment. PHP just worked, but it is not well designed. The reason it is somewhat simple to deploy is because everyone and their dog had to learn how to deploy it - compared to deploying a Go binary it is miserable.
I spent a few years trying to work on legacy PHP systems. Would never take another job using it if I had any choice. Most large tech companies do not have large PHP codebases, and most small ad hoc PHP codebases are awful to work with (in my experience), so the intersection of "uses PHP" and "higher quality software engineering" is pretty small. I won't say it's an empty set, but it's a small opportunity space. Meanwhile, the odds of having to work on really awful codebases are... high.
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.
What people who don't work on content sites don't realize is that from 10 best CMSes like 7 are written in PHP. And i don't even mean Wordpress. It's stuff like Craft, Kirby, Twill, October, Bolt, Statamic, Bookstack, Dokuwiki, Mediawiki… there few OK ones in Javascript but they lack features and maturity.
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.
The fact that people are ignoring the degree to which human factors are responsible for making the Corolla what it is in people's minds is disappointing albeit 100% predictable.
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?).
I don't think this analogy holds. Corollas are popular because they are good cars. People make individual choices to buy them and are generally satisfied with that choice long term. Corollas are not a regretful product choice.
PHP is more like a Lime scooter. Trivially easy to start with, gets going quickly, significant chance of causing brain damage.
I think the allure of javascript is the idea that you can use sparse server resources and have your software mostly run on the client side.
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.
That's certainly one appeal of JavaScript, but also consider that the client being a browser means you can run JavaScript on uncountable numbers of devices. And since the introduction of Node there's also the appeal of being able to write in one language for both server and client.
I think that wordpress probably had a big impact on PHP's success.
It's on 40%+ of sites. It was set up in a way for people to make modifications to actual code (or at least see). Hosting providers had to make sure PHP was preinstalled and useful.
php is so boring and it works. i am so surprised to not see more jobs on HN for it. I don't really consider myself a PHP programmer, it just, what we use I dont think about it, almost ever.
Whenever I read HN talking about PHP I am reminded of the Gell-Mann Amnesia effect. The level of discussion on the topic is abysmal, compared to (I guess perceived?) the discussion on other topics.
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.
Right, I think this gets at the biggest issue with "judging languages."
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.
Java is more akin to the Corolla. Utterly insipid (by design), lacking in refinements compared to competitors like the Mazda3, and made for people who just see it as a way to get from point A to point B.
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.
This is very ignorant of a modern Corolla in a lot of ways.
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.
I think it's a pretty good analogy - the only programming language that I think might be a better one would be Go.
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.
> Toyota Corollas are exceptionally well-engineered cars. The thing is, they're engineered for convenience, reliability, and affordability.
Say that to the half a dozen recalls my 2007 Toyota Corolla had. The constant sensor issues. And a slew of other issues, like the very well know chain issues.
Well engineered is something that really does not fit with my 2007 Corolla. Yes, my 1992 Corolla was a tank, but not the "modern" 2007 version.
> affordability?
You mean the 33.000 euro that a base model Corolla now costs??? I think people have been living in the old corolla's mindset from the 90's because modern Corolla's are expensive cars.
Worst of all, its not even the good hybrid. A BYD SUV with 1080km actual road range, with full loaded electronics, solar roof, the works was 36.000 euro here. When a not big hatchback is that expensive, vs a freaking SUV...
You sound very sad that your Corolla isn't good. I would get rid of it, if I were you.
However, 6 issues with a 20 year old car doesn't sound that bad to me.
Edit: By the way, you can easily get a 2023 Corolla for less than 23k euro.
If I want to buy a car today, preferably electric, that is like the corollas of the 90s, what should I buy? Not having customer hostile features like DRM or anti repair anti features is a part of this.
Subarus are very reliable these days. They only have one EV model right now I think, but another is coming.
This just isn't the case anymore, Toyota isn't that company.
Right now they're just producing cars that are better engineered and it isn't because their pieces are conservative. Their technology isn't lagging, in fact, it's ahead in this particular area of COMMODITY cars.
Even that being granted, Toyota is an integrator. They don't have vertical control of their supply chain. They're not as far ahead or different from other companies, they just have different priorities and a larger war chest to draw from.
Luxury cars are ahead but that isn't in contention.
I'd also argue that Go is the better analogy because it also eschews bells and whistles that would add complexity to it. While Java the language was indeed intended to be fairly unexciting, the JVM came with a bunch of complexity that took quite some time to tame (e.g. it took a while for JITing to really get the performance to a reasonable point, and GC longer still).
The modern Corolla, like most competitive cars, is a good, safe, high-quality, reliable car. These qualities aren't at odds with being "insipid". The Corolla interior feels utilitarian, its features are spartan, and the driving dynamics are... behaved.
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 characterization was still incorrect.
The Corolla has better implementations of modern features than the Mazda3, it's simply not as flashy.
> The Corolla has better implementations of modern features than the Mazda3, it's simply not as flashy.
As someone who owns and drives a 2024 Mazda 3 PP daily, and test drove and compares notes with my neighbor who dailies a 2024 Corolla XSE Hatch, I don't think this characterization is accurate at all. I have nothing against the Corolla, but the Corolla is lacking in /many/ ways compared to the Mazda3.
One simple example is that my Mazda3 has a heads up display that puts car safety system data, turn-by-turn navigation (from android auto or apple carplay or built-in nav), speed data, and vehicle data into the HUD so I never need to look down at the dash.
Another example is that while the Mazda3 has a touchscreen in the center console, there are physical controls for every functionality with good tactility and Mazda has chosen to disable the touchscreen once you exceed 5MPH (by default), ensuring you aren't distracting yourself using a touchscreen while on the highway.
As to all those automated safety systems, most of those are government mandated and every car has them. I do agree that Toyota does a better job than most manufacturers, but to my knowledge there is not a single system on my neighbor's 2024 Corolla that isn't also on my 2024 Mazda3...
Where the Corolla wins in my opinion is actually its simplicity. The Mazda3 has too much effort in its interior, but also somehow not quite enough, and it ends up with it being very comfortable to drive except it sometimes has rattles in panels, which is not a very premium experience. The Corolla has a much more basic interior, very bog standard, but it's also flawless in executing being bog standard.
As far as driving dynamics, it's no contest, the Mazda3 is significantly better. The only Corolla with great driving dynamics is the GR Corolla, but that's really a completely different sort of car.
The word "insipid" doesn't really have anything to do with being a "good implementation" or not.
Right, which is why you're focusing on it rather than the two other claims made.
>lacking in refinements compared to competitors like the Mazda3, and made for people who just see it as a way to get from point A to point B.
Of course, I also disagree that it is insipid, that's also inaccurate vis-a-vis modern Toyota, but that's a different discussion.
In context, it appears they are using the word “refinement” to refer to enthusiast taste. They’re not saying Toyotas are crude vehicles. Your opinion notwithstanding, their statement is very supportable, both in industry reviews and in both brands own value proposition.
The sibling comment is defending what Java has grown into also.
I just had a rental Corolla in Europe. It had a lot of driving assistance features, and they're all absolute dogshit (and, I think, mandated by EU regulators). It's a pain in the ass to turn them all off every time you start the car, and I don't know how any drives these cars with them enabled.
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.
So, the interesting thing about this is that I've heard it before but I didn't really understand it until I drove with my father-in-law, who drives like a mental patient.
His cluster was flashing constantly, warning him of imminent doom. And it was warning him correctly, because he was accustomed to driving incorrectly.
Of course, he hadn't been in an accident in some time - but this was more thanks to luck of the draw, his ability to ride the razor's edge, and other people's attentiveness.
I own a modern Toyota and I am never hassled by the safety features.
I own it because I just don't care about cars and it's that car.
| His cluster was flashing constantly, warning him of imminent doom. And it was warning him correctly, because he was accustomed to driving incorrectly.
In the cars I've driven, the cluster flashes all happen regardless of how you drive. The speed limit changes and crosswalk indications and so on, will always trigger. (Unless you disable them -- however, in a foreign country, where I don't understand the customs quite as well, I was willing to tolerate the annoyance to reduce my odds of running afoul of the local constabulary).
The one exception is the speed limit indicator continues to flash if you dare exceed the posted (or, sometimes imagined) limit.
It’s possible that my car (NA market 2023 Nissan EV) just isn’t as “vocal”, but as a relatively new driver I’ve found myself changing my habits to not anger the machine. These days it rarely gripes at me.
Arguably some of them are useful (speed? as much as I hate to say it).
I don't think the "don't drive anywhere near the edge of the lane" is a good practice. There are lots and lots and lots of good, pro-safety reasons to come near the edge of a lane, or even cross over it, and I'm not sure it's helpful to train drivers to stay in the geometric center of the lane. For example it's one of the things I hate about autopilot the most, the car tries too aggressively to center itself.
You definitely tried Mazda long ago :)
No, I'm aware of both involved technologies the implementations.
I test drove the Mazda3 for my kids and it had some faux-luxury accoutrements but fundamentally it was an inferior car: the technology implementation was worse.
Mazda hasn't invested in drivetrain implementations so they license Toyota's. Mazda hasn't invested in ADAS software so they barely try. Mazda hasn't invested in a decent suspension implementation so their 3 line uses some god-awful torsion beam garbage that feels completely unrefined and consumer.
Bad.
> Mazda hasn't invested in drivetrain implementations so they license Toyota's.
??? Mazda has their own drivetrain development, there is nothing in a Mazda3 that is shared with a Toyota. The only company sharing drivetrain with Toyota is Subaru and BMW via their joint ventures on the BRZ/GR86 and the Z4/Supra.
> Mazda hasn't invested in a decent suspension implementation so their 3 line uses some god-awful torsion beam garbage that feels completely unrefined and consumer.
Mazda uses a torsion beam rear suspension on the Mazda3, that is true. While independent and multi-link suspensions /can/ be superior handling, it relies on having adjustability in the suspension arms to allow you to set your geometry to match your expected conditions and the tires you're using, which is to say that it's basically irrelevant in a commodity road-going vehicle, most of which offer no adjustment in the rear or toe-only adjustment. I say this as someone who raced cars as a hobby, and invested the time/effort/money to learn at least as much about suspension design as someone who did an undergrad in MechE, modeled my racecar's suspension in software, and worked with a shop to develop and produce custom suspension arms with full adjustability to match my ideal geometry.
Despite the technically "worse" torsion beam suspension in the rear of the Mazda3, it handles better than a Corolla XSE on a curvy road.
EDIT: I stand corrected, Mazda licenses the RAV4 Hybrid drivetrain for the CX-50 Hybrid crossover. Which is of course super-relevant to the Mazda3, a totally different vehicle, which almost anyone who cares about the drivetrian buys with the 2.5L turbo motor and PP so they get AWD, but hey who's counting.
I'd have simply deleted the post if the driving force of it were corrected.
Mazda licensed the drivetrain because they're a small company without much development going on. They can't really make anything good.
Their racing pedigree and long standing in the hot hatch category disagrees with you, so do the basic facts of the matter.
You've now written yourself off as an idiot with an axe to grind rather than any form of good faith interaction.
Modern Java is quite good these days, no? Type inference, fibers, text blocks, records...
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.
Pretty funny you mention Java 8 as a negative example, I remember it being widely heralded as a step in the right direction that was a long time coming and a breath of fresh air.
I think they just mean that newer versions are further steps in that direction, not that Java 8 was a step the wrong way.
Yup. Java 1.8 is humongous leap to the right direction.
The JVM and its ecosystem are the best thing about the Java platform. Not the language, i dont even use it anymore and i am nearly 100% JVM based. But even then its still not horrible. it's just that there are better options like Scala.
Great analogy, horrible example in the analogy heh. (Hate to nitpick)
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.
Java is more like the Honda. It's literally everywhere, ultra reliable, sufficiently boring technology that people can't stand to look at it because it simply makes no statement about anything, and despite all attempts to replace it or dethrone it, it continues to excel and grow.
You are great with analogies.
Can you tell me which car is Python, so I can add it to my shopping list?
> 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.
A Mercedes Benz sprinter. It’s being used for everything. From simple delivery to nerdy camping. Not the fastest, but has loads of modularity and can work as a daily, work truck or leisure.
I'd say the sprinter is more like Fortran. You use it when you need to move around lots of stuff and although it's quite fast on its own, you would drive it neither for fun nor when you only have a few things to move around.
Long gone are Days that the Corolla was bare bones and even then it was better than what the Mazda 323 had to offer
I drove a 2009 Corolla SE for 3 years of my life. Its _only_ redeeming quality was that maintenance and repair bills were minimal. Besides that, it was sluggish on the highway, handled like a shopping cart, unstable at 140 km/h, and had an interior that would never let you forget that you’re poor.
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).
Java is more like Ford F-150 than Corolla
PHP did well for ONE reason: it was really, really, really easy to deploy. This was, of course, underestimated by programmers in the know, but I remember first getting into web dev, and I could start putting real programs (!!!) on the web, in minutes!
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.
Can't upvote this enough. Zero friction is like superconductivity: a huge, qualitative jump. If doing the key thing is trivially, absurdly easy, people will readily excuse whatever shortcomings the product may have, be it a specialist tool like Docker, or a mass-audience service like Twitter.
(Do one thing, but do it well; sounds familiar?)
Yep. I was doing Perl CGI scripts at the time, and you often ran into deployment issues somewhere along the line of uploading the scripts via FTP, making them executable, and setting the permissions on any files that needed to be written. Building PHP into the web server instead of external CGI scripts eliminated a lot of that, so it was more likely to just work without some back-and-forth with a web admin to get things setup right for CGI to work. It wasn't the language, but the way it was deployed.
Yes! This was huge. You could go from coding to uploading to refreshing your application as fast as you could perform those actions. And don’t forget, with Perl CGI, you had to output the right Content-Type header (and two carriage returns) at the top of your outputted page content for the browser to even parse it correctly.
of all the reams of php snark the internet has produced, one line has stuck in my mind - "any fool could write php, and many did". both because it was funny, and because that lowered barrier to entry is actually a good thing. I want "any fool" to be able to program and if php supports that goal, more power to it.
Exactly. I remember that at the time, the alternative was the nightmare of setting up tomcat, Jboss, etc and dealing with all that bullshit.
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.
PHP is so hard for me to describe. I used it a lot in the late 90s when we were migrating off mod_perl because it was a great way to add dynamic data to otherwise static pages, and no one really knew how to develop large sites yet. We were making it up as we went along. But ye gods, the language was bad. “A poor craftsman blames his tools” and all that, but imagine a screwdriver with 2 handles and 3 tips projecting at random angles. Sure, you could assemble an IKEA desk with it, but would you want to? And would you look suspiciously at anyone who claimed to love that weird screwdriver when the equivalent of a Snap-On was available for free from the same place they got the weirdo?
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.
A fractal of bad design, if you will.
For folks unfamiliar with the reference: https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
Other languages caught up with PHP.
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.
Its HTML-inline nature is the entire reason I ever used it. At some point in the early 2000s I came across PHP’s include, which felt like the piece of HTML that’d always been missing. Suddenly I no longer had to manually keep all that header/nav/footer code in sync across N pages! Magical.
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.
The author makes a fair point that the language is no longer the fractal of bad design it was in 2009, but doesn't make the case for starting a green field project with it in 2025.
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.
> What does it do better than other languages?
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
This is often the fastest way to solve your immediate problem, at the cost of making everything harder to reason about. PHP persists nothing between requests, so all data that needs to persist between requests must be explicitly persisted to some specific external data store.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.
I hadn't really thought about PHP through this lens. But it's so much a part of where it came from as a preprocessor for text. It was a first-class part the stateless design of the OG internet. Now everyone wants all things persisted all the time, and leads to crazy state problems.
Also because it's a language for the web, and HTTP is stateless.
But that's Python, no?
Edit: Oh, you showed an example against Python! Now I get it!
I think the advantages are pretty much what they always were.
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.
I think #1 has been outdated for a long time. FTP or copying files through CPanel hasn't been more convenient than workflows like `fly deploy` where you don't even need to know about a remote file system nor about a server that's already running. And php-fpm being called by nginx is also more complicated than just "node script.js" or running a compiled Go binary.
While I never actually wanted it, #2 was kinda cool spiritually. Same with CGI or a Cloudflare edge worker.
People who manually copy files are not going to use anything more sophisticated. It was not what I had in mind and I do not think its a fair comparison, nor is a pricey and proprietary platform.
These days I imagine people are more likely to be using git pull or rsync anyway.
> And php-fpm being called by nginx is also more complicated than just "node script.js" or running a compiled Go binary.
Apache with mod_php is still an option AFAIK. It is also definitely easy to find everything pre-configured on share hosting. Then there is FrankenPHP.
Might not be the easiest option for everyone, but it is going to be for some people.
I think 1 is a myth. It’s easy to deploy as long as you don’t care about atomic updates, like the newly uploaded version of foo.php importing bar.php which hasn’t been uploaded yet. Solve that, say with a DAG of which files to upload in which order, and it’s no longer easier than anything else.
Like many other things, PHP makes it easier to do the wrong thing than other languages which make you do the same thing correctly.
I worked at a place that did git pull as the release process - it was a big site but I never heard of there being any issues (though the code was on life support so no huge changes were happening).
They switched to blue/green deploys for the new site (which I suspect was done at the server level, not with symlinks or the like).
> It’s easy to deploy as long as you don’t care about atomic updates
Does that matter if a bit of downtime is acceptable?
No, but it's moving the goalpost quite a bit. "Just copying a bunch of files around" is definitely easier than, say, deploying a new Docker container containing a Python app or a Rust or Go binary, etc. But neither is it nearly so robust.
Wouldn't that be better solved by uploading everything to a v2 directory and then renaming the directories?
Maybe. You could probably get pretty far with atomically moving a symlink so that the filesystem view always looks at either all the old or all the new files.
However, even that doesn't handle in-flight requests that have their view of the files swapped out from under them. Yes, that's a small time window for an error to happen, but it's definitely not instantaneous.
The safer solution would be to update the server config to point at the new directory and reload the webserver, but now you're way past just uploading the new files.
Its pretty instant. Hitting inflight request still finishes with the old version since the code thats run is already in memory.
I dont think its very different from changing proxy to point to different port.
That's not quite right. Imagine some (horrid) code like:
such that there's a significant interval between the request being spawned and it later including another file. The duration of the query is the opportunity for 'old.php' to go away, which would cause a 500 error.The difference is that you can have 2 ports listening at once and can close the first once it's drained of connections.
There's no fundamentally safe way to upgrade a bucket-of-files PHP app without tooling complex enough to rival another language's deployment.
I don't believe thats how PHP works (atleast not anymore). When the request is made the code is first compiled to opcodes and only after that's done the opcodes are run. In most production environments these opcodes are even cached so even if you delete the project it will run.
In any case you would have to hit some few milisecond window in this opcache generation to break single request but even that might be unlikely thanks to how filesystems read files?
In that example, I'm pretty sure that the 'require' line is compiled to opcodes, but not executed, until that line is reached. Supporting evidence: https://stackoverflow.com/questions/37880749/when-is-a-php-i...
So if there's a 10 second gap between the start of execution and the 'require' line being reached and evaluated, then any incompatible changes to the file being required within that 10 seconds will cause an error.
That actually makes sense because the codepath could be huge with huge surfaces of unused code.
With OpCache this could be solved so i guess lessin for me - deploy like this with opcache on.
Well, now you just have to manage cache invalidation. Piece of cake!
I kid, I kid, but seriously, now you have a different set of issues.
This is how its done in many deploy tools in PHP world with help of git. I think it works so well nobody even thinks about how it works.
That's a perfectly reasonable approach, so long as you understand why it's a risky operation and can tolerate the consequences, including customers seeing errors in their browser. If that's OK for your use case, then rock on! If you can't tolerate that, then you have to have switch to a more complex upgrade system, like blue-green deploys behind a load balancer or such. In other words, the deployment method of a Rust or Go or Python or Java app.
In a sense thats blue-green deployment just on filesystem level? PHP is always run behind proxy/webserver (mostly ngnix nowdays)
But you are right there is no reason why you couldn't have two instances of the php app runing and switch between them. For some reason the PHP deployment services i've used seem to use the filesystem approach and i doubt it's laziness or incompetence.
I'd content that it's out of ignorance, and I don't mean that in a mean or nasty way. I've heard lots of pushback from PHP devs that it's way easier to update than sites written in other languages are, but I think it's genuinely due to a lack of understanding of why those languages recommend other upgrade processes. Those processes solve real, genuine problems that also affect PHP, but they're dismissed as overkill or enterprisey or overly complicated.
And all that may be true for a trivial website. If you've written a personal project with 10,000 hits per year, YOLO. Go for it. The odds of it affecting one of those users is vanishingly tiny, and so what if it does? But if you're hosting something like a Wordpress site for a large company with lots of traffic, it's crucial to understand why "just rsync the files over" is not an acceptable deployment method.
Sorry but we were not talking about “rsyncing the files over”. We are talking about what services that i've used like Forge or Ploi do where you deploy project into separate folder and then switch symlink. You can even roll it back.
I have a feeling you want to dunk on poor dumb PHP developer but like Forge is by the people who created Laravel. I believe they would put some thought into it. Maybe just maybe small chance of one bad request is not such a bad deal.
It is literally exactly the same issue, just with slightly less of an error window. I don't think those devs are poor and dumb, but I do think it's likely they've been working in environments where production errors are more tolerated than in other environments.
> Maybe just maybe small chance of one bad request is not such a bad deal.
If your company is OK with that, seriously, sincerely, right on! Keep doing this and move on to other problems.
I had thought about it and you are just pulling my nose.
If you have very long database query and you update your app in middle of it using blue-green load balancer you get to same production error. It is the same thing just implemented slightly differently because of PHP characteristics allow this and with different systems you have to use different strategy.
So yeah have good feeling about us PHP devs having bad deployment strategies.
That is… exactly wrong. I encourage you to consider why that would not be the case.
It is not the same issue, due to how opcache works. No one remotely competent runs PHP without opcache in 2025.
The comparison would be towards other languages in its class: Python, Ruby, Javascript.
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.
Maybe it is a good base for vibe coding since there is a lot of code around?
There's a lot of bad code around, and I think the protections of a (good) static type system are likely of particular use in that scenario. I'd be interested in reading a test of that prediction if anyone has done it (but not interested enough to do it myself).
Honestly the author doesn't even make a great case that PHP has improved since 2009. His arguments mostly seemed to be "don't use the old busted way, there's a better way now". But if you have to go out of your way to remember to not use the old busted way, sooner or later you will shoot yourself in the foot. Having good defaults matters, and the author seems to ignore that.
I think you're underestimating how hard it is to shoot yourself in the foot when using the PHP language defaults and the defaults for any modern PHP framework - it's genuinely hard to do.
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 think you're underestimating how hard it is to shoot yourself in the foot when using the PHP language defaults and the defaults for any modern PHP framework - it's genuinely hard to do.
Agreed. I remember happily starting a couple of new PHP projects in the last decade and the frameworks felt like working in any other programming language.
I’ve used PHP for more than 20 years. It’s my “go-to” language for the backend. I’m not a server programmer, and PHP is fast, well-supported, and, if you’re a decent programmer, you can write robust, secure, performant servers in it.
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.
I wonder where this graph gets it's data from. Scala sitting at 4.6 percent and python at 1.2 percent is not what I would expect, but my perception of the industry could be totally off.
I wonder where this graph gets it's data from
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 think that we tend to have personal biases, depending on the context of our relationships and professional cultures.
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.
> server-side programming languages for websites
Maybe because most websites are Wordpress websites.
The PHP thing is believable, I'm just still stuck on scala vs python based on my observations from working in the industry and being part of the hiring process for both of these languages. Perhaps it's because I work in B2B SAAS where these products aren't always necessarily exposed to the public internet.
Yeah this feels off, though if its assessing all/many sites it could make some sense, versus assessing the top N sites by traffic.
See my note about the pron industry.
Those sites get a lot of traffic.
I did notice that JavaScript (which may include TypeScript) is going up, but so is Java, and that Java is still higher than JavaScript.
I've also used it for about 20 years now. Surprised you haven't warmed up to it. It's perfectly fine. I still use it for scripts from time to time even though I prefer TS now because it's got some good stuff built-in.
I don't hate it, but I've never really gotten excited about it, like I did for C++, or Swift.
i feel like that graph just shows wordpress dominance (43% of all websites) and a bit of joomla (2%) and drupal (1%), which are all php based.
The article loses impact due to the way the author keeps self-conciously mentioning how the "PHP haters" are wrong instead of just explaining the possible usecase for PHP better.
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.
Php developers are easy to find and cheaper than the alternatives, that alone seals the deal for many businesses
I wouldn't trust a PHP developer who wasn't able to figure out how to become a JavaScript developer.
… who are also relatively inexpensive and easy to find?
I often wish it weren't the case as much. There's a massive cassum the size of the Grand Canyon between the majority of JS devs and good JS devs that understand the language, and have a good grasp of software craftsmanship. And that doesn't mean stuffing JS based projects with "Enterprise" patterns that don't make sense in the platform being used.
JS devs who started around or just after covid are everywhere. JS devs with 10+ years of experience are a small fraction of the market at this point. JS devs with any number of years of experience who also understand JS (or even just CS in general) well are a minute fraction of JS devs.
Normally PHP developers are competent in Javascript but try to avoid it due to the clusterfuck that javascript is, especially the ecosystem.
‘laughs in left-pad’
Not everyone wants to become a JavaScript developer.
Yet they became a PHP developer. Go figure.
But I can deploy a decent sized Laravel app in about 2 days... I would need to learn the javascript equivalent.
I fell in love with PHP in kind of a funny way (and looking at my career now, was probably an indicator I was destined for what I do now) because it saved me during college.
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.
Work wise that would mowt likely be Laravel or Symfony.
Aren't Corollas reputed to be functional and reliable? Seems like a weird analogy.
Having always referred to Java as the Honda Civic of language-ecosystem, I take offense to this claim that PHP is the robust, cheap, and reliable workhorse.
Functional and reliable, but often maligned by Real Car People for being boring and underwhelming.
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.
Yeah. I had a 1990 Corolla from its best selling car in the world period and it was functional reliable and designed with a lot of care even if it was a simple design compared to fancier stuff.
PHP is a DeLorean. I think I encountered 10 segfaults in it within 1 year which is a complete joke. This was only two years ago.
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.
> I think I encountered 10 segfaults in it within 1 year which is a complete joke.
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.
Yeah I don't remember last time I saw PHP segfault. And I have clients that easily sum billion+ requests per month in PHP alone.
I will never give PHP any serious thought. Back in the mid 2000s I started an app hosting company as a side-gig. I started out hosting FogBugz (bug tracker) because Fog Creek Software only offered it as a self-hosted option. I had zero problems for 9 months - it was a Microsoft ASP based app (IIRC). Then I decided to host a helpdesk app called HelpSpot. At the time it was a one-man startup and he didn't offer a SaaS option either so he was happy to send customers my way. The software itself was fine (and it's still around) but it was a PHP-based system and no matter how up to date I kept the servers, the PHP servers got hacked over and over due to PHP's complete disregard for security at the time. My claim to fame is I hosted Twitter's first helpdesk. I got tired of getting home from work and having to rebuild servers almost weekly, so I "sold" my fledgling little sidegig for $2k. Screw PHP.
While it certainly could have been PHP, the amount of poorly coded PHP back then was more often the issue.
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.
Sorry, I don't buy it, PHP was complete and utter garbage from a security standpoint at the time:
https://www.cvedetails.com/vulnerability-list/vendor_id-74/P...
https://www.cvedetails.com/vulnerability-list/vendor_id-74/P...
Sure, your experience sucked. But by all means let's continue to look down our noses at a programming language based on mistakes made 20 years ago.
I have plenty of other issues with PHP that haven't been addressed in 20 years. There are plenty of other better tools out there. You don't have to choose them, and I don't have to choose PHP.
Sure, of course you don't.
But when the only issues you can actually name are 20 years old and based on one specific implementation, rather than PHP as a language, it doesn't reflect poorly on PHP. It reflects poorly on your critical thinking skills—or, at the very least, your ability to persuasively argue.
I don't have to enumerate all of PHP's shortcomings to justify my position.
No one's asking you to.
But you call it out as "garbage", claim that you—personally—have "plenty of other issues" besides the ancient history you specifically cited, but do not elaborate and expect us to just take your word for it.
You're asking us to value your low opinion of it, but you're not giving us any good reason to do so.
Look, it's ok - you guys love PHP and I'm sure it has some merits. I still have my same old opinion of it. Just like I can't change a bunch of people's opinion on C#/.NET because it's from Micro$oft. We can agree to disagree.
Emphatically no. PHP is the ford escort of programming (needing regular maintenance, rather insecure but easy and simple to drive and control). Unlike the Toyota Corolla which is really REALLY reliable, consistent and much much more secure.
(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 think the author means the Nissan Versa of programming. Corollas are quite a bit more expensive and hold value longer. But both are very useful.
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.
Having used many of the 'Toyota Corollas' to build web apps, do any others feel a little pang of frustration that, here in 2025, teams have the choice of using TypeScript on both the client and the server and choose not to?
"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.
There are still some backend people who care about performance, or so I’ve been told
Is PHP more performant? That'd be surprising to me, given how many eng hours have been invested in V8
PHP is decent enough - if Opcache is enabled and configured correctly then it does the job. I haven't tried the latest JIT stuff though.
The viable alternative is not PHP, its almost any sane compiled language.
In my anectodotal experience, PHP is much, much more performant, even before I moved to Frankenphp - which is so much better than Express, it isn't even a joke.
And PHP is much easier to read and handle when the project gets larger. And more secure, as you aren't forced to rely on all these NPM packages (we use Composer, but nothing like the way we used NPM. PHP really comes with almost anything you need built in - and even if you use Laravel its still not a pyramid).
I have read through all the comments, and I really don't get it - I use Node and PHP a lot, and quite a bit of Python. Not to much experience with Go or Rust, but some with Java.
IMO, There is nothing that competes with PHP in speed, security (for web stuff at least), or ease of writing for the web.
My main gripe with TypeScript (and node/JS) on the backend, is that it's not trivial to scale horizontally. You start node and it's a single event loop.
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?
Its unclear if Typescript has comparable backend ecosystem. For JVM you can find reliable, somehow well documented, widely used library for most of backend stories: driver for that database, SOAP-XML lib with support of niche security protocols needed for integration with some finance/healthcare institution API, logging, monitoring, etc.
But you kind loose the simplicity of these other languages. Like not needing a complex build setup, the unreliable dependencies. Compare to Django, Ruby on rails and Laravel. JavaScript doesn't have anything as feature complete
The Corolla was simple but very well designed; it's manuals were used in classes teaching car mechanics.
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.
It teaches you the value of getting things done in a simple and straight forward way. I'm working with people who have grown up with Java and it shows. They tend to overcomplicate everything.
Common Lisp is the Bagger 288 of programming!
https://www.youtube.com/watch?v=azEvfD4C6ow
https://en.wikipedia.org/wiki/Bagger_288
Dude, you’re totally right. Common Lisp is the Bagger 288 of programming. It's this absolute unit of a machine, designed to literally eat mountains. And when the first mine shut down, it didn’t retire or rust away. They drove it across Germany at 2 miles an hour, moving villages and flattening everything in its path. People came out just to watch it roll by like it was some kind of steel god. Eventually it got a new job at another mine, still doing work nothing else could touch.
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.
I have programmed using Php for at least 25 years. While PHP did start off being quite poorly designed for security, newer versions of Php and also the PHP frameworks like Laravel, Yii etc have become quite sophisticated over the years and is a really good alternative to frameworks like Rails etc.
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...
I always found Hack interesting. It's PHP slowly transformed step by step into something closer to Java (Java isn't as bad as new grads claim, compared to PHP it's actually great). It's pretty much exclusively used at Meta.
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.
I dabbled in Hack and HHVM several (almost 10 now??) years ago but haven't kept up. My understanding was that PHP8+ now includes the improvements that Hack brought, making the leap to Hack less interesting/valuable. Is that not the case?
PHP caught up with Hack's performance, but it still doesn't have many of its features, notably generics and async/await.
I'm quite surprised that the article doesn't mention Laravel.
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.
My day-to-day work now is mostly Python and Vue, but PHP was my bread and butter for almost 20 years and to this day probably still probably one of my favorite languages just because I am still so familiar with it. There's something to be said for knowing all the traps and rough spots, and knowing how to avoid them.
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.
There's few programming environments I hated more viscerally than PHP. Yes, it got the job done. But thank God I never had to maintain that giant kludge of duct tape and elastic bands.
"vibe coding" is also a Corolla of programming, the Adam Corolla
https://www.youtube.com/watch?v=iNMrQUF6Fvc
Couldn't agree more.
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. :)
How do you keep them secure?
What is the significance of 'scene'?
Even after years of not building anything substantial with PHP, it still maintains a soft spot in my heart. I remember how it felt writing PHP code ~15 years ago and feeling so productive. I felt that I could do anything with it. Then the Laravel framework came around and made that experience at least an order of magnitude better.
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.
The corolla is wonderfully designed for its main purpose- a cash cow in its segment. PHP just worked, but it is not well designed. The reason it is somewhat simple to deploy is because everyone and their dog had to learn how to deploy it - compared to deploying a Go binary it is miserable.
I spent a few years trying to work on legacy PHP systems. Would never take another job using it if I had any choice. Most large tech companies do not have large PHP codebases, and most small ad hoc PHP codebases are awful to work with (in my experience), so the intersection of "uses PHP" and "higher quality software engineering" is pretty small. I won't say it's an empty set, but it's a small opportunity space. Meanwhile, the odds of having to work on really awful codebases are... high.
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.
What people who don't work on content sites don't realize is that from 10 best CMSes like 7 are written in PHP. And i don't even mean Wordpress. It's stuff like Craft, Kirby, Twill, October, Bolt, Statamic, Bookstack, Dokuwiki, Mediawiki… there few OK ones in Javascript but they lack features and maturity.
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.
Sorry, that's an insult to Toyota and Corolla. PHP is at best a Nissan car.
In 2024, I asked “Can Raku replace PHP?”
https://rakujourney.wordpress.com/2024/09/15/can-raku-replac...
If you are wondering, Raku can replace PHP literally…
BUT that’s beside the point. Just my sense of -Ofun getting out of hand.The corolla may be boring but it's the well designed kind of boring. I think Python or maybe Java is the Corolla of programming.
PHP is boring and poorly designed. Maybe more like some of the very old Eastern European cars.
The fact that people are ignoring the degree to which human factors are responsible for making the Corolla what it is in people's minds is disappointing albeit 100% predictable.
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?).
I don't think this analogy holds. Corollas are popular because they are good cars. People make individual choices to buy them and are generally satisfied with that choice long term. Corollas are not a regretful product choice.
PHP is more like a Lime scooter. Trivially easy to start with, gets going quickly, significant chance of causing brain damage.
PHP being a Corolla would mean my 20 year old PHP application would run today with no changes. This is not the case.
The Trabant of Programming
From reading the comments you would think this article was actually about cars.
I think the allure of javascript is the idea that you can use sparse server resources and have your software mostly run on the client side.
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.
That's certainly one appeal of JavaScript, but also consider that the client being a browser means you can run JavaScript on uncountable numbers of devices. And since the introduction of Node there's also the appeal of being able to write in one language for both server and client.
I think that wordpress probably had a big impact on PHP's success. It's on 40%+ of sites. It was set up in a way for people to make modifications to actual code (or at least see). Hosting providers had to make sure PHP was preinstalled and useful.
Before I started a different career, I made lots of money as a PHP developer.
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.
I still think the way you mix php and html is the best. It’s not php + jinja, it’s just php.
php is so boring and it works. i am so surprised to not see more jobs on HN for it. I don't really consider myself a PHP programmer, it just, what we use I dont think about it, almost ever.
Whenever I read HN talking about PHP I am reminded of the Gell-Mann Amnesia effect. The level of discussion on the topic is abysmal, compared to (I guess perceived?) the discussion on other topics.
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.
If PHP is a Corolla, whats a Land Cruiser then? Rust?
I beg to differ, sorry. It's clearly Java.
Clojure is the Mercedes of programming.
I presume you mean luxury but Mercedes reliability isn't great.
What’s the Camry of programming then?
Kotlin? Basically the same as the Corolla but a bit more comfortable in all regards. :)
lol that’s actually a good comparison!
Right, I think this gets at the biggest issue with "judging languages."
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.
What is Java then?
Java is a DSL for taking large XML files and converting them to stack traces.
A Soviet moving castle made from Volkswagen Beetles
e: (my only real experience with java is spring boot)
Just look at the Java installer: What is Java? Java is everywhere!
A Toyota Corolla where you have to import 1000 parts with hideously long names in order to get it running every day.
even back when i didnt do scala, i used an IDE to fully automate this. By far the least annoying part of the system.
Do tell, what were the more annoying parts of the system?
A John Deere tractor used by mega farms.
If I were Toyota, I'd sue.
[flagged]
Also shared in the article is FrankenPHP - "Modern PHP App Server, written in Go"
https://frankenphp.dev/
I mean you can either click on the article or click to read the comments, its the same amount of clicks either way
PHP Must Die is not a wish, its an execution paradygm.