[HN Gopher] PHP: The Toyota Corolla of programming
___________________________________________________________________
PHP: The Toyota Corolla of programming
Author : secstate
Score : 152 points
Date : 2025-08-04 13:49 UTC (9 hours ago)
(HTM) web link (deprogrammaticaipsum.com)
(TXT) w3m dump (deprogrammaticaipsum.com)
| debarshri wrote:
| What is Java then?
| baggachipz wrote:
| A Toyota Corolla where you have to import 1000 parts with
| hideously long names in order to get it running every day.
| dionian wrote:
| even back when i didnt do scala, i used an IDE to fully
| automate this. By far the least annoying part of the system.
| willismichael wrote:
| Do tell, what were the more annoying parts of the system?
| timw4mail wrote:
| A John Deere tractor used by mega farms.
| mmcromp wrote:
| A Soviet moving castle made from Volkswagen Beetles
|
| e: (my only real experience with java is spring boot)
| briffid wrote:
| Just look at the Java installer: What is Java? Java is
| everywhere!
| DonHopkins wrote:
| Java is a DSL for taking large XML files and converting them to
| stack traces.
| lucasyvas wrote:
| 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.
| 9dev wrote:
| > 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.
| hu3 wrote:
| 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.
| GiorgioG wrote:
| 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.
| bbarnett wrote:
| 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.
| GiorgioG wrote:
| 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...
| eamann wrote:
| 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.
| GiorgioG wrote:
| 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.
| danaris wrote:
| 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.
| GiorgioG wrote:
| I don't have to enumerate all of PHP's shortcomings to
| justify my position.
| danaris wrote:
| 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.
| GiorgioG wrote:
| 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.
| PaulHoule wrote:
| 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.
| cosmic_cheese wrote:
| 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.
| normie3000 wrote:
| Aren't Corollas reputed to be functional and reliable? Seems like
| a weird analogy.
| antonymoose wrote:
| 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.
| danaris wrote:
| 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.
| tim333 wrote:
| 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.
| pinewurst wrote:
| The Trabant of Programming
| wodenokoto wrote:
| I still think the way you mix php and html is the best. It's not
| php + jinja, it's just php.
| ChrisMarshallNY wrote:
| 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.
| 89vision wrote:
| 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.
| captainkrtek wrote:
| Yeah this feels off, though if its assessing all/many sites
| it could make some sense, versus assessing the top N sites by
| traffic.
| ChrisMarshallNY wrote:
| 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.
| rrr_oh_man wrote:
| _> server-side programming languages for websites_
|
| Maybe because most websites are Wordpress websites.
| 89vision wrote:
| 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.
| ChrisMarshallNY wrote:
| 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.
| dagw wrote:
| _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.
| woleium wrote:
| 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.
| 8n4vidtmkvmk wrote:
| 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.
| jamil7 wrote:
| 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.
| woleium wrote:
| Php developers are easy to find and cheaper than the
| alternatives, that alone seals the deal for many businesses
| DonHopkins wrote:
| I wouldn't trust a PHP developer who wasn't able to figure
| out how to become a JavaScript developer.
| woleium wrote:
| ... who are also relatively inexpensive and easy to find?
| tracker1 wrote:
| 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.
| hajile wrote:
| 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.
| steelbird wrote:
| Not everyone wants to become a JavaScript developer.
| resource_waste wrote:
| But I can deploy a decent sized Laravel app in about 2
| days... I would need to learn the javascript equivalent.
| linkage wrote:
| 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.
| Freedom2 wrote:
| 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.
| dionian wrote:
| 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.
| perching_aix wrote:
| 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.
| CamouflagedKiwi wrote:
| I think they just mean that newer versions are further
| steps in that direction, not that Java 8 was a step the
| wrong way.
| earnestinger wrote:
| Yup. Java 1.8 is humongous leap to the right direction.
| catigula wrote:
| 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.
| maxerickson wrote:
| The sibling comment is defending what Java has grown into
| also.
| kube-system wrote:
| 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.
| catigula wrote:
| The characterization was still incorrect.
|
| The Corolla has better implementations of modern features
| than the Mazda3, it's simply not as flashy.
| kube-system wrote:
| The word "insipid" doesn't really have anything to do
| with being a "good implementation" or not.
| catigula wrote:
| 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.
| kube-system wrote:
| 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.
| tristor wrote:
| > 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.
| mldbk wrote:
| You definitely tried Mazda long ago :)
| catigula wrote:
| 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.
| nostrademons wrote:
| 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.
| CamouflagedKiwi wrote:
| 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).
| catigula wrote:
| 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.
| rconti wrote:
| 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.
| catigula wrote:
| 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.
| rconti wrote:
| | 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.
| cosmic_cheese wrote:
| 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.
| Reubachi wrote:
| 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.
| antisthenes wrote:
| You are great with analogies.
|
| Can you tell me which car is Python, so I can add it to my
| shopping list?
| slt2021 wrote:
| Java is more like Ford F-150 than Corolla
| smrtinsert wrote:
| 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.
| Zak wrote:
| 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.
| graemep wrote:
| 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.
| kstrauser wrote:
| 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.
| fragmede wrote:
| Wouldn't that be better solved by uploading everything to a
| v2 directory and then renaming the directories?
| kstrauser wrote:
| 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.
| omnimus wrote:
| 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.
| kstrauser wrote:
| 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.
| omnimus wrote:
| 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?
| kstrauser wrote:
| 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.
| omnimus wrote:
| 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.
| kstrauser wrote:
| 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.
| omnimus wrote:
| 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.
| kstrauser wrote:
| 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.
| omnimus wrote:
| 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.
| kstrauser wrote:
| 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.
| omnimus wrote:
| 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.
| graemep wrote:
| > 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?
| kstrauser wrote:
| 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.
| hombre_fatal wrote:
| 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.
| graemep wrote:
| 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.
| bigstrat2003 wrote:
| 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.
| sjm-lbm wrote:
| 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.
| sharpshadow wrote:
| Maybe it is a good base for vibe coding since there is a lot of
| code around?
| Zak wrote:
| 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).
| JoshuaDavid wrote:
| > 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 import uvicorn,
| fastapi app = fastapi.FastAPI()
| counter = {"value": 0}
| @app.post("/counter/increment") async def
| increment_counter(): counter["value"] += 1
| return {"counter": counter["value"]}
| @app.post("/counter/decrement") async def
| decrement_counter(): counter["value"] -= 1
| return {"counter": counter["value"]}
| @app.get("/counter") async def get_counter():
| return {"counter": counter["value"]} if
| __name__ == "__main__": import uvicorn
| uvicorn.run(app, host="0.0.0.0", port=9237)
|
| 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.
| secstate wrote:
| 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.
| eduardofcgo wrote:
| Also because it's a language for the web, and HTTP is
| stateless.
| zygentoma wrote:
| But that's Python, no?
|
| Edit: Oh, you showed an example against Python! Now I get it!
| 0xbadcafebee wrote:
| 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.
| calvinmorrison wrote:
| 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.
| DonHopkins wrote:
| Common Lisp is the Bagger 288 of programming!
|
| https://www.youtube.com/watch?v=azEvfD4C6ow
|
| https://en.wikipedia.org/wiki/Bagger_288
| fragmede wrote:
| 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.
| AnotherGoodName wrote:
| 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.
| benburleson wrote:
| 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?
| chuckadams wrote:
| PHP caught up with Hack's performance, but it still doesn't
| have many of its features, notably generics and async/await.
| MarkusQ wrote:
| If I were Toyota, I'd sue.
| haunter wrote:
| What's the Camry of programming then?
| volkadav wrote:
| Kotlin? Basically the same as the Corolla but a bit more
| comfortable in all regards. :)
| haunter wrote:
| lol that's actually a good comparison!
| kstrauser wrote:
| 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.
| arcanemachiner wrote:
| A fractal of bad design, if you will.
| iainctduncan wrote:
| 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.
| aaronbaugher wrote:
| 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.
| incanus77 wrote:
| 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.
| nine_k wrote:
| 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?)
| msgodel wrote:
| 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.
| decasia wrote:
| 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.
| theanonymousone wrote:
| I beg to differ, sorry. It's clearly Java.
| sam_lowry_ wrote:
| PHP Must Die is not a wish, its an execution paradygm.
| PeterStuer wrote:
| 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.
| daft_pink wrote:
| 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.
| threetonesun wrote:
| 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.
| jrm4 wrote:
| 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.
| eptcyka wrote:
| 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.
| JohnMakin wrote:
| 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.
| omnimus wrote:
| Work wise that would mowt likely be Laravel or Symfony.
| potato3732842 wrote:
| 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?).
| cies wrote:
| 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.
| erichocean wrote:
| Clojure is the Mercedes of programming.
| timbit42 wrote:
| I presume you mean luxury but Mercedes reliability isn't great.
| teunispeters wrote:
| 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).
| pkphilip wrote:
| 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...
| rs186 wrote:
| Sorry, that's an insult to Toyota and Corolla. PHP is at best a
| Nissan car.
| jancsika wrote:
| 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. :)
| rwaksmunski wrote:
| If PHP is a Corolla, whats a Land Cruiser then? Rust?
| fsckboy wrote:
| "vibe coding" is also a Corolla of programming, the Adam Corolla
|
| https://www.youtube.com/watch?v=iNMrQUF6Fvc
| kevdoran wrote:
| 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.
| stathibus wrote:
| There are still some backend people who care about performance,
| or so I've been told
| akavi wrote:
| Is PHP more performant? That'd be surprising to me, given how
| many eng hours have been invested in V8
| stathibus wrote:
| The viable alternative is not PHP, its almost any sane
| compiled language.
| riku_iki wrote:
| 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.
| hu3 wrote:
| 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?
| kelvinjps10 wrote:
| 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
| t1234s wrote:
| PHP being a Corolla would mean my 20 year old PHP application
| would run today with no changes. This is not the case.
| Einenlum wrote:
| 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.
| RebeccaTheDev wrote:
| 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.
| munificent wrote:
| 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.
| jay-barronville wrote:
| 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.
| interestica wrote:
| 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.
| omnimus wrote:
| 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.
___________________________________________________________________
(page generated 2025-08-04 23:02 UTC)