- no "unknown unknowns". it's so tried-and-true, there's no surprises
- deployment is so simple, just drop a file on a web server. No middleware needed.
- No long compile times because there is no compiling needed.
EDIT: why the downvotes? If you don't agree, just reply so we can have a healthy dialogue.
EDIT2: I also think there is something unique about PHP documentation. It has plenty of real life examples, and the ability for users to leave comments allows you to hear directly from others "gotchas" that people have experienced. I feel like PHP documentation is very undervalued.
> - no "unknown unknowns". it's so tried-and-true, there's no surprises
This part is laughable. People who have been programming PHP for 20 years (several of them at my company) still routinely discover hidden bugs, quirks or general behavior that is totally unintuitive and nowhere found in the documentation.
I mean, I am by no means an expert in PHP, and in fact most of my knowledge of it comes from hating on it (or having been thrust into the unfortunate position of being the system administrator for a popular MediaWiki instance), but even in my limited experience with it from a couple lifetimes ago I know that most of the documentation for PHP is crowdsourced in the documentation comments section. That might be depressing, but that isn't what that comment was defending: it does feel likely to be true that there aren't many "unknown unknowns" waiting for you in PHP.
To me the comments section is one thing that sets PHP apart from other languages. Need to learn a new function? Go read about it on php.net, then skim the comments for edge cases.
Need to do something new in Node? Sift through a bunch of search engine spam, read a few dissenting answers on stackoverflow that refer to a previous version, eventually find a library that does what you want, written by skullM4ster2004, plug one's nose and install it.
When I had to code in php I've written a css-rule for my browser to hide the user contributions to the docs, since they where often misleading if not plainly wrong.
I remember no discernible border between 'official docs stop here' and 'user contributed opinions start here'.
I can't attest to how it used to be, but now at least they are in a section labeled "User Contributed Notes". The notes can be voted up or down, so hopefully the dross sinks to the bottom.
I do agree with the sentiment though that these unofficial notes should be taken with a grain of salt. In my experience, they have been more help than hindrance.
i always found those comment sections to be so odd — fifteen year old comments about a common pitfall and the information never makes it up to the official documentation?
i suppose it's fitting for a web-centric language to crowd source its docs on a website, but does any other mainstream language do this?
Meanwhile, I find the PHP docs far more readable/accessible than almost any other language. Compared with the official Python or (shudder) Java docs, and they're far superior, IMO.
If it makes you feel any better, at least the comments are next to the documentation? Really big projects that people rely on every day -- things like Rust's Cargo or Google's Flutter -- are riddled with bugs and limitations, requiring frustrating boilerplate workarounds to make basic things work correctly, and they generally only have mention of the problems in the comments on the billion 5-10 year old open issues in their task tracker.
Maybe it’s the frequency that you use the language? I go maybe 5-10k loc between needing to lookup anything in the docs at all, and 5-10x that where the issue I need guidance on isn’t in the formal doc.
Much more frequently I’m looking up something related to the tools and libraries I’m using.
The only surprising thing I’ve learned about PHP at the language level in the last 6-10 months is that you can call array_filter() without a callback to cull nulls.
It could be, but I also never felt like I really got to the point you're talking about in 2 years or so of moderate usage. I've been productive in it, and it's not like I'm hung up on control flow or something. I don't hate the language either. I still have to use it from time to time, but it just doesn't seem like it makes sense for a lot of green field work due to this.
It's mostly things like parameter order for certain built-ins that aren't intuitive and/or finding built-ins I've never used or heard of because there are so many obscure ones (there are nearly six thousand) that keep me coming back. For example, how do you disable errors in a DOMDocument? It ought to be as easy as DOMDocument->setAttribute("errors", "false"), but no it's a separate function call to libxml_use_internal_errors(true). There are like five other similar function calls for this too. PHP has abstraction leaks and little inconsistencies like this everywhere.
Granted, languages with small standard libraries, like JavaScript, by contrast get an easy cop out to blame the community of various package maintainers here. But at least in that case someone can always just write a better library.
That was my point - OP said it "culls nulls", and the pitfall is that kind of thinking - if you think of it as removing nulls and you're not mindful, you might be deleting things from the list you don't want to be deleting.
Do you really though, or are you being a bit hyperbolic? It's really not that complicated or arbitrary. If you find yourself hitting idiosyncrasies so often you've got the docs open you might just be doing it wrong. There's also some learning to do for any language, no language is so intuitive that you know it without any effort or learning.
All the above said, do enough real work in any language and you'll find cases where the idioms of the language don't map to your work.
PHP isn’t consistent with itself and has abstraction leaks for things that it shouldn’t. PHP does not bring me joy.
Of course I’m speaking succintly above. It’s not that bad, but it’s not that much better either. I’m not going to stockholm myself into using a language just because it’s “mature” if I don’t have to. I may have that relationship with JavaScript but at least in that case resistance is somewhat futile and there are practical benefits to be had.
Go might be a contender save for a couple weird features. JS might be with a few ground rules and/or enough tooling.
I’m also willing to grant implicitly that there are tradeoffs here. Languages with small standard libraries usually have big community libraries and vice/versa.
JS isn't directly comparable due to the very delineated nature of ECMA -vs- DOM/NodeJS APIs - ECMA is pretty easy to internalise but you'd be hard pressed to get by without MDN DOM or NodeJS core API docs open (unless as you say you're abstracting them with community libs as you say).
I've only used Go sparingly - I heavily relied on docs, but yeah it may have a shallow learning curve. It's certainly much saner than Python (which seems to be the other language used in my "space" for e.g. ad hoc ops tooling, etc.)
My approach (very similar than when I write C or raw JS) is to use a few "cleanup" APIs or libs that hide the nasty stuff (string handling / array iteration / SQL building), because I know I don't want to deal with all the footguns. There were rarely is a performance argument that would need me to do otherwise.
That's what makes the statement "no 'unknown unknowns'" a bit ridiculous though. How can you possibly assert that there are absolutely NO 'unknown unknowns'? You can never rule them out, and at best can only suspect there's a possibility either way, that they do or do not exist. You can never actually know with certainty.
You can have a statistic approach, and that's what the OP is referring to. If you find out about an unknown unknown frequently, they are out there. If you go years without hitting one, they are (probably) absent.
Ruby, Python, C#, Java, and JavaScript are all are more predictable and just as useful. Go, Elixir, Clojure, and probably others are more predictable while being less "useful" only in the sense that they may have less convenient deployments or less mature web libraries.
I've used Python, C#, Java, JavaScript and PHP, and in my experience Python is the most unpredictable of these languages. Just to name a few:
- mutable default arguments
- late binding closures
- typings that are purely documentation instead of being enforced
Labeling these things as "gotchas" doesn't make them predictable imo.
Python less predictable than PHP? In what world? In PHP standard library functions silently take a null instead of a string, even though they are string handling functions, hiding that mistake for the user of the language, until a later point in time, when the context has been lost and one needs to do silly debugging, until one finds the place where the null first was handled, while it should have raised an error. Such is the silly character of PHP standard library. Many functions also have multiple return types, which makes it difficult to simply use the result of one as input to another.
If predictability means to predict, that standard library will behave nonsensically, then yes, PHP has the one high predictability.
Oh, so you _haven't_ used any of the recent versions of PHP, then. You're just talking shit with no actual recent experience. Gotcha. Well, thanks for your input.
docker run -it php:8.0 bash
# php -a
Interactive shell
substr("abcdef", 3);
// no result
-- Ah right, PHP does things differently than other almost every other language that has a REPL and I have to echo a value, which was just returned, even on the REPL ...
php > echo substr("", 3);
-- Silently hiding the error. Idiocy.
php > echo substr(null, 3);
-- Silently hiding the error. Idiocy.
php > echo substr("abcdef", 3);
def
Who is shit talking now? Are you suggesting, that all this is normal and OK? Nothing is fixed. It's still badly designed and probably will remain shitty like that, until PHP programmers finally realize, that this needs to be properly fixed.
EDIT: Of course the docs also do not mention this to happen at all and tell you, that the first argument must be a string. So I guess that means, that in PHP terms, null is a string. Great for type safety!
No, I was thinking 'less mature web libraries' for Go. It's hard to talk about groups of languages in broad strokes when there are various tradeoffs and each language has its own strengths and weaknesses, and I painted two possible weaknesses broadly across several languages that don't strictly apply to all of them.
I am starting to find PHP bearable as soon as they are starting to follow Python language and precepts (like libs for humans, code readability instead of shorthands,...)
I've never experienced the same kind of out-of-the-box problems with PHP as I have Python. I seem to suffer constantly from python/python3, pip inconsistencies and stuff just breaking constantly.
I don't think it's an either/or; more like both language and tooling can eat into your annoyance budget and you look for the combination that has the lowest overall cost.
If you never upgrade, sure. PHP 7 and each minor version in it have deprecated and removed plenty of stuff that was legal in 5.6. PHP 8 is on track to do more of the same. I think the backwards incompatible changes are pretty much all good for the language, but claiming backwards compatibility in PHP is completely wrong.
If you aren't on PHP 8, you aren't supported, and if you're on anything earlier than 7.4, you aren't getting security releases. And the new versions released yearly all have breaking changes, and get three years of security support. It's not 2015 anymore.
Besides the obvious 2 to 3 transition, cpython has obsoleted or renamed stdlib modules several times between 3.x versions. For example, the collections.abc change causes several common Linux bits to break if you change the system default to 3.8.
Which is a double edged sword. How many ways can one escape a string, and for how many of them will you find a stack overflow comment from a decade ago saying are the secure option to use?
> I feel like PHP documentation is very undervalued
PHP is documentation done right because of the comments, essentially "Stack Overflow" for PHP before stackoverflow.com was a thing.
I've found an example of documentation done wrong recently with Microsoft .NET 6.0. Apparently, Microsoft has decided that code samples are no longer important
I've been migrating to Azure and their SDK documentation is next to nonexistent. The codebase is also uncommented and inconsistent. It's just been a dumpster fire.
> PHP is documentation done right because of the comments, essentially "Stack Overflow" for PHP before stackoverflow.com was a thing.
It's funny really, for a programming language to rely on comments made by random people, instead of having those aspects covered in the documentation itself. Shows a bit of lack of care. It seems half-assed as many things in the ecosystem seem. What happens, if they ever lose that database of comments? The whole world scratches their heads wondering how to use standard library functions? Ridiculous. I hope they have good backups.
> I've found an example of documentation done wrong recently with Microsoft .NET 6.0. Apparently, Microsoft has decided that code samples are no longer important
And for as long as important documentation resides in comments in PHP docs, the same can happen to PHP docs. Lets say they push out PHP 9 and some things change. Someone thinks "Ah those comments are not actually true any longer. Lets get rid of them." Bam, massive resource lost, because the knowledge has not been integrated into the documentation.
> - no "unknown unknowns". it's so tried-and-true, there's no surprises
I've always been a fan of PHP too; it was my first programming language that I used to build a shipping application, but saying there are 'no unknown unknowns' in a language as quirky and old as PHP is akin to denying the sky is blue.
PHP 4 + 5 had so many weird quirks, and they lasted a long time because PHP 7 took so long to ship (note there was no PHP 6). When 7 hit, they followed it up with many minor releases to try deprecating/removing/correcting some of those quirks, which itself introduced more unknowns when refactoring legacy code. Suddenly the quirks you were used to for so long were now gone or behaving differently (or more sensibly at least), but this required even more refactoring to account for.
When a language is always changing or evolving you can never know in advance with certainty how new features or changes will change how existing code will work.
I noticed being stateless made it difficult to scale for any complex app. It’s been 7-10 years since I used it but Drupal used 60-128MB+ plus per request. As it was stateless it had to do a full bootstrap for every request coming in, set up a new database connection, module discovery etc, all which was heavy to do for every request. Most people scaled Drupal by putting Varnish in front preventing the origin from being hit so not really scaling Drupal as such, varnish is taking off some load where it can.
Drupal is probably the extreme though. If you have a simple app with a few scripts, light use of a DB it’s not to bad. I’ve heard it’s come on a lot in the past 10 years and Laravel. I certainly had less issues using PHP than I do with JavaScript.
Yes, nothing comes for free. opcache, object cache + db pooling is something I always turn on.
Then, for app performance:
My approach is to usually design the app / refactor the app so static content can be fully cached. In ecommerce sites this can make an absolutely impressive difference. Then, leverage opcache and object cache and further separate cacheable path from dynamic path in dynamic SSR queries. Always drive using APM performance metrics as a guide. No need to optimize the DELETE /user endpoint called twice a week.
Then, identify the heavy hitters in the dynamic DB queries, and basically write those in hand rolled SQL. It usually boils down to 4 or 5 queries doing 99% of the work (GET /posts, GET /categories, GET /products, etc...). I do this fairly late in the game, but think about it very hard up front. I like to use some kind of ORM for everything writing to the DB, and sql builders / pure SQL for reading.
The split between cacheable / non-cacheable can be subtle depending on the application, and might require some non-obvious structures in the codebase.
For real tricky performance issues (not something I had to do in PHP projects), I will either ducttape some AWS infrastructure or handroll a microservice in C++ or golang. This is something I had to do for realtime / transient loads.
Drupal misused the database. For Drupal 7 I made the apdqc module for async prefetch MySQL. no deadlocks makes it easy to scale, load balance more Apache servers in front. DB size was 100gb; well into millions of rows of nodes; all logged in users. Site I made this for has been up for years; Fix the database layer and Drupal 7 will scale like crazy.
> I noticed being stateless made it difficult to scale for any complex app. It’s been 7-10 years since I used it but Drupal used 60-128MB+ plus per request. As it was stateless it had to do a full bootstrap for every request coming in, set up a new database connection, module discovery etc, all which was heavy to do for every request.
It doesn't make scaling hard, it makes scaling very easy because you can just horizontally scale out as many instances as you need. The constant factor is pretty awful, but that's the tradeoff you make for statelessness.
Ok, it makes scaling technically easy with horizontal scaling for the web tier, ignoring the DB.
In practice it makes scaling hard for financial reasons if you require 128MB+ per request. A 32GB server will struggle with more than 256 concurrent requests at 128MB+ per request. A 32GB server is an extremely large server for such low request numbers.
If you can bring the memory usage down stateless works well. I use a bit of rust on aws lambda with the lowest memory settings so pay fractions of a cent and can handle more traffic than I ever need. I do set up persistent connection pools for the life of the lambda and only bootstrap once to bring down latency per-request but treat it as an ephemeral horizontal scaled service.
It might be much less efficient per request than other popular languages, but it's stateless design, does at least prevent developers from using local memory caches, which can prevent a number of problems from cropping up when scaling horizontally.
With that said, I think the stateless nature of php is talked up too much.
While not enforced by the nature of the language like php, writing stateless apps in other languages comes quite naturally.
Scaling difficulties are almost always to do with the database solution rather than the app, and overcoming those problems has little to do with the choice of language.
It always depends on the situation, but I do value the stateless approach "by default" of PHP because it makes shoddy code / legacy code that has grown through generations of uninterested developers much easier to deal with.
I of course value at least partial "stateless" (functional core / hexagonal architecture, event driven architecture) in any language, because they reduce complexity so much.
With both Drupal and Laravel it's very easy to overload the database. It's shocking when you start using some tool that gives you insights in to this and it tells you you're running 6000+ queries every time your homepage loads.
In Laravel it's not too hard to avoid this problem but a lot of noobs don't get the lazy / eager loading thing and then you end up like this.
Drupal seems to add hundreds of queries for every module you add.
I feel this is more a "classic" ORM problem. Wordpress is absolutely egregious here as well. I wrote up my strategy in another post, but I usually develop using the ORM (often, ORM for writing, SQL builder + ORM for querying, because I hate ORM filter/join abstractions).
I do think very hard up front what the product will require in terms of:
- static content
- dynamic content that is cacheable and which keys can be used to cache it
Static content can use ORM as much as it wants, cloudfront will take care of it. dynamic content that is rarely hit doesn't really need much help either if there are no UX latency requirements. dynamic content that is hit very often (usually only a couple of endpoints) can be rewritten into manual SQL.
If you think about it, most page hits with dynamic content can be rendered basically by the DB + templating engine, and no other logic should be involved.
That might be mainly a Drupal problem, I use Laravel and it can do some significant caching of all the bootstrap stuff for production. Plus as mentioned PHP itself is pretty strong now in terms of opcache and such.
Had same experience, had same thoughts. I bet I could make my way around the Drupal 7 bootstrap even these days, I looked at it so much... and so often thought... all this... every request?
I agree. I started learning PHP in 2006, and though obviously it's advanced enormously since then, I did wonder if I should switch to more 'modern' options. In particular I tried to switch to Node a few times. But I just found myself feeling like I was missing out on benefits from PHP and not really gaining anything new (particularly, like you say, stateless requests just makes logical sense).
I do think people who react so viscerally negative to it in 2022 are only doing so from an old preconception and not judging it for what it is today. I build seriously large and complex applications and never once have I felt that I was fighting PHP or it was holding me back. I don't really get the hate.
First 10 years of my career were heavy PHP. I’m solidly into Ruby and Elixir now, but I completely agree with you on the perks of PHP. People love to hate on it.
Its so easy to just get things done in php, even if its in an ugly way that you would never show to another developer. I built a saas for a fortune 1000 company after not programming for 5 years and never having done web development that ran several processes for them and they used it for a decade. It was the ugliest code in existence but it was so easy to just update and after it was up it just ran, forever. Deploying changes was just dragging over a file in Filezilla. Been thinking of building something new and considering learning node but PHP is right there. When I had to migrate to a new server I just copy - pasted the folders and away it went.
> Deploying changes was just dragging over a file in Filezilla. Been thinking of building something new and considering learning node but PHP is right there. When I had to migrate to a new server I just copy - pasted the folders and away it went.
These days most organizations will not tolerate just copying files over. There will be a process for testing the code and then stuff will probably be put in a container, to be even easier to run on another server.
At that point the advantage of just sftp-ing files over disappears. It is no longer deemed safe enough to do so. Usually it is not the end of the world, if your website is down for a minute, but it does tarnish the public image of reliability, so organizations are not willing to put up with developers making a typo somewhere bringing down their website or causing at least an annoying error on the website.
Instead of copying files over to another server, you would typically do some docker pull or other container engine pull some image or what have you. Then you would run that previously tested thing on the server.
I think the point is that you can do both. Sometimes being able to yeet a PHP file to some PHP/wordpress hoster and get a project done in an afternoon is exactly what is needed, because even spending 2 or 3 days to set up a proper CI and deployment environment would be too much friction.
There is a whole range of projects like that out in the wild, once you leave the realms of startups and big tech.
It's about as easy to do "proper" deployment using bundles / containers / CICD / kubernetes / gitops with PHP as with any other stack. It's also possible to click a wordpress domain for $10/month and upload 2 php files and start making revenue.
For a small business that is starting up, choosing between $10k of freelance work to get a nice github actions workflow on GKE + a monthly retainer of $2k for "maintenance" vs a one time $1k of freelance work to get a wordpress where you can configure the plugins and theme yourself is a no brainer. Many of those small business then grow much larger and reach a point where in hindsight you can say "should have gone with docker containers". But the original decision was not just perfectly valid, but probably the only reasonable one.
Not talking about organizations, talking about a little group of people or a startup building something fast to get some cash flow or a poc. Php is there when you just need to get something done and live. I built my SaaS in 4 months with php, probably did 40 total hours of updates over the life of the application and it was used for a decade performing some relatively complex process management.
DISCLAIMER: I am not actually a "backend" developer (although I have written some pretty big backends).
I am not a JS fan. This is not because I have anything against the language; it's just that I have no real need for it, and have treated it as a "necessary evil," in my frontend work, so I don't believe that I have much of a platform to lob spitballs at it.
PHP, on the other hand, is a language that I have used for over 20 years. I think it was 3 or 4, when I started. If I do backend work, these days, I'll be doing so, in PHP.
I always like looking at the "fishtank graph"[0]. That sort of puts things in perspective.
Ah I remember the experience of just dropping files on a server from a long time ago.
I had one web host where magic_quotes_gpc was enabled. Good luck figuring out what the hell is going on with all these extra quotes in your variables.
And I kept looking up how to do prepared SQL statements in PHP, finding the mysqli functions, and then eventually figuring out that mysqli wasn’t available on your average web host with PHP back then.
(Yes it was that long ago. I also think a lot of the hate comes from that era)
I remember the documentation as well, with usually all the gotchas in the comments. Which is great, but there were a lot of gotchas. like, A LOT.
I really like the serverless aspect. I still think nothing has the deployment story that PHP applications have. Just upload some source and your website is up.
Pixar should make a film called "Deployment Story" in which PHP is basically Woody (maybe it's even just the PHP stuffed elephant?), and Woody ends up in the box on the street, and then Woody's dev pal doesn't realize what they've really lost until some reflection is done. I'd watch that.
Perl's not unique in that way. Any language can talk cgi. That's literally the purpose of cgi. Perl was just the popular scripting language of the day.
If you're using something other than cgi to get your httpd to talk to your webapp, your answer lies in understanding the architectural decisions of that tool.
PHP is pretty batteries-included, sometimes to a fault (it comes with things like 3 different MySQL drivers in the standard library). I'm sure there are cases where you'd want to install a C extension that depended on some system library, but I can't actually think of any right now.
What do you mean by system packages? There are PHP packages now and Composer. Though core and its bundled extensions are quite rich. So 3P packages aren't strictly necessary.
I’ve always wondered why the more respectable dynamic languages, like Ruby and Python, don’t have a web framework with the PHP deployment model of “just upload this file to the server and refresh your browser to see changes.”
I don't know for big instances of Laravel, for every deployment pipelines of Symphony I've seen were far from "Drop that file on the server. The end."
In the most primitive ways, you would at least do cache warming, which usually means "building" the app instance in a separate folder and swapping the active directory served by the web server. That's basically what a basic Capistrano deploy would do.
Nowadays I'd expect most shops to be using containers for PHP too, and that means building your container like any other language.
What I'm saying is, the days where PHP deployment was simple have been long gone, for at least a decade in my experience.
Ruby did have such a thing, via mod_passenger, and other options were available for different scripting/programming languages.
Back in the day PHP got big because most of the larger shared-hosting sites provided mod_php out of the box, along with MySQL.
If you wanted to run CGI scripts you were probably capable of doing that, whether in Perl or something else, but most of the other options came later or were unusual.
I know when I tried to setup a few sites a long long time in the past I had to get a VPS of my own, with root, to configure Apache appropriately. None of the shared hosting sites would have run the kind mods I wanted to have.
I think the "the more things change, the more they stay the same" is a great thing, and something to very much be aware of and study. The move back and forth from backend state to frontend state to slim apps to fat apps has been going on since the 60ies, and is driven by ultimately hardware and networking costs.
The underlying patterns are all fairly well understood, which means that knowing both approaches and being aware that things are going to slosh back and forth heavily simplify long term design.
I haven't written these thoughts out, but in many ways the codebase (as in, how your files are organized) is largely independent of how your code is actually deployed and where it runs. If you are aware that some business logic might one day run in the frontend on the client device, and 4 years later might make more sense ot run in a lambda, that's something you can architect for.
Serverless / stateless is ultimately "functional programming". If you write your code as a side-effect free function, leveraging technologies like WASM, you can keep the same code, and deploy it frontend or backend or both or as a lambda or as a single node worker, and the code itself won't change. These are the things that next.js and vercel and edge computation leverage, but it is true in every codebase (embedded, desktop applications, etc...).
Of course, vendor lock-in is a feature because once developers leave a company, someone else with the necessary proprietary knowledge needs to replace you. Spread proprietary cloud stuff like the plague and you'll always be employable somewhere!
Python and Ruby have more startup overhead than Perl and PHP, so usually you don't want to pay that cost for every request.
Edit: Not sure why this is controversial. Here is a "hello world" benchmark I just ran on my machine, in units of hello worlds per second: Perl – 1020 runs/second; Python – 78 runs/second; Ruby – 30 runs/second.
Can we have the "soft reload" model like how Django works in development mode?
Drop a file on a server, it notices filesystem change, reloads an app (or spawns a second copy of app, waits for it to initialize, kills original app and switches over to a new one)?
Gunicorn has an option for this[1] so you could enable it on your production server, although I don't think that's recommended.
One problem with this approach is what happens when you're updating multiple files. If the server restarts immediately on the first change, you end up loading a mix of old and new files, which probably won't work properly. But if you delay the restart to wait for all the files, how long do you wait? If the delay is too long it's confusing and annoying (did the server restart yet?) and if it's too short you get mixed versions as before.
So it's better to explicitly signal when it's time to restart. You can still have automatic restarts in the development environment.
Assuming you get a new "event" every time a file in the watched folder changes, you could restart the count.
Ex. First even triggers a 5 seconds wait. If before those 5 seconds have passed there is another trigger (say after 1 second) another 5 seconds wait starts, for a total of 6 seconds in this example.
I really like the vercel and co approach to the dev cycle. It's as easy as (if not easier) PHP and you get a huge boost of monitoring / infra tools for a minor cost. I think we are seeing a lot of the "yeet and get shit done" approach with vercel and netlify that we used to with PHP.
I would say security by default is a good reason to not have this. I've been burned too many times on PHP projects because someone miss-configured an httpd conf file.
> why the downvotes? If you don't agree, just reply so we can have a healthy dialogue.
I think downvote = disagree is expected. If someone thinks your comment is not making valid points, downvoting is a way to bury it below other comments.
So that, naturally, the comments that the community most agrees with (in addition to adding quality content) bubbles to the top.
PHP documentation is one of the worst things I've ever seen. That people subject themselves to abuse such as "reading it" is comical to me. Enjoy scrolling down 15 years of comments to get the quick rundown.
> - No long compile times because there is no compiling needed.
I respect that some people accept dynamic typing as a better tradeoff for various reasons (I've worked with Ruby for many years before I discovered my love for type systems), but to me that statement reads similar to:
"No long CI builds because we skip all the tests."
That's runtime type checking, which is a completely different thing and doesn't fit the analogy. Runtime type checking helps you fail fast, which hopefully prevents undefined behaviour and data corruption, and can help with fault localisation (some hardcore type theorists would even argue that runtime types aren't really "types" per se, but more like tags).
Compile-time type checking is a soundness proof of your program, which is an entirely different thing.
The issue I have with php, having started building websites in the early 2000s with it, is that it is a language that doesn’t push you to write better code and progress. I am much more of a fan of static langages where the IDE guides you a lot more, gives you live feedback so that being curious is cheap, you don’t have to dive into some documentation to know what the other methods, parameters and overloads are, you can refactor code safely and effortlessly.
So I am sure some professionals write brillant code in php, particularly in large organisations, but my guess is that the median code base quality out there is probably pretty lousy. Anything below the 80th percentile probably too.
I think PHPStorm has been very helpful as an IDE for over a decade.
One of the things I do like about PHP is that while most legacy codebases out there are lousy (even when good developers are involved), and often lousy for totally legitimate reasons, PHP with its "don't even try to do clever" approach makes many things easier.
Of course, I only dealt with so many legacy applications. My worst experiences have always been with python legacy code because there were strata of conflicting "better code" approaches piled on top of each other.
Once you start abstracting into patterns, and you don't have the experience needed to get a sense of good architecture, it's easy to make a real tangled mess.
I won't downvote you, I think it's kinda crappy when people just do that without explaining. Also an opinion isn't something we shouldn't downvote, we should downvote poor responses.
In any case, I definitely agree with all those pros. What I dislike about PHP is that as you start growing a codebase, especially with includes, your attack surface just grows and grows and grows. In other frameworks where a stack is involved attack surface generally grows as well, but since any PHP script has access to the request, it's much much worse.
> I also think there is something unique about PHP documentation. It has plenty of real life examples, and the ability for users to leave comments allows you to hear directly from others "gotchas" that people have experienced. I feel like PHP documentation is very undervalued.
I think it's the best documentation out there, and that part of the reason it's easy to document, is because the language uses a standard library, and functions, as opposed to the structure of the language, itself, to provide most of the utility. Functions are easy to document.
They do a good job of "cleaning out the cruft," as well, so that there isn't much in the way of "no longer applies" stuff.
Part of it, too, is that the language probably supports stuff all the way back to 4. They tend not to deprecate, and accrete, instead (not always a good thing). That means that examples and discussions maintain relevance, even years later.
One of the biggest issues that people tend to have with PHP, is that it allows you to write bad code.
I came from a C++ shop (another language that people love to hate). If you think you can write bad code in PHP, C++ says "Hold my beer."
I am a big believer in Discipline. With Discipline, we can write excellent, maintainable, code in any language. I have written stuff in Assembly, FORTRAN, Pascal, PL/1, Perl, Bash, BASIC, C, C++, ObjC, and Swift, that is quite well-structured, maintainable, and well-documented.
That's sort of true, but the default state mechanism (session files) doesn't scale well, or even work across load balancers that don't maintain server affinity for each client. Scaling a PHP app isn't hard, but it can be non-trivial if you've written the code without considering scaling. Other serverside scripting languages (Python, Ruby with Rails) nudge you in the right direction in ways that PHP doesn't.
Have you tried a more "modern" language recently? By trying I mean using it for more than 6-10 months. I've been one of the PHP "supporters" until I've found Go and Rust. PHP was really nice to get into programming and make a spaghetti website but the language itself and the ecosystem always felt like a hacking project.
The killer feature of PHP has always been the hosting ecosystem. A simple FTP upload would do the job without knowing much about the hosting infrastructure. Recently we've got that kind of "serveless" experience for other languages as well but the deploying is proprietary and the providers are very few. I'm aware only of Google Cloud Run.
As for JavaScript even its inventor said it's time to move on. It's time for a new language and a new DOM interface. Maybe we can fix the "language" issue with WASM but we are still left with the DOM.
> PHP was really nice to get into programming and make a spaghetti website
Facebook manages quite well with PHP. Maybe it's your fault you didn't learn how to use modern PHP practices which have been well-documented for over a decade now.
I didn't say you can't make it work. You can build great stuff using just bash scripts. I'm pretty sure you can have success with any programming language. That doesn't mean it's the "best" way to do it.
>> Maybe it's your fault you didn't learn how to use modern PHP practices which have been well-documented for over a decade now
I doubt it's my fault. I'm not "special". I think PHP is prone to bugs and bad practices both due language design and bad documentation.
> I doubt it's my fault. I'm not "special". I think PHP is prone to bugs and bad practices both due language design and bad documentation.
Not in 2022. I avoided PHP for a long time. I got back to it and found that the Internet and books are full of best practices and I have not had an issue with documentation either. Would you please give me an example of how PHP is more prone to bugs vs. other languages in this area? I have found it to be really difficult to write buggy and insecure code. For example if you have not heard of PDO and you do not prepare, bindValue/bindParam, and then execute, that is your fault (make use of filter_input() as well!). It is advised literally everywhere today. Regardless, my return to PHP was pleasantly surprising. I finished my project pretty quickly and I have not used any frameworks. Security vulnerabilities? Perhaps, but so far so good. We will see. I tried my best and I have done my research. Every time I mention that it is written in PHP, people frown because they are stuck at PHP 5 or so. That said, subpar defaults in php.ini is still a thing though.
It's more like redditors creeping in. The "downvote is not a disagree button" of reddiquette went out the window a looong time ago. People are fast to hit that button and the attitude is seeping in here, harming discourse.
React gets an equivalent amount of disdain as PHP. Like 60% negative, 40% positive. (lots of preferences for server-side templating, htmx, Vue, Svelte, and Phoenix LiveView)
React is great. Vue is wannabe angular (not sure what version though was it 2, 3 or 4 now?) svelte is too busy shipping bugs to fix any and I don't even know what the others are.
Criticizing is so easy, especially on the internet. If they're that good, why won't they propose a workaround or work with the language developer and provide some feedback?
Elitists can't like what the general mass likes.
There's a reason the general mass likes but they think they can do better, but let's see how they do so in real life.
What cult? PHP is technically, objectively inferior to almost every other web technology (which is impressive, actually, given how terrible most web technology actually is) in almost every use case one can think of. That doesn't mean it's bad or that nobody should ever use it, or that it isn't a superior solution in some cases. But in basically any non-trivial use case, it's a poor choice.
I always have a hard time understanding what exactly is meant with comments like these. We can all agree that PHP has a wildly uneven standard library, had its fair share of security-relevant footguns, tends to have unexperienced developers. That's not extremely different from python and node.js, for example.
The language significantly cleaned up its act, it has had classes, traits, closures, introspection, namespaces, packages for well over 10 years now, a robust third party library ecosystem and many successful projects to build upon (wordpress, drupal, woocommerce, phpbb, etc...). This makes it a pretty good choice for many applications.
The stateless model and the resulting "no crazy stuff" approach makes it a much more reasonable choice for web development than say, python+django or ruby+rails to me. There's nothing I loathe more than trying to find which duck-typing, method-injecting package is causing a slow-burn memory leak in production.
I also don't understand where the "most web technology is terrible" stance comes from. I find the quality of software engineering and the care put into developer UX and productivity in the web world quite inspiring. It has been a forcing function on all programmer tooling since the cambrian explosion in the earlier 2010s.
That's not really true at all. PHP is like a Swiss army knife. It's not the very best at any one speciality. It is much better at many things than pretty much anything else though. You can use the Swiss army knife to put in screws, but a screwdriver is much better, but it's terrible at cutting zip ties.
Suppose you had a old car. You know its limitations, you've used it for many, many years. You know its problems, its quirks and warts. You also know the workarounds for its quirks. In all, it is good enough for most of your needs. It rarely surprises you. It is average looking, but it just runs and is easier to maintain.
Then comes the shiny new car - it has way too many gadgets and gizmos, you don't know how most of them work. Heck, you don't even know what half these gadgets are for. You don't know when or how it will break. But most importantly, you don't know how to fix something when it breaks, because there is too much magic going on. High maintenance, constant stress.
The first case is PHP. People can dunk on it all day, every day. But it is good enough for most projects. And with tools like Laravel, Composer etc, PHP is constantly improving too.
The latter? I dunno, there are lots of candidates for it I suppose.
It is absolutely the fault of PHP. You absolutely can compare IEEE floats using equality. Often it isn't what you want but this totally should work.
In this case PHP is unexpectedly rounding floats for display.
~ python3
Python 3.9.13 (main, May 24 2022, 21:28:44)
[Clang 13.0.0 (clang-1300.0.29.30)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> b = 46333.48000000001
>>> b
46333.48000000001
~ php -a
Interactive shell
php > $b = 46333.48000000001;
php > echo $b;
46333.48
Apparently exact minimal float-to-string conversion is more recent than I thought, and many languages used to print more (Python?) or less (PHP) decimal digits than necessary to uniquely identify the bit pattern. Python correctly prints 46000.80 + 553.04 as 46553.840000000004, but I don't know if it ever prints more digits than needed. One recent algorithm for printing floats exactly is https://github.com/ulfjack/ryu, though I'm unaware what's the state-of-the-art (https://github.com/jk-jeon/dragonbox claims to be a benchmark and the best algorithm).
I did a 100-level paper at University that explained floating point arithmetic and how to solve for equality. Without being snarky, how do developers miss this sort of stuff?
> EDIT2: I also think there is something unique about PHP documentation. It has plenty of real life examples, and the ability for users to leave comments allows you to hear directly from others "gotchas" that people have experienced. I feel like PHP documentation is very undervalued.
This is perhaps one of the better things about it! It feels like lots of different languages and frameworks would benefit from comments at the bottom of the page, from the community, explaining various common use cases and gotchas.
Somehow it feels like docs being on GitHub with people being able to contribute to them there somehow can have higher friction, versus a forum-like system.
> - it's stateless by design (much easier to scale)
I'll grant you this one. Though PHP in practice goes to great lengths to add state back in for performance reasons (e.g. memcached, or for a while APC).
And Haskell is stateless, too, yet not a frequent choice for web work.
> - it was "serverless" before Serverless
This is retconning. It was never trivial to set up a LAMP stack, especially at scale. I can't tell you how many times I've seen the PHP "too many open database connections" error because someone just treated their Wordpress blog as "serverless" and it went to the top of HN.
> - surprisingly performant
I can't speak about the latest stuff, but PHP5 in ~2014-15 was abominably slow. There were certain "benchmarks" which indicated it was fast, but on closer inspection, these were simply calls where PHP provided thin wrappers around C calls.
I had to once take an Excel file, parse it and then present certain fields to the user for the DB to be updated. This was possible in PHP, but it took excruciatingly long (like 8 minutes - in fact, sometimes Apache would just drop the connection), and third party library support was just awful. I implemented the same task in Python, and not only was the code much simpler and and easier to write, but the task took a second or two each time.
> - no "unknown unknowns". it's so tried-and-true, there's no surprises
The standard library is a toxic sludge of surprises. Nothing is consistent. "Will this function treat an array like a list or a dict? Who knows?"
Maybe this is better now, but the last time I dabbled in PHP, I spent a while trying to get a workable debugger set up and gave up. Stepping through code is apparently impossible, and every now and then you hit some fatal error that immediately crashes your code.
> - deployment is so simple, just drop a file on a web server. No middleware needed.
What does this mean?
First, PHP has middleware (e.g. memcached, Apache/Nginx).
Second, the complexity of deploying a Python, Node, Rust, Go or Ruby application is not the "middleware." The complexity is ensuring that the update is correct, the update is applied consistently, can be rolled back, doesn't cause downtime, etc. I could also do updates by running webpack dev server in prod and dropping files in there for deployment. As easy as PHP, yet a terrible idea.
> - No long compile times because there is no compiling needed.
This is odd to say the least. PHP's biggest weakness IMO is that each thread must entirely parse and interpret its executing program on every single call. That is a ton of wasted work, and there are literally sections in the PHP docs about tools to circumvent this problem.[0] And the solutions involve caching, which mean we give up (1) the "stateless" benefit and (2) the "just drop in a file" benefit, or else we need to add a bunch of cache coherence logic. It would be so much easier if someone could compile the PHP code to a bytecode format and drop _that_ in, which could just start executing on an interpreter ASAP.
Ultimately, I think the list is getting downvoted because it deviates so much from developers' experience with PHP. PHP started out as a sub-Turing templating tool that had a Perlish language bolted on, which then mutated to look a lot like Java. Eevee's classic blog rant[1] calls it a "fractal of bad design," but the reality is PHP has no design: it's just a kludge of duct tape and bolts.
Also, maybe this is totally incorrect now with PHP6--er PHP7 and PHP8. But my experience with PHP4 and PHP5 was so horrific that I will not be working with it again. I've yet to find a PHP use case that is not better solved with a combination of a static site generator and something like AWS Lambdas or Cloudflare Workers.
As a counterpoint, I used PHP5 when writing https://www.goldeneaglecoin.com/ and it was always < 50 ms on my endpoints, running on some crusty hosted celeron at the time. Adding caching and opcache doesn't invalidate the stateless approach.
Programming is about adding abstractions on top of underlying computational substrates. Ultimately our CPUs don't care if we run haskell or PHP, they just run machine instructions. I never found it too complicated to use useful abstractions in PHP.
I usually prefer inheriting a subperforming cache-free PHP site, because devising a consistent cache strategy is usually not too hard (cache static content + opcodes on deploy, determine which invalidation keys you need for the subset of dynamic content that does the bulk of the load / has latency requirement, don't cache the rest). If I have a big collection of lose php files, that's reasonably easy to do. If i have a tangled web of middlewares and ORM'd business logic, it's much harder, and I usually have to unfold it to "lose leaves".
Great comment! You clearly are well-versed in the ecosystem much more than when my PHP5 self gave up. If I needed a PHP dev for a project, I'd hire you.
> Adding caching and opcache doesn't invalidate the stateless approach.
> Programming is about adding abstractions on top of underlying computational substrates. Ultimately our CPUs don't care if we run haskell or PHP, they just run machine instructions. I never found it too complicated to use useful abstractions in PHP.
I'll push back a little on these. TL;DR: it's a trade-off.
My point with Haskell is that the entire language itself is stateless, so if per-request statelessness ("shared nothing") in PHP is a virtue, then certainly total statelessness ("purity") in Haskell is even more of a virtue. The problem is that, despite having similar performance to PHP, Haskell is hard to write.
This is illustrated with caches: if a PHP program had a line something like `if ($cache.retrieve('foo') != null) { echo "Success!<br />"; } else { echo "it's broken"; }`, then now global state matters again.
Haskell doesn't allow code of this form, but forces you to think harder about how to make it work using e.g. monads, and this can be frustrating. But if you can get Haskell to work, you can get caching nearly for free.
for sure. but it's not "hard" (of course abstraction is hard to learn and see, but not to implement, I hope you understand my meaning here. I apologize for the lack of clarity) to build something like (very rough sketch):
The caching is declarative, and the code is "stateless." This is fast enough that caching the render is pretty much not necessary, despite running on a t2.medium, and easily sustains > 100 rps. In the happy path, it reads a single value in the object cache. Only an initial hit will cause a render (using a bytecode compiled optimized template), and only the first XHR will cause an actual lookup in the server side cache (if necessary) because the browser then does the rest.
I wrote this code 12 years ago, and porting to react doesn't require any change on the server side. We just put RTK-Query in front and let it do all the rest.
GGP was wondering why there were downvotes rather than comments detailing disagreements.
I decided to write down the reasons why I personally would not touch PHP again rather than give a downvote.
Maybe PHP8 or PHP7 or whatever it is (I know they skipped 6?) is awesome, but I've moved on.
Also, FWIW, a few of my objections are certainly still relevant based on the claims in GGP's post and some cursory review of the documentation, particularly around caching & in particular op caching.
> Do you judge all languages according to your experience from 8 years ago?
No, only ones that left mental-emotional scar tissue.
> Do you go on python boards telling everyone how much you hate working with python 2.7?
Python 2.7 was highly pleasant. I wouldn't use it now, but it didn't abuse me. :)
> Maybe spend your afternoon on rust threads to complain about it not being available to the public yet?
GGP: <X> is awesome for these reasons!
GGP: HEY! Why are people downvoting rather than commenting?
GP (me): Here's why your reasons don't persuade me based on my admittedly outdated experience
P: Why are you so critical?
> Do you need to like a language for 8 entire years before letting anyone know about it, or just some time within the past 8 years?
Non sequitur. But the answer is no.
Perhaps it might be more productive if someone commented which of my claims are obsolete rather than ad hominem them. I know that those relating to compilation, deployment & statelessness are still valid, given GGP's comments and my cursory examination of the PHP docs, plus experience with other platforms.
Maybe modern PHP has truly excellent performance. Maybe using a breakpoint debugger has been solved now. Maybe design is better, e.g. the standard lib has functions that can work with arrays as lists and arrays as dicts without being surprising (e.g., `filter()` used to preserve all indexes, since it treated arrays as dicts from numbers to values; often, you needed to use fold/reduce or a loop to re-number after a filter).
then take my upvote, I agree 100%, I'm saying exactly this to many people and they just roll their eyes (to be fair I don't use PHP anymore but I certainly don't share the despect which others have)
fun thing I also wanted to add a point about documentation but you did it yourself, life is fun sometimes :)
agreed reminds me of nomadlist and the sort of php philosophy of I wanted some function so with 1 php flat file I made a sort of website with app like behavior. If anything is this not programming to the masses? PHP PHP! :p
> - it's stateless by design (much easier to scale)
"By design" PHP encourages very very stateful procedural programming. It is one of the languages, where making things not mutate state seems like a mostly unused strategy. The amount of beginner code people find online and that mindset of "if it works it works shrug" continues to keep bad code alive.
The thing that might be referred to here by "stateless" is that a PHP "application" runs the code from top to bottom, as if all was one long script. This primitive handling has its own issues of course, but I will admit, that sometimes it is useful, that you can change the code and do not need to restart PHP or anything, because you will get the new script executed when the next request comes in.
> - it was "serverless" before Serverless
Where "serverless" is just a buzzword. PHP runs on a server just like many other languages. You will need a machine acting as a server, you will need PHP installed, you will need some webserver, usually something like Apache or NGINX with fpm or some other shenanigan. Nothing really special there.
> - surprisingly performant
Which in part, I would claim, is due to its reckless way of handling types, introducing hidden bugs. The type system is quite underdeveloped and cannot give many guarantees. No generics, no general object type, which everything inherits from, but only an object type, which not every other object inherits from. Then that "mixed" type, which just makes things even more fuzzy in a signature of a procedure and encourages bad design again.
Of course, if you throw all safety overboard, then you can get a bit more speed. Not really impressive.
> - no "unknown unknowns". it's so tried-and-true, there's no surprises
I just recently looked at defining constants in PHP. But I could not see in the docs, what the scope of a constant is. Simply not to be found. I just had to try it and hope. This is often the case with PHP and its half-baked docs.
> - deployment is so simple, just drop a file on a web server. No middleware needed.
But the webserver is the middleware you need. Like mentioned above, some Apache you need to configure, or some NGINX, or some other server. Maybe you have only ever deployed on managed infrastructure and never done the actual full deployment? Always enjoyed other people setting things up for you? I guess this is true for most of the people claiming, that PHP deployment is simpler than in other languages.
> - No long compile times because there is no compiling needed.
That again comes at the cost of safety. PHP types if you declare them in the code are not checked at compile time, but only when the code runs, making them merely annotations to read for another person.
In the PHP world we have learned not much from the past decades of programming language design. It is understandable. Lots of people have build tons of almost breaking things on top of PHP's design flaws and would start a riot, if things ever changed. For the sake of backwards compatibility PHP will remain in its swamp of bad design choices.
Sure, people can try to build on top of that, abstracting from it all through more modern web frameworks, plastering over all of the flaws. Sooner or later though, you will need to use some actual PHP code in there somewhere and the bad design will rear its head again.
i dont like react but even in react there is clear distinction, I've found tons of logic within templates of php like from <?php to ?>.. anything at anytime could cause anything. Kinda gives me global variable vibes
This is just so far from the truth. I can just as easily push tons of logic down into templates in erb/jsp/jinja etc... at some point it boils down to the programmer's level of expertise, but also to the programmers' opinions as there are still a lot of varying opinions on what exactly are best practices.
> I can just as easily push tons of logic down into templates in erb/jsp/jinja etc...
Not just as easy if they don't allow you to insert arbitrary code at arbitrary points as PHP does.
Personally my preferred approach is Wicket where you can't have any logic in your markup at all, all of your logic lives in code and the only thing you can put in the template is IDs for where the code can insert child components or plain text. (OK, it's not quite that strict, but it gets pretty close in practice).
> at some point it boils down to the programmer's level of expertise, but also to the programmers' opinions as there are still a lot of varying opinions on what exactly are best practices.
That's neither here nor there; "programmer's level of expertise" is just abdicating responsibility, when in fact a programmer at the same level of expertise might produce much better code in one language than another.
You seem to think that you refuted my argument, but instead you reinforced it.
By using Wicket you are making a choice to opt in to a template system that encourages best practices. This is the same reason people in the PHP ecosystem opt in to Twig/Blade/Mustache, or how people on Ruby opt out of ERB for Slim or Haml.
How many of them, and how well does the ecosystem support them in doing so? It's theoretically possible to write good code in any language, sure, but in practice the language (not just the formal syntax, but the tooling, ecosystem and community, the whole culture of the language) has a lot of influence on whether people write good or bad code in it.
Laravel is the top choice for PHP frameworks these days which auto opts you into Blade. And just from my my own personal experience (so not necessarily a great sampling) every non-legacy PHP codebase I've been involved with on various teams had adopted other template engines with Twig being most common.
Also, to be frank, it's a real shame that people look down their noses at PHP so much just because of the sheer amount there is that can be learned about the practical application of design patterns from spending some time in the Laravel code base.
Smarty is still around and well supported, but Twig is the top choice these days. Symfony is the 2nd most used "framework" these days, Twig is part of Symfony; then on top of that Symfony is really just a set of components (that work hard to adhere to current PSRs) so even projects that aren't Symfony projects will usually incorporate Symfony components as best of breed. Even Laravel relies on Symfony components.
Hack does have a lot of great features (some of which have already been ported to PHP, others are kinda impossible for technical reasons), but at this point, it's diverged so hard from PHP that they're separate languages.
If you choose Hack, you lose the entire PHP ecosystem (composer) that could back you up and save you time. The only ones really using it are Facebook/Meta, so it would be a mistake to choose it for a new project, IMO. It doesn't really have a future.
Yeah there were a few years there where PHP frameworks were also adding Hack support... and then Hack started to diverge too much from PHP and now I don't think many (any?) PHP frameworks still support hack.
> A legacy codebase means that the product is performing well. It means that I can often make immediate and impactful improvements.
Wow. This person must have worked on very different legacy codebases than me.
Legacy Javascript code, to me, is something that I do not want to touch with a 10 foot pole, because every little piece of it can be intertwined with and used by many other hidden places. Plus, I've never found a legacy JS codebase that has a robust test suite, so any refactoring I do can be hard to test and verify.
From a practicality perspective, I get that the best programming language is the one you can use to build your product, but I tend to long for languages like C# or even Go when I'm trying to deliver a product on a team with 10+ people. Static typing really helps when you're interfacing with someone elses code, and Typescript only aids this point.
Maybe if your target audience is genuinely 10 year olds learning to code, fine. But also if you're building a serious product for a company, please don't choose a "Janky programming language" because I really don't want to have to debug it after you left before really thinking about sanitizing user input.
I feel like, in the hands of a really talented programmer, they can be super productive in PHP or Javascript or really anything. But I've just had a lot of bad experiences with quickly written, undocumented code.
Author here, thank you for reading the article and taking the time to comment.
Every legacy codebase I have worked with was actually a successful business. That probably plays a big role in why I enjoy working with them. The job is not easy, and in one case (800kLOC of PHP without a single function), I had to rewrite everything from scratch.
Legacy JS with its strata upon strata of framework du jour and jquery and porous language are indeed notoriously annoying. To be fair, I just isolate the legacy JS to its own little DOM sections, and then introduce a new framework in parallel until I can nuke the old code out.
Revamping a legacy JS codebase often comes with a design revamp as well, so it often becomes a matter of strangling [1] out the old API. I do really enjoy how typescript allows me to gradually introduce typing and leverage static analysis for more adventurous refactoring.
I use golang, rust and typescript as my daily drivers lately, but I must admit that my most horrendous legacy codebase experience was a tiny 20kLOC go program that was just a mess of concurrency nonsense. PHP codebases have a certain "flatten it out and don't be clever" style to them that make for easy strangling [1]. Highly abstracted codebases where the abstraction doesn't fit the use case anymore, or the abstraction was thoroughly eroded by generations of misinformed developers are much trickier.
What language I would use to greenfield a new application would depend highly on the experience of the team, but my usual approach is "whatever we are already using".
You have to be the most sensible programmer I've run into here. If I could plus one a single section of your post it would be the "Good software is <bullets> none of which depends on the language". Had me nodding excitedly in agreement, subduing the urge to shout YES at my screen.
> From a practicality perspective, I get that the best programming language is the one you can use to build your product, but I tend to long for languages like C# or even Go when I'm trying to deliver a product on a team with 10+ people. Static typing really helps when you're interfacing with someone elses code, and Typescript only aids this point.
This. Languages like Java and C# are great for teams and codebases starting to scale out. Hence their popularity in enterprise.
I think Java and C# are indeed my favorite languages for huge projects with wildly varying developer competence. Python is probably my most hated for that situation.
Though, being optional, it creates its own problems that are time consuming. I have spent a fair amount of time trying to find the right versions of npm dependencies and accompanying @type/whatever packages that work together and aren't saddled with open vulnerabilities, etc.
That's not what I meant. What I meant was finding a matching/working pair of xyz and @type/xyz that were new enough not to have either vulnerabilities (in the main package) and also worked with other packages that were new enough also. It introduces new dependencies and into an already chaotic chain.
Like 1.2.3 of xyz has issues (or dependencies with issues), and you need 1.2.4, but the @type package won't yet work with 1.2.4.
What websites are you working on that have 10+ people? In my nearly 25 years working as a web developer, I don't think I've ever worked with more than three other developers at one time.
Over 10 people worked on the solution for utility meter readings in the Netherlands. All PhP, MYSQL and jQuery. Over 80% of the utility companies were served through this platform.
Everything you say is well and good, but the businesses with the legacy codebase (PHP or Javascript) are still trying to pay someone to work on their systems, and quite frankly, their money is the same shade of green.
That's actually not my experience. I pretty much always had complete technical freedom when brought in as a freelance on e-commerce PHP applications. As long as it enables the business, they let the nerd do the gobbledigook.
If there is no pre-existing test suite, it is extremely difficult to know what is the right expected behavior that should be tested, and what is incidental to the implementation.
Hopefully there is a product team or actual internal users you can interface with to know the expected behavior. I'd expect to at least be able to write some integration-style tests that can ensure everything works from the user's perspective.
If you're so disconnected that you don't know the user's perspective or have no way to see the program in action, then ..best of luck!
Defining big obvious functionality is usually easy to get from people. It's all the finer details that people might not know. You might have a feature that's been relatively untouched for a while, but people still use, so the devs have either left or forgotten from their past "drive-by development".
I tried adding tests to a legacy AngularJS application (it was in the process of being phased out but was still business critical). I sunk days into trying to get a test to run, let alone pass, before giving up and deciding that eventual replacement was going to be quicker than finding good AngularJS documentation.
hella legacy js and php is the opposite of intertwined by it's very nature. every page is isolated. one php file per page. probably some inline js script tags. easy refactor.
and if they're actually using frameworks and libraries.. well that's just being a good programmer. if you don't know how it works, leave it alone and go rewrite a piece that doesn't require rewriting something core
This really speaks to my heart. I learned programming as a young kid when my uncle taught my pascal. But I just couldn't see the point of console programs and never really got into it. Eventually I picked up late 90s HTML (hello geocities!) and php was a natural next step. I still remember going to the library to borrow the book PHP and MySQL web development. It was so empowering. I could make any kind of application I wanted and see the result in my browser, GUI and all (Win32 API was way beyond me at that age). I made my own forums, ebay clone, and a few web apps for an old Korean MMO.
Fast forward a few decades, and things look very different. Tons of web app backends being written in go, nodeJS/TS, and I recently learned people write them in rust+webasm. It's just crazy to me. I've worked on FOSS projects that are massively over-complicated because of their platform/language choice, when they would've been very straightforward php choices. But php still has this weird stigma about it despite most of the old concerns having been addressed.
I do have to say, though, that front end web development is way better than before with the advent of React and co, webpack, css libraries etc. Doing all that html/js/css by hand was always painful.
And then run off for the next job after a year or two and leave the rest of the dev team with your badly written code, so that they have to clean up the mess behind you?
I'm on a team that maintains two projects with over 500k PHP LOC apiece. They're built using a decent framework (Yii 1.x). One of them has a module that's about 25kLOC of AngularJS.
They've each been running over a decade, and while there are some frustrations, it's not so bad. The biggest issue is lack of compatibility to migrate to later versions of the frameworks involved.
They perform adequately for their purposes. These are business applications that are not designed to scale to huge audiences, although one does aggregate ludicrous amounts of sensor data. Both codebases interact with a lot of external systems via APIs and/or batched data transfers. When it comes time to integrate with a new/different backend system, it's not difficult.
Could it all be implemented more elegantly in some other language? Sure. But in long-lived business tools, there's always an evolutionary process going on, and your pristine design from year two won't be useful with the changes they want in year seven. The ability to make fast changes is important.
Lastly, none of this would be possible without functional and unit tests. Those are probably more important than the languages used. They're a pain in the ass to maintain as the business uses and functionality evolves, but it allows the refactors that keep the codebases sane.
Many comments about static typing in here. I agree that it is a great and helpful feature, and it's also not the only feature.
For many other reasons, my languages of choice are mostly PHP, Perl, and JavaScript. And I have experienced the types of bugs that static typing (and also immutability) can help with.
What I have found extremely helpful is to write as if variables are immutable, not allowing myself to change them. And to do sanity checks in the beginning of every function which expects a certain type of value.
Perl's taint and strict are of great help, but I haven't thought of an easy way to port them to JS and PHP. So whenever I can, I do the heavy lifting in Perl, and then use PHP and JS as glue.
The main reasons I have chosen these three languages is their ubiquity and their committment to backwards compatibility. With all three, I can carefully write something reasonable 20 years ago and have it still run today. Sadly, I recently came across a GNU/Linux distribution without Perl, but it is rare. PHP is widely available anywhere with a web server, Perl is ubiquitous in modern (post-2000) *nix, and JavaScript can still be written in ways which work in Netscape 3.x and up.
I think if you want to write software which continues working without too much fuss, it's helpful to exploit the Lindy Effect to your advantage.
You can configure TypeScript to give you the output for older versions of ECMAScript. No need to limit yourself and you get many benefits (not just strict typing but also some constructs like interfaces and enums to easily scale your codebase).
Defining good software is hard. Every definition seems to miss something. Including the definition in this article.
It misses that Good Software is cheap to maintain and can easily have features added.
This goal is hard to meet and there are lots of ways to get there. You can get there with PHP and JavaScript but both languages allow developers to create a mess. Don't get me wrong all languages allow developers to create a mess but these are on the end of the spectrum that requires more tooling to avoid a mess.
I'm a huge fan of strict typing. Because I make lots of stupid errors. Spelling mistakes in variables, that sort of thing. My brain seems to function well at the high level of problem solving but no so well at the details (you might be able to tell from my grammar). Strong typing helps me immensely. Many people don't have this struggle so would rather work with a language that doesn't require the same hoops to jump through. They can do it in manually, and it frustrates them to have to setup types that offer them no value. But for me, to build good software that is easy to maintain, I'll lean on the type system. It will help prevent my mistakes.
So I try to avoid JavaScript. It's more difficult for me to maintain than a strongly typed language. I love Typescript as it fills that gap for me.
PHP is not as bad as it's reputation but old poorly written PHP is. I once witnessed a developer come in an update a legacy code base such that it could be tested. I didn't understand why he spent months working on it. I didn't think it would pay off when there were so many important features to get out. His work completely turned that horrible mess into something maintainable.
I guess my point is that new languages are desirable as they can bring down the cost of maintenance. Some of my favorites are TypeScript and F#. TypeScript is a mainstream way to put the training wheels back on JavaScript and F# is like a dream to use. With Fable, FableRemoting and the Elmish architecture I love it for frontend. It's a hard sell because it's so niche but it's great.
Edit: After reading my comment I felt it was more negative than I'd intended. I liked the article and think the author makes good points, I was just adding my two cents.
Thanks for the thoughtful comment. I indeed haven't fully articulated what is driving me to write this piece (besides a desire to give PHP a bit of love as it is so harshly criticized for reasons I don't entirely understand).
I find "problematic PHP" much easier to untangle than say, "problematic node.js" or "problematic python". Because PHP is often older codebases that have survived the test of time, this is actually a big feature of the language.
The world and web development has much progressed since PHP3/4/5, and pretty much all of that progress can be leveraged with PHP as well. If I were to green field a new project, get to pick every developer on my team and a budget to match, I would probably not chose PHP.
But, if the problem were "we want to try out an ecommerce SEO idea and don't want to sell our soul to shopify if it is successful", wordpress/woocommerce + a few janky plugins and templates + a custom plugin with 1k LOC is totally something I would consider. And I absolutely loathe wordpress database legacy sludge.
If I have a team of experienced PHP and wordpress developers, a set of internal plugins that can be repurposed, and I can pay a freelancer to build custom react CMS components, using PHP and even wordpress for a new project is a no brainer.
I had a bit of a laugh as I read this. I realized that PHP is my go to language for very simple side projects. I have one that is left alive. It runs the scheduling of greeters for a group I'm part of. Every week we have two people stand at the door to greet new people and help them find their way in. We used to have a spreadsheet that managed it but I kept forgetting to update it and send it out. There were also some rules that made it tricky. Like you don't want people to repeat too often, you want spouses to be on the door together and a few other boring details that made the spreadsheet a chore.
One weekend I got sick of that and threw together a tiny website that automates the entire process. My tool of choice was PHP because it takes no effort to get started. TBH it was a great choice for such a simple tool. It's been running for five years and has easily paid off the time it took to build.
Back in my college days, I was exposed to web application development because of PHP.
Angular was still in its infancy and I was not aware of AJAX at the time. PHP frameworks, specifically Laravel and Code Igniter, made it very easy for me to put my computer science education to practical use. And I was dropping files off into our student workbenches via FTP! There was very little overhead for me to get anything online.
I hardly ever use php, but when I do, I’m always surprised by how good it is. Its the only mainstream progamming language that is specifically designed to make backend web applications, and it really shows.
Rails is right up there. I work daily in projects in both Rails and Laravel, and while Rails has the upper hand in many places, Laravel does win in a few categories.
Which amazes me, I thought I’d never find something that can compete with Rails.
Biggest flaw of php to me is getting paid well and the number of jobs.
From the stack overflow dev survey, php devs get paid much less than others.
Laravel and php is a beast, super easy to use. All that annoying shit is setup for you. But, how many ppl hire Laravel devs? Job boards are stacked with react, vue etc. Personal use is great though.
I'm a PHP dev, I didn't take part in StackOverflow survey and ~15 senior PHP devs that I know personally didn't take part either. Judging on such a small sample, I'd be guessing that it's safe to assume that survey is missing crucial data from people who do get paid well.
I'm 22 years in the business, 16 years working at the same place. At this point, there's various bonuses next to salary. After so many years, it's the domain knowledge and ability to figure problems out what gets me paid.
I don't have to work with the tool that someone tells me to use, I'm free to choose language/stack that I think is appropriate to solve the problem (deliver the project that's maintainable/useful for the customer).
I also don't take part in any surveys which makes the accuracy of the data questionable. There's plenty of people like me, what I learned is that a lot of senior/capable devs don't use social networks or sites like SO.
Approach the results of the survey very careful, false data is dangerous.
That's how sampling works, not everybody writing Java, Go, or whatever else is filling out surveys, either. I know I haven't.
I haven't looked recently, are there a lot of remote positions for US employees writing PHP for $200k+ base plus bonuses?
I'm not even talking about the crazy-high comp from FAANG companies here, just Principal developer roles paying more than $200k base, with bonuses as well.
My anecdote and your anecdote combined don't make data, of course, but I know my comp climbed pretty dramatically when I left PHP behind.
Our anecdotes don't make the data, of course. My point was that narrow thinking in terms of languages is inaccurate and cannot be relied upon when it comes to choices relating to career.
Choosing the IT field because of compensation alone and then relying on top charts to choose the tech is what yields low quality.
Ultimately, every dev with 2 decades of experience will know more than 1 language and learn that tribal language/framework wars aren't helping anyone.
Getting things done and being of use is what our profession is. When one becomes useful, then the real career starts.
I didn't choose to leave PHP for comp alone, I was surprised at the dramatic shift on comp after the fact. I certainly don't think I've said anything that suggests tribal warfare. PHP can make for some amazing productivity, for sure! I think I last coded in PHP about ten years ago, maybe a bit longer, but it definitely has its place in the market.
I only note that you didn't answer my question, so I think I'm going to carry on with my assumption that there aren't a lot of PHP jobs in the US paying $200k+ base. Not that someone should choose a career path solely to pursue higher comp, of course.
Community sentiment means almost as much as technical facts. PHP might be just as capable as Ruby, but the vast majority of devs, especially experienced ones, do not like it, will not suggest it, and will not apply for companies which use it.
> especially experienced ones, do not like it, will not suggest it, and will not apply for companies which use it.
That's a bit of a reach, I would work for a company like Slack or Wikipedia of course even though they use PHP and so would many other devs. In fact the further I am into my career the less the tech stack matters to me; I've come to realize the bosses and the company's culture and leadership and how they generally treat employees is WAAYYY more important than whether the stack is Rails or Node or PHP. To me. They are all web stacks that do more or less the exact same thing and the work you do is really quite similar on all of them.
I was sure being a Rubyist is what makes me happy because I like Ruby...well guess what, you can be miserable in a Ruby shop...that's the lesson I've learned.
If I ever become super choosy about tech it's only because I really wanna switch directions - e.g do low level development or something like that which is dominated by C. But all the high level web languages ...are all the same to me (my preferences aside).
I would say PHP takes effort to make maintainable projects, and allowed some of the most heinous code I have ever seen in production. It was likely the years of spiral development that made it so problematic.. and pear finished the job.
The good parts were a small memory footprint, fast soap/xml parser, and stateless finite execution. Unlike the 200MiB+ "hello world!" async nodejs standard popular today... one can run small php cms/wiki sites on budget servers.
So do thousands of people, because they're pragmatic and useful. They're the Honda Civic of the working software world. For people doing real work, you have a whole host of great languages available, and there's no sense in pretending that one of them isn't PHP just because you think you're still doing comp sci at uni. There's definitely better languages than PHP, no doubt. But we're in the trenches now, getting stuff done, and people have been getting great things done in PHP for years.
I learned PHP as a kid in the 90s. It always seemed too easy to use it, almost as if it was a toy language, and I thought there's no way that professional programmers actually work this way. But here I am, having spent ~50% of my career in PHP off and on.
Each PHP file is a magic hot swappable component. Not some bulky binary you have to full compile/deploy on every tiny change. What other web technology compares?
in the last decade I don't know when compilation has ever been something I've ever thought about, all modern frameworks for any language just hot code reload for you.
although if you're talking about your deploy process being dragging and dropping files onto an ftp server, not only is that horrifying but it doesn't win out on automating it with any one click deployment tool out there
On the other hand, if your production is already broken, it's much easier and quicker to apply a hotfix in PHP (just edit a file on the server directly) without waiting for the whole CI/CD to finish.
This leads in turn to testing/developing in prod. I do not personally miss it. If you have CI/CD you should not be able to skip it.
Maybe putting it under a feature flag would be a safer alternative.
I was talking about a situation when prod is already down and something is better than nothing. For example, once we forgot to add timeouts to calls to a third-party service, everything worked great for a year, then suddenly the third-party server started hanging for no reason which made all our PHP processes hang, too, and those processes were holding DB connections so we went out of DB connections as well and the whole production went down. We quickly found the root cause and applied a hot fix (setting the timeout) by editing a PHP script on the prod server without waiting for the usual cycle "pull request -> code review -> deploy to stage -> testing -> release" which can take an hour.
I spent the afternoon with Laravel, the first real framework I have touched in a decade besides Magento's Behemoth of a MVVCnotreally.
It was quite sane, I had a very nice time. My application works as expected and it took me a few hours to complete, while learning the sort of get-up-and-go bits from the documentation.
PHP was my first backend language when I deployed my first project on the web. So easy to deploy and easy to enter.
I still love laravel until now, would choose it again sometimes just to have fun with it. However it's just never used in big companies so I always end up with python or java (not even c# around here except MSFT lol)
TBH I don't like PHP but I admire how easyly deployable and ubiquous that it is.
It's so omnipresent that that Spolsky used a sort of translator from ASP to PHP to be able to run Fogbugz un Unix systems[0], which I think is a neat idea (at least for a source lang subset and with tons of problems to be solved, but a neat idea nonetheless).
I love PHP, it fits that niche of having a fast startup like Perl, while having a big standard library like Python. However after using Go and Rust, I don't like the idea of the package manager being this separate thing (Composer).
I think the package manager should be part of the PHP distribution itself, not some other thing that people have to find and install separately. I am fine if people want to implement other/better package managers, but I think the PHP distribution should include something, if only a rudimentary tool.
> NPM isn’t bundled with JavaScript, and it seems to be doing ok
I'm not sure what point you're trying to make here. If you install the Node runtime, it comes with NPM. So it seems you're not correct about this, unless you are referring to some other runtime. And even if you are, why would some other runtime include NPM?
huh? Node is a JavaScript runtime. Its the "base thing". Its "JavaScript", at least in the sense that we are talking about here. So saying "Node isn't included", doesn't really make sense.
When you install Node, you also get NPM, which is essentially what I said in the previous comment.
> When you install Node, you also get NPM, which is essentially what I said in the previous comment.
The other person said that JS also doesn't include a package manager. It sounds like you wanted to take issue with the colloquial use of NPM rather than their point about package managers not being included.
> I also don’t believe a bundled package manager is necessary — NPM isn’t bundled with JavaScript, and it seems to be doing ok.
> Composer is the de facto package manager for PHP. I’ve never seen anyone try to compete with it.
According to common PHP culture, there's no need - since it's already good enough. Instead of re-inventing something you can just move on and get your own sh*t done. :)
On the other hand JS now has many package managers yarn, pnpm and even competing runtimes deno, bun that include their package managers and have often incompatible code.
Composer is atleast undisputed, embraced and works well. Anything PHP is on there. Package formats are unified not like in JS.
Python's pip is developed separately, but the main repository is operated by PSF (authors of Python), and python's source code nowadays contains the "ensurepip" module to install pip if needed and official binary releases contain pip directly.
Think about it like this. How would you feel about Go, Rust or Node, removing their package managers from all new versions? Then they make a blog post saying, "we are going to let the rich community handle any future work of developing and distributing a package manager".
2 years in, but same. Made especially beginner friendly with modern tooling [autocomplete, hover:documentation, Copilot]. Any advice/recommendations/resources for people in that weird transitory stage between ‘getting it’ but not quite Senior Enterprise Software Architect?
I think I learned it through a couple of venues. I am still thinking this one out, and definitely plan to write a post about it.
1. designing "big" enterprise software from scratch, on paper, and then building a toy implementation.
I would say 95% of the actual work that goes into a big enterprise codebase are error handling, logging, changing requirements, covering the 80000 different user cases, while the architecture itself (a message bus, a pub sub pattern, a cache) can actually be written out in a few hundred lines of code.
This toy implementation can then be used to run multiple experiments: what happens if the message bus gets choked out? what happens if messages get reordered? how do you change a message schema?
These are rare and intense efforts in real life, but you can cosplay them with a few docker containers.
2. reading big existing enterprise codebases.
This is a skill that is not often taught, and people starting to read big codebases from "main.go" are usually doomed to fail, as they will hit the "big wall of enterprise indirection". Instead, try to get the codebase to compile, skim all the files at random until you think you recognize something, set a breakpoint in your debugger and run some part of the test suite or the real thing if you are adventurous. Then, try to mess with it some.
Once you found your marks, try to understand where all the big blobby nebulous enterprise nonsense comes from, and why it is there. Often, it helps to look at the source control history to see when it was introduced, and if design documents relevant to the change can be found.
I try to "read" a big unfamiliar codebase every couple of months. It could be kubernetes, or nginx, or webpack, or typescript, or react. You learn a lot about real world production code.
The amount and quality of opensource projects out there is nothing short of incredible these days. When I was coming of age in the early 2000s, it was linux, GNU, apache and a few other autotools driven monstrosities, with a CVS repository and a crusty mailing list.
3. learn to write RFCs
I started practicing writing relatively late (in fact, my blog just got started a few weeks ago), but learning to communicate clearly about design is vital. I have always done a tremendous amount of whiteboarding, and do most of my development on paper with boxes and arrows. I think this also develops a sense of "architecture" vs "code".
sucks on the hiring end too. I'm willing to pay but don't know how to weed out the cruft. building something with a full ux mock and prd anyone can do. actually figuring out the requirements and then so building that... seems harder to find
You can write good code without compile time type checking, but it requires so much more developer focus to avoid writing bugs than a language with type checking. Everything else, php’s “jankyness”, javascript’s mystifying truthyness tables, those are easily overcome
problems. Handing a string to a function expecting a number, and not finding out about it until that code actually runs? That’s the real problem, imo
thanks for reading and commenting. I am incredibly bullish on static typing and static analysis in general. There are quite a few tools that bring these to PHP and JS (I am not entirely happy with PHPStan / Psalm, I am very pleased by Typescript). Before that, I have been using Jetbrains analysis tools.
In web development, I find that there is a certain freedom that comes with dynamic typing that I wouldn't tolerate in other systems software (my other specialization is embedded software), as easy templating and logging are givens.
The fact that so much in web can also be "caught" at runtime (monitoring, logging, tracing) changes the game quite a bit as well, giving dynamic typing a bit more breathing room.
I think it's the fact there are no compile times (those runtime tools you are talking about are at your fingertips) that people historically have not worried as much about types in PHP and JS. In many cases it does just feel like verbose boilerplate rather than a useful tool. Type checking is just one of the many things you can test by hitting ctrl+R, and you will be doing that anyways to test everything else. (Obviously, the bigger the project, the less that is true, but that argument is well-known). Personally, I spend exponentially more time correcting my typos than my types, and auto-completion of previous used variables and functions is worth a lot more than a type system to me in my day to day.
I will never argue against types, but unless I am working with somebody else, I don't need them.
I have used PHP extensively and moved to node then finally settled on using golang. I think PHP does have a place as a current programming language but much more small scale operations.
It is just more complicated, to run a PHP site you need to have knowledge of PHP, PHP config, server config, the tooling is poor, there is always something else you need to bolt on to get a similar experience to a modern development language, there are so many ways you can write bad code or write code in a different style to others around you sharing this in a team is hard.
At my company we still run PHP apps and everything we want to do as an organisation is relatively simple in Go, but hard with PHP. I imagine the issues and problems we have with it are why it is not well used in large organisations
PHP was my main language from 2000 to 2011. I liked PHP 4 very much. "Pass by value" was the default, so it accidentally introduced me to the Functional paradigm, even though it didn't have the memory management to allow for real functional programming. (It did not internally share memory between old and new versions of an object.)
I dislike the direction that PHP has taken since the introduction of PHP 5. For the last 18 years or so, the language has been trying to become something like Java, but without the speed benefits we might get from it being compiled, and without the strictness benefits we might get from being strictly typed. Nowadays it has most of the heavy rituals of Java, but without any of the benefits.
The single greatest thing about PHP, circa 2000, was the abstraction it calls an "array" which combines what other languages would call a vector (or a list) and a hashmap (or dict in Python). That array construct was very flexible and allowed me to get away with a great deal. Later on I discovered the "seq" abstraction in Clojure, which is even more incredible, and has the added benefit of being done correctly, in an academic sense.
After 2011, I increasingly relied on Clojure, for any task where dynamic programming was reasonable. Clojure puts me on the JVM and allows me to drop into something like Java, and strict typing, in the rare cases where that seems necessary.
PHP in 2000 was extremely lightweight but nowadays it demonstrates of envy of heavier object oriented languages, but again, it still lacks the speed benefits of being compiled or the correctness checks offered by strict typing.
The article lists these benefits of PHP:
* speed
* ease of deployment
I don't think anyone would pick PHP purely on the basis of speed, again, there are many languages that are faster.
In terms of easy of deployment, any deployment of PHP (or Python, or Ruby) tends to mean deploying tens of thousands of files. By contrast, when I work in Clojure, I typically uberjar the code, and then I only have to deploy one file, which makes deployment ridiculously easy.
An amazingly fast specialized JS runtime solution [1][2] does indeed have the #1 spot on the most recent rounds, but full PHP frameworks hold spots #2 - 29 and then it's a mixture of PHP and JS all the way to #58 before we see the first other language (python, uvicorn) emerge.
You can also do some pretty "fun" things with PHP leveraging the opcache. I wrote what in my own personal biased benchmark was the fastest mustache template renderer by transpiling mustache to php files and then "compiling" them with apc [1]. Kind of a poor man's staging / partial evaluation optimizer.
This is still running https://goldeneaglecoin.com/ whose framework (and HTML/CSS) is pretty much untouched since 2011. It is running on an ec2 t2.medium instance and is one of the fastest e-commerce sites i know.
wow, that was some incredible performance, never thought php could be this fast, I was in a dilemma on what language to focus on as an ordinary dev,
think I'll stick with php for a while longer.
I abuse the crap out of PHP "arrays" between mapping to JSON rather well and allowing you to really put some strange data, functions and objects into them you can really get some work done with data processing.
I kinda like js but hate php with passion. Having said that php has one really very big thing going for it - people who use it are simply addicted to getting things done.
This! I use it as a mix of web applications and back end code, like you would with python. More and more my scripts I'm writing in PHP never see a web browser but the power of PHP Data processing has allowed me to really glue APIs together that have no official support in anything. I really do love it for being able to bash out a program in a afternoon and have it do amazing things.
Not at all. Just seems like PHP people are laser focus on getting things done maybe because the language and it’s runtime is so primitive there aren’t any distractions
thanks for reading! I use legacy code as in "code that was written yesterday or earlier", or in a less jokey fashion as "code that noone really feels ownership for", usually a codebase that shows the sign of many developers, repeated cycles of outside pressure. What I mean by "product performing well" is that the legacy codebase is still alive for a reason: it is doing its job and the job has value. Otherwise it can just be cut and deleted (a very pleasant refactoring technique, I must admit).
Yes, I got that. I didn't feel that the "alternative definition" was offered disingenuously, but it's still a problem when you want to have a discussion and you use certain commonly accepted terms, but with a different definition in mind. Imagine if I talked about "democracy" and in my mind I meant "The Athenian model that only allowed men over the age of 30 to vote", when everybody else was talking about, well, democracy.
In case you're not familiar with the book (i.e. "M. Feathers, 2004. Working effectively with legacy code."), it is a classic and widely regarded as "The" book on how to approach legacy codebases (even if a bit dated by now). A highly recommended read. It was also very enjoyable to read, which is remarkable for an otherwise technically-oriented book. Here is the relevant except from the introduction, defining what legacy code is and why it's a problem:
> In a strict sense, Legacy code is simply code you've gotten from someone else. However, clean, easy to work-with code is rarely referred to as 'legacy' code; the term usually implies a tangled, unintelligible structure, difficult-to-change code that is difficult to really understand. Therefore, a more pertinent description is:
>
> Legacy code is where any of the following questions fail to apply:
>
> - Is your code easy to change?
> - Can you get nearly instantaneous feedback when you do change it?
> - Do you understand it?
>
> If the answer to any of these questions is no, you have legacy code, and it is draining time and money away from your development efforts.
Further down, he offers this simpler, provocative definition, which introduces the main theme of the book:
> Legacy code is code without tests: Code without tests is bad code. It doesn’t matter how well written it is; it doesn’t matter how pretty or object-oriented or well-encapsulated it is. With tests, we can change the behavior of our code quickly and verifiably. Without them, we really don’t know if our code is getting better or worse.
In a more modern setting, presumably 'tests' would be extended to include other good software engineering practices, like version control, CI, etc. But the book's theme still applies in the more general since, so it's still relevant today. If you've not read it, then pick a copy up, you're in for a treat :)
I definitely studied that book when it came out. I feel my definition is the same as his "Legacy code is simply code you got from someone else". I have seen MANY legacy codebases with tests. Surprisingly often these tests are not only useless, they were partly responsible in reifying horrible wart-patching on top of an outdated abstraction, as replacing the abstraction as requirements changed would have required a new test suite.
As I'm gaining more experience tackling project from a business perspective, when encountering a legacy codebase, it makes sense to start reviewing the business assumptions. Does this codebase even make sense in view of the current business strategy? If not, there's probably big chunks of code that can be entirely "written of", yet need to be kept alive long enough to migrate without disruption. Unit tests can help, but I often found deleting the unit test suite and starting a new one a more productive approach (again, with my experience of 6-7 projects).
But we agree. The book is a bit out of date, and it's focus on approaching the problem using 2004 agile techniques is not something I would fully recommend anymore, but I have yet to find a replacement (maybe there is one out there, I haven't looked recently)
I like PHP for its simple deployment. Symfony has some interesting concepts with the adoption of Stimulus via their UX packages. But their ORM and Queue handlers are a bit annoying. Or maybe i'm just too dumb for that, because i'm just a hobbyist.
Yeah spaghetti code people then love react/jsx/vue… in vue single file components include html/js/css (structure/logic/presentation) in one file and everybody loves it. In PHP you structure it same way (even without css) and its WRONG.
I feel like Emberjs is the PHP of JavaScript frameworks. People looove to BS about it with no apparent reason.
I mean, everyone knows tech is moving fast. Especially the JS ecosystem. So now why are you talking sh*t based on your experience like 3 or 5 years ago? At least just go around and read more before you comment.
I think that php has some weird disk usage behaviour that makes running Wordpress in a docker environment slow. I don’t know exactly what it is but I would say it is a weird behaviour of php anyway.
Wordpress is just bad. PHP is leader in CMSes but the old ones Wordpress, Drupal have to support so much legacy stuff. Including wierd patterns hand hacks from the past.
Modern CMSes like Craft, Kirby, Twill, Bolt, October… it is very different story.
And will your database, webserver, php and linux auto update itself next 20 years?
Reality of that is that most people will use some plugins or their theme wont update or your code will have breaking change.
The auto update is nightmare. Because so many people are trying to hack WP you gotta do it and every other update becomes stresfull event. Good luck updating someone elses plugin.
Much higher chance of website working 20 years is - take simple preferably file based system. Make manual update every 5 years. If its good system then the migration will be well documented and painless probably taking 5 minutes.
Wordpress is elegant with its hook system. It is easily customisable. Virtually in each and every step you can modify the wordpress software via plugins.
You need to make sure disk writes are against mounted volumes and not against the CoW filesystem in the container but that's a docker thing not a WordPress thing.
In 2022 there is no reason to prefer these dynamically typed languages over statically typed ones for production code. When languages like PHP, Ruby, JS blew up the knock against statically typed languages was the verbosity of the resulting code, slow development cycle and general cruft, these languages solved a real problem at that time. That is no longer true today- TypeScript, Go, C# code feels as fluid as a dynamic language and even Java has come a long way with type-inference that Java no longer feels as unwieldy as it used to.
I legitimately can't imagine willingly not using a statically typed language for anything that matters that's gonna have more than just me working on it.
"No reason", at all? Have you seen how much standardized legwork is done with a backend framework like Rails and Django? How much easier that is to work with other developers because everyone is following known conventions? With Django, there's also the huge benefit of millions of data libraries an import away. When I search for client libraries to do something, anything under the sun has a Python client. Much much less so with Go, C#, and Java.
> Have you seen how much standardized legwork is done with a backend framework like Rails and Django? How much easier that is to work with other developers because everyone is following known conventions?
How is Django different from, say, ASP.Net Core in that respect?
You lost me at Java. Web development was popular in Java well before it took off for Python, and it's been one of the most popular programming languages period since it's inception. There's been multiple supported clients for anything I've ever wanted to connect to.
Often times, as a programmer, it's easier for me to change my environment, language, or learn their stack to be helpful to them than it is for the company to switch their stack because of my unwavering views on "right" languages.
I agree. But no developer starts writing unshoddy code right away.
There's a lot of really great developers that got their feet wet with dev work because Wordpress is immediately accessible and helpful. They just needed a playground to write shoddy code before they matured and perfected their craft.
In my opinion, I'd rather people write shoddy code and improve it than wait until they've ready enough books to write perfect code, but never actually start.
Doing something subpar now is often better than waiting till it's perfect and not doing it at all.
job security in software development isn't a problem especially since the pandemic started, if you're working on crappy code its because you're choosing to at this point
I assume this is meant in snark, but jquery was such a breath of fresh air when it came out. I have been doing some SPA stuff with raw DOM, later on mootools and yahoo ui around 2003-2004, and that was really the wild west.
if you are getting shit done then that is all that matters - but it is hard to find a compelling reason to start with PHP these days unless 1. you are constrained to commodity godaddy-esque cpanel hosting or 2. you have an entire team of PHP devs.
I find Laravel a very compelling reason to start with PHP. If you start with Laravel today, you're most likely in a position to start with php 8.1 which has nearly none of the issues plaguing the earlier ones.
Rails of course is a great alternative. Depending on your requirements, experience and preference etc you might choose that over Laravel given that from what I heard they're similar in productivity and features.
There is one main reason devs get into PHP. Content management systems. People here forget how many developers create content websites not products. PHP is pretty massive leader in CMSes. And i dont mean legacy stuff like Worpress. Most modern ones are essentialy light MVC framework with admin panel. Many are even based on Laravel.
So by doing CMS dev you end up with pretty good skills with php+MVC. Why not use it for webapps?
that's great! Because of its benefits, it's always been one's favourite. Hire Backend Developer(www.hirebackenddeveloper.com) for your PHP and Java based project requirements.
I love to hate PHP. From a design perspective it is pure garbage. It allows you to do so many basic and stupid mistakes which better language design could have prevented.
- it's stateless by design (much easier to scale)
- it was "serverless" before Serverless
- surprisingly performant
- no "unknown unknowns". it's so tried-and-true, there's no surprises
- deployment is so simple, just drop a file on a web server. No middleware needed.
- No long compile times because there is no compiling needed.
EDIT: why the downvotes? If you don't agree, just reply so we can have a healthy dialogue.
EDIT2: I also think there is something unique about PHP documentation. It has plenty of real life examples, and the ability for users to leave comments allows you to hear directly from others "gotchas" that people have experienced. I feel like PHP documentation is very undervalued.