This 100%. It's actually a bit of a red flag to me these days if a developer turns up their nose at PHP. The language has matured a lot and building stuff with it is simple, cheap, straightforward and fast. If someone's still hating on PHP in 2023 it makes me wonder if they've been focused on more exotic technology because they were looking to pad their resume with more expensive skills, build science projects for their own amusement vs. what the business needed, etc. etc. Red flag. I've had these guys like this on my team and guess what, they built fancy over-engineered solutions to problems that no one had and then job hopped and left it for us to deal with. I can't speak for anyone else but I go into work every day for one purpose, and it's to ship shit which users use. I don't have room on my team for people who have other priorities. The amount of stuff you can get done with basically just PHP and Linux is amazing.
Don't you dare to tell me that my isomorphic Node trpc graphql with redux and sagas on top of next.js with SSG and SSR and parts in server components with my home grown validation and ORM framework and still no translations because they don't work together with everything else and deployed on serverless docker lambdas to a kubernetes cluster is over engineering a landing page with a contact form. So fast!
That's a state of the art WebApp. You old PHP developer!
Don’t forget to deploy all that code to the edge. Your $5 VPS in NY running both nginx and MySQL is going to be a huge bottle neck when somebody in Texas tries to view your simple website and it takes .10 seconds longer to load. You’re going to want that contact form code on at least 1,000 servers worldwide for maximum benefits and conversions.
Also, now that you are on the edge and your form submissions are web scale you likely need to model eventually consistency for the processing so you will need a highly available queue running somewhere.
Joking aside, as someone who runs their entire saas off a single bare metal server in Las Vegas, I have been toying with the idea of pushing some stuff to the edge. The reason being, sometimes those average load times are not giving you the real picture. If my average load time is 560ms per request because 90% of requests are 400ms and 10% are 2 full seconds, that might be a problem. Fixing those 10% requests and bringing them down in line with the rest would equate to an average speed up of only around 100ms.
However, I'm not yet sure a complicated edge deployment would actually fix the 10% problem.
I like the idea of a "Progressively Enhanced Monolith". Start by building the core of the application in something like Laravel that can do anything and be developed quickly, then stick it behind a proxy/CDN like Cloudflare. Then if you find endpoints or pages that are accessed frequently and would be better as their own microservice then use a small serverless worker to either respond directly from the edge or forward the request onto a microservice.
I'm jumping on the conversation , actually my portfolio website is on cloudflare pages with astrojs , it costs me nothing to host it , has a quick way to develop . I higly recomend it
Though to be fair, devs lose employability when they don't get to use (in their work) technologies that are gaining wide popularity. It's a balance to be struck by the CTO/architect (assuming the devs want or are able to demand that skills development in the first place).
> If someone's still hating on PHP in 2023 it makes me wonder if they've been focused on more exotic technology because they were looking to pad their resume with more expensive skills, build science projects for their own amusement vs. what the business needed, etc. etc. Red flag.
I get that you are arguing from personal experiences, people you met and worked with. But this statement lacks context and nuance.
There are developers who don't like PHP because of outdated reasons and possibly because they are snobs. Sure, that's a red flag.
But there are many who have so many battle scars and war stories with the language and its ecosystem that they decided it's just not worth the pain anymore. Even though PHP has evolved (with regular breaking changes...) and tries its best to put something useful on top of a shaky foundation: The effort required to make PHP work with you, in comparison to other languages, becomes too large and painful. I'm not talking about superficial things here, nor do I have the tendency to overengineer stuff, quite the contrary. I'm talking about writing simple, robust and efficient code.
However I would say there are three very good reasons why you should use or at least consider the language:
- You want to quickly hack together something useful with minimal fuss, AKA its original purpose.
- Buy-in of the OO, code generation, IoC/DI, magic framework stuff that Laravel/Symphony provide.
This comes across exactly what the previous poster was saying as someone who turns their nose up to PHP. Especially the "you have to" gibe.
> But there are many who have so many battle scars and war stories with the language and its ecosystem that they decided it's just not worth the pain anymore.
I could say the same thing about javascript from the early days, through Jquery, and beyond. Should I turn my nose up to modern javascript because of the past 2+ decades I've been working with it? No because they are "outdated reasons" as you say
> The effort required to make PHP work with you, in comparison to other languages, becomes too large and painful. I'm not talking about superficial things here, nor do I have the tendency to overengineer stuff, quite the contrary. I'm talking about writing simple, robust and efficient code.
> I could say the same thing about javascript from the early days, through Jquery, and beyond. Should I turn my nose up to modern javascript because of the past 2+ decades I've been working with it?
Yes. And I say that as someone who has been developing "modern" Typescript web apps full-stack for the last few years.
My issue with JavaScript are fundamental to language design decisions that can't be removed due to major breaking changes. Things like having to deal with `undefined` AND `null`. `==` vs `===` (more specifically, type coercion), prototypal inheritance in addition to ES classes in addition to TypeScript classes. Array.push causing mutations. Having `for of` in addition to `Array.forEach` etc. etc. etc.
And then you have the fact that it is neither OOP nor Functional. So you get people from both backgrounds, and ideologues from both backgrounds, trying to squeeze JavaScript into their preferred paradigm, within the same code-base ... and JavaScript obliges. Because it is neither.
Every single JavaScript application looks radically different from each other and, worse, in a large organization with many teams working on a common code-base, consistency becomes damned near impossible to enforce.
And so you start adding lint rule after lint rule after lint rule until you have an entire team dedicated to maintain your custom linting bullshit.
JavaScript is a complete shit show to this day even if it does have nice features and even if you can get up and running with it quickly.
If it weren't so popular, and if it weren't the "language of the browser", I wouldn't recommend it for anything other than small teams who can decide on which "version" of a JavaScript adventure they want to strictly adhere to.
Same experience. JS is shitshow and dumpster fire. I’m picking up Vue 3 and every time I have a new question I need to ignore Vue 2 documentation written 1-2 years ago because the paradigm has shifted away from the “option” API to “composition”. The same jarring change experienced in the React community when it shifted to hooks. It is no wonder I can find a cascade of defects in just about every modern website made written within the last 3 years.
It is not only bad for the developer, but for the users, too. The overall confusion and frustrations are abundant.
I don’t turn up my nose though. I don’t judge anyone for choosing tech, especially if they have good reasons.
I’m also very loyal and pragmatic. I really tried.
I don’t want to start a language war here either. What I said above was a counterattack on the idea avoiding tech that doesn’t agree with you is somehow a red flag.
My general point is: consider that there are people who have earned their opinion the hard way. Even if you disagree.
> magic framework stuff that Laravel/Symphony provide
The magic in these frameworks is evil, and likely a big part in ruining PHP's reputation. Laravel in particular hides way too much stuff behind magic, and when it goes wrong you find yourself sifting through OOP-obfuscated layers of framework and libraries just to find out how exactly your controller is called.
This is one of the reasons I like PHP, in newer PHP versions it is an attribute but in older versions it is just a comment. Clever and backwards compatible.
It isn't backwards compatible (`#[foo` used to be legal PHP 7, but is illegal in PHP 8).
It may technically be forwards compatible syntactically (`#[foo]` will, as you say, just be ignored by PHP 7), but that's an anti-feature (assuming that the attribute isn't a no-op, it'll presumably break something else).
And a program can generally read its source code and make fancy adhoc interpretation, sure. That’s nowhere close to specified facilities that you are guarantied to be able to use with a fair amount of trust in the resulting outcome with the regular toolbox.
I honestly prefer community supported battle proven production ready "magic" than what most product developer under a deadline cobble together. In my experience the problem you describe happened like... 2 times in my 20 years career. And I literally spend my entire days fighting my own colleagues very explicit smartnesses
One is that the framework can do all the magic under the wood, or not, and in (almost) no case leak any clue about that.
Or, the framework can provide a lot of facilitation through conventions and there no real benefit to use this framework if you don’t leverage on these facilities. Having conventions doesn’t mean you have to be acculturated to all of them upfront though, as with proper modern IDE the learning curve can be very smooth and funny.
> when it goes wrong you find yourself sifting through OOP-obfuscated layers of framework and libraries just to find out how exactly your controller is called.
debug_backtrace() has always been my friend in situations like this
What ruined PHP's reputation is people believing the language itself was a sufficient framework and unsafe SQL and escaping practices being the norm, due to naive developers (which PHP has plenty of) thinking the simplest solution (eg concatenating strings and variables into SQL queries vs prepared statements) is always the most correct.
I mean, with PHP you either use a framework or you necessarily end up writing your own ad-hoc, informally specified, bug ridden implementation of one. At least frameworks like Laravel are battle-tested and should at minimum cover the most obvious issues.
I agree with you. But, and this is a big but, it's a tradeoff. You also get benefits.
This is why I said "buy-in". If you are comfortable with doing things in their way, you get a ton of leverage: easily consistent code, a fast and productive "get off the ground" experience. The downside is what you described.
Personally I'm just not a fan anymore of these things. You quickly produce code that _looks_ clean and consistent. But it's also bloated and brittle, especially if you need to break out of the happy path. A framework like that is great if you don't do software design, but more of a hindrance if you do. There's no framework that can help you do a holistic solution. For that you need good tooling, a robust foundation (AKA not PHP and probably not JS) and a simple design.
Again: Trade off.
That's why many here in these discussions will tell you that X or Y is the best thing since sliced bread - because it fits their needs almost perfectly. But you also get many (like us) who have at least some reservations, because had to bend over backwards to fit a square peg into a round hole and ultimately wasted so much time that using X or Y wasn't worth it at all.
It's like that with every framework: Laravel, Rails, Django, you name it.
If you build a class of thing which the framework creators had in mind, and do not have a need to deviate from the prescribed ways, it's a force multiplier.
Once you try to build something that does not fit the confines of the framework, it's of course possible, but the framework stops helping you, and after some time becomes more of an impediment instead.
"...Once you try to build something that does not fit the confines of the framework..."
Can you provide an example of that? In my experience people think too quikcly they're smarter than the community behind the framework and that it doesn't fit their use case, and the real cause is just that they don't "like" the recommendations and think they can do better. Plot twist: They don't, and usually end up creating a terrible mess. What would be the alternative? Building your own in-house undocumented, untested, unproven framework and/or tying together 100s of libraries? Are you convinced that's going to lead to a better result for all use cases of your application? And that once you leave the company, the next developer will think "Oh, this custom framework is great... I'm glad they didn't use Rails/Django/Laravel"... not my experience... at all.
I think that these frameworks are the best choice for most project, and if they're not (Like.. you're building Google Earth or Figma or something really different) then the problem is that you picked the wrong tool from the get go.
I don't think that "this one special case" is special enough like to not use a batteries included framework and go wild with your imagination. Unless you're a FAANG, otherwise you're wasting your employers money.
As an anecdote, I once worked for a shop that used Django. One of the developers before I was there "decided" the Django ORM was bad and promoted bad practices, etc, etc... so he wrote his own "better" ORM on top of a postgresql library. You can imagine how that went, specially after he left and the second gen of devs arrived to deal with the monstrosity.
This happens a lot more frequently than you think.
We should stop thinking we're "so special". We must focus more on providing business value by writing product code, tests and documentation and less rewriting the world because it's cool.
I've been building on Laravel for some years now and I'm always delighted how you can just ctrl+click and see the internals (and the magic). They're pretty modular and extensible/overridable.
Those resonate with me reminding menof some of the worst development experiences in my career. Different language, different ___domain, but I recognize it. The simplicity is alluring, and even enticed me at first. It just doesn't scale for problems that are complicated vs the ones you are shown as marketing. The managers and architects like it because it hides the confusing or non-elegant details from view, but that just makes it hard for the devs to work on it.
> But there are many who have so many battle scars and war stories with the language and its ecosystem that they decided it's just not worth the pain anymore
This applies to absolutely every language or stack. You switch to Ruby because the grass is greener, and 5 years down the road you feel the same. Then you switch to Kotlin or Erlang or JavaScript and you'll end up hating it anyways if that's how you roll.
I love PHP, but a red flag?! If they’re busy in the Ruby/Java/C#/Go worlds (all get-it-done environments) then I’d just assume they don’t read many Hacker News praises for PHP. It’s easy to have not encountered it since the bad old days unless you work on a team that uses Laravel for some things.
I do understand hiring someone who has that tradesman programming ethic and is comfortable with Linux, but that’s more requiring certain positive traits.
Yeah, that's fair. Now that you mention it, 90% of these guys where I get that red flag instinct I described are Javascript devs or wannabe Javascript devs. It's as if the JS ecosystem has driven an entire generation of developers insane
I'm in complete agreement there; I've seen a number of those. I like to ask simple questions about what they like about programming to catch some of those issues and look for a certain amount of self-understanding.
I think it's a case that unfortunately many people don't understand how simple a solution can be. They've been fed the typical books and articles and firmly believe that if it's just PHP it just can't be good. Right? I mean going through all this pain and requiring that many developers, means that this solution has to be much better? Right?
On the one end of the scale you've got the PHP Laravel monolith, and on the other you've got the completely serverless bits of JS over lambdas, with 12 different technologies, buckets up the wazoo, to store 300mb worth of data.
Then you're told 'yeah, but this is distributed'! Okay cool, so you save 50ms of latency. Super... How long does your javascript takes to start returning content? Right, much longer. What the hell is even a cold start? How is that a thing in 2023?
PHP is unsexy. And people don't like unsexy. I, on the other hand, I like my vacations uninterrupted.
One does not need PHP for that. Most well known traditional web framework with server side template rendering will do.
But yeah, before you jump through the whole ecosystem of JS and require 3 different third party services, only to make a website, that does not work with JS turned off and cannot be build and run any longer 3 month later, due to dependency fup, you are much better off with unsexy PHP.
PHP has matured and has been a nice language for a decade now. But PHP developers havent. Cargo culting “good practice” and lack of creativity plagues the community. Frameworks have become so heavy that you spend more time configuring them than actually adding value. Oh and some still argue over setters and getters.
My experience is that if I join a team of PHP developers, there is a 40% chance of the team being professionals and writing good maintainable code. With Java, .NET and Python I would say 80%. C and C++ around 90%.
> PHP has matured and has been a nice language for a decade now.
And how did it manage that? Python forced people to deal with encodings properly and the result was a lot of pain. You're claiming PHP somehow invisibly fixed the numerous problems of the language without anybody noticing? That "fractal of bad design" blog post, everything described in it has been fixed?
If so I want to learn how they did it. That's some heavy duty language evolution work.
There are breaking changes from 4->5->7->(less so)8
This is why so many basic php web hosts continue to offer older php versions because the old code will not work and why paid projects like cloudlinux hardened php still exists. Just in the last 2 years they finally ended security support for php4 on the hardened php project.
So to explain how it worked, it wasn’t as sudden as python, but the problem areas have been depreciated and removed as php has evolved.
Encodings are a non issue in PHP and the availability of web tools is much wider in php than for python. PHP matured in the sense that it from a wordpress type of hacky language to an almost decent language. It can be used properly if you know what you are doing (ie can scale really well for the web, can be secure, allows for good oop design, can be fast _for the web_, and has a wide range of supported packages, separation of concerns and so on).
> and the availability of web tools is much wider in php than for python.
If that was a metric for language quality, then Javascript would be undeniably the most perfect language ever designed by any intelligent species in the universe, judging by the number of frameworks.
> to an almost decent language
And now I would like to hear a good reason why I should use an "almost decent language", when I can use a decent one instead.
> It can be used properly if you know what you are doing
It doesn't matter what I do, the language still insists of having multiple modes of error handling, a massive amount of builtins all of which sit in my global namespace, it's configuration is still seperated between compiler flags, a system wide ini, and local config. The base deployment mode is still "dump files into folder and let CGI do the rest".
I am not saying that’s a metric of the language’s quality, nor am i saying that python is worse than php.
What i am saying is that the offering of tools has matured in php - instead of a basic template engine like smarty you now have “advanced” templating engines, packages and so on. Python has less packages but that can also he because python packages work better and there is no need for an overwhelming number of packages.
Regarding error handling that’s precisely one of the many issues with php. There are so many ways of doing the same thing that it becomes exhausting. And what many php devs do is they work around these issues either by endless hair splitting debates or a dubious amount of made up design patterns.
You shouldn't use php, i am totally against it. I think it’s as bad as it can affect your mental health. Just saying that by comparison to it’s previous versions it has come a long way.
However it does handle character encoding quite well and you can scale as much as you want to literally. Probably because thats too complex for the average php developer and it was left to core language developers which are pretty competent and experienced.
That hasn't been my experience at all. Although, I do spend more time interacting with the Laravel community (a subset of the PHP community) than the PHP community itself.
I found the (Laravel) community to be more about object-level discussions ("how to do x feature the best way possible") rather than meta-level discussions.
Whether to use them or not. Petty endless debates over their benefits and drawbacks. Literarily for as long as i worked with php devs in all teams there was someone debating this pattern. As php is not strongly typed these can help with data type validation, can perform some logic when setting values, while others say it’s inefficient as thats an unnecessary method call, or that no logic should be performed in them. Some prefer to use magic functions instead of setters and getters others are against it because it makes the code difficult to maintain, some say they should only be used for data entities, others want to use them for every property, some prefer them because you can rename properties while maintaining external accessors, others against then because of consistency, some argue over what naming convention is best, some want to persist data in some type of storage when making updates, some attach observers to them and so on.
Bottom line is that the language being so flexible, unassuming, and swamped by needless features almost everything can be debated the point of exhaustion.
Python, being more straight to the point and not overkilling oop allows for more focus on doing what matters: business logic.
The issue is that there is so much configuration that it’s basically coding. PHP frameworks are all bloat. It would have been much better to abstract things in a way that you actually spend time on features not thousands of configs.
> Note: In the years since releasing Lumen, PHP has made a variety of wonderful performance improvements. For this reason, along with the availability of Laravel Octane, we no longer recommend that you begin new projects with Lumen. Instead, we recommend always beginning new projects with Laravel.
There's plenty of stacks that I'd say qualify as "simple, cheap, straightforward, and fast" (modern Java, for instance - huge red flag to me if people still turn up their nose at Java), including some that you'd probably consider exotic (honourable mention: Elixir+Phoenix).
I personally never liked PHP, so I haven't kept up with how it has developed and I don't expect to start, to be honest. Of course, if you've got an otherwise interesting project that happens to be PHP and want to pay me to help you with it, I'll be professional about it, but there are too many alternatives that appeal to me more than PHP for anything where I have a say.
> It's actually a bit of a red flag to me these days if a developer turns up their nose at PHP.
Depends on the reasons. One good reason for preferring another language is .NET/Java business app developers can earn a lot more here than PHP developers ;)
Oppositely: not being able to articulate the problems with PHP/Laravel compared to a stack of say Kotlin/Ktor or C#/MVC or Java/SpringBoot is a red flag too in my book.
Have worked at a few places where PHP was dumped on because “it doesn’t have threads”. The dumper-folks were also noted to be for spending most of their time trying to fix threading issues (Java, usually). Saw this in person twice, have heard similarly from other colleagues over the years.
I agree “it doesn’t have threads” is a bullshit reason. Especially since it took JS's threadlessness to make evented (aka async, aka promise-based, aka callback-based, aka eventloop-based) mainstream, and for good reasons! It allows many to maximize the compute resources better than possible with the threaded approach.
There are good reasons to avoid/switch-away-from PHP... Like weak compile time quality guarantees, messy std lib, low quality of available libraries, many security issues; all WHILE great alternatives exist for free! (e.g. Kotlin, Rust, C#, Java)
And don't get me started with all the points where the syntax pretends to consume an expression but it's actually just the parser looking for a very specific pattern that will be read as if it was an expression, but other forms won't be accepted.
Sure, it's perfectly possible to grow numb to those pains and some will even pat themselves on the back, claiming pragmatism over principles, but wow, if you're not used to that level of make-believe in computer languages you'll be paralyzed by disbelief. An endless series of "this can't be true!"
Ditto for any language. I think it is a good sign for someone to recognize the trade-offs a language makes, or even accept that they can complain about it while acknowledging they don’t understand the trade-offs.
But when a dev says X is objectively bad, that is not a good sign. Languages are tools, not a way of life.
What about people who get their stuff done with mature, well established, and high performant Java and C# frameworks? The benefits of static languages is already established, particularly for longer maintained and larger code bases where multiple people work on them.
PHP8. You think it's a red flag when people don't believe that PHP8 finally got their shit together.
What's that George W Bush line, Fool me once, shame on...shame on you. Fool me—you can't get fooled again. But we're not talking about getting fooled just once, or twice, we're talking about eight times.
First off, this comment reveals some ignorance about the language. PHP 6 never existed. Trying to infer anything off version numbers like this is goofy; in a much shorter time period Node is up to v20. Does 20 versus 8 mean anything? No.
No one got “fooled”. The got a useful tool that got better over time.
Anybody who believes that this time PHP isn't awful can expect the same disappointment as the last few times. I'm an old man, I remember all the pain of upgrading to PHP3 and for my sins my current work includes trying to cajole somebody's PHP7.x code into running even though it appears their employer disowned the project we know if we don't make it work the "replacement" will never actually materialise.
This is a language built by people who didn't really know any better, so I don't blame them, but it's ludicrous to pretend that it's a "red flag" to have noticed that this keeps happening and learned from that experience.
To be blunt, you are a terrible hiring manager if your red flag is “they haven’t got an up-to-date opinion about the shitty-history language that I’m personally into”.
This just sounds like PHP Stockholm syndrome with extra steps.
I guess it depends on how it's communicated. If someone tells me he doesn't like PHP because of this and that reason, that's fine. Getting wound up about some specific programming language (feature) or any tech still raises a red flag for me. But then I might be terrible as well :)
