DEV Community

loading...
Cover image for Why bashing PHP makes you look stupid

Why bashing PHP makes you look stupid

neoan
Passionate generalist conquering the web one project at a time. Whether authoring libraries for node, JS, PHP, or Rust, I am always on the lookout for better solutions to common problems.
・4 min read

It seems to be common knowledge that PHP is a terrible language and that it's not enough to simply avoid it, but to signal your position with memes to make sure you are "a full member of the web dev world". But what is behind this weird behavior?

The history

When PHP gained popularity in the late 90s, it wasn't perceived as a full programming language. Back then, the acronym stood for "Personal HomePage" Tools and was more like a capable template engine than anything else. Additionally, the concept of a "web language" was more or less unknown: something that only does this new internet thingy? How can we take that seriously? With this background, the first wave of "PHP hate" came from programmers that saw PHP as a cute yet inconsistent tool for hobbyists. And arguments pointing out structural weaknesses were usually founded and mostly based on comparison to compiled languages. End of story? Not so fast!

Wave 2

Further development and the rise of Content Management Systems like TYPO3, WordPress, Yoomla & Co in combination with efforts by Zend & Symphony while the internet exceeded all expectations have transformed PHP into a widely used stable companion without competition (Well, ignoring Perl, that is). Wikipedia and Facebook are just examples of the big players of this era using it in a completely different way than the original intention. However, there were still missing features, security concerns and a standard library that "classical programmers" disliked for consistency reasons. At that time it was clear, however, that another wild-card has grown from enhancing the UI with little gimmicks to something that wants to be taken seriously: JavaScript. And for reasons I will not expand in in this post, JavaScript was seen as the worst nightmare of them all with a problem that in theory exists to this day: every browser treats your code differently. It was worse than that. Whatever inconsistency or unusual behavior PHP might have had, JavaScript doubled down on it and made sure that books can be filled with quirks and their explanations to this day.
In this scenario and with PHP codebases like Wordpress and Magento ruling the web with disregard to non-existent best practices, the web was a playground for explorers and adventurers. So why not Java? Why didn't a language that honored features that modern PHP or Typescript made possible over a decade later from the get-go rule the web? Well, it's speculation, but I believe it's a mixture of the web first being a hobby culture in combination with the hope that more predictable and capable technologies than HTML, CSS and JavaScript would run on browsers. But that never happened. See, the only reason we don't say things like "CSS is the worst styling option" is due to lack of alternatives. On the backend, however, that wasn't the case. Java, C# & Co offered viable alternatives to PHP and - with the rise of web frameworks - user friendly alternatives. This led to PHP having to evolve in order to compete with these "serious" languages, while jQuery was "enough" to keep the front-end interactive.

The 5.6 stalemate

PHP rapidly evolved until version 5.6. At that point, further development had to be leveled against a huge problem: backward compatibility. With the fast majority of the web running on LAMP (Linux, Apache, MySQL, PHP), one couldn't risk to potentially "break the web". As a result, PHP6 never came to be, leading companies like Facebook to create their own spinoff and others to go a completely different route. So in wave 2, we still have criticism of PHP that is mostly based on real arguments by programmers who either wrote low-level code or used structurally superior alternatives. However, we are now in the middle of the 2010s, a new kind of critics came from an unexpected direction: JavaScript developers. With NodeJS on the rise, a new generation of JavaScript only developers started to bash PHP in order to present an approach that had no technical advantage, but would simplify and revolutionize the web in combination with somewhat predictable and stable front-end solutions like AngularJS. Additionally, NoSQL databases made data persistency for the ones "overwhelmed" with relational solutions reachable.

Wave 3 / status quo

So were are we now? PHP8 has grown into the fastest interpreted language with all features one could desire without transpiling or compiling and without the dependency-hell and installation time of i.e. node. However, every week we find a new "PHP go home" meme on our wall and beginners are actively discouraged of giving it even a glance. These beginners have grown into mid-level, sometime senior developers without ever having given PHP a look yet tweeting about the superiority of "their" solution as if it was grounded on anything else but the generation before them preventing them from making up their own mind.

Why should you care?

In a time were serverless devs consider themselves as full-stack and bootcamps selling the idea of being a reputable developer after 14 weeks, we live in a world where express developers are under the illusion that they are using a superior technology and therefore have the "right" to look down on PHP. And not only is that far from the truth, but it also makes them look really stupid or at least uneducated. Whenever I encounter a candidate or student laughing at or bashing at PHP, I always ask if they can explain their distaste. And the answers are always embarrassing and only show their limited understanding of technology in general.

Discussion (26)

Collapse
andreidascalu profile image
Andrei Dascalu
  1. There's a difference between bashing and criticism. Since no language is perfect there's plenty of legitimate criticism to go around. If you enjoy working with the language and the criticism against it doesn't impact your work, then what's the problem?
  2. WP and PHP pre-5.6 earned PHP a bad rep, which may be less deserving now but it's sad to see that language-wise even PHP 8 still carries a lot of the pre-5.6 baggage around.
  3. I've been a PHP developer for 20 years, but it took facing the criticism head-on to see the points in some arguments and learning a couple other languages up to the same level to appreciate the developer experience.
Collapse
sroehrl profile image
neoan Author
  1. Nothing wrong with criticism at all. Well grounded criticism is the only path to improvement

  2. Details please, otherwise deep familiarity is required in order to evaluate your point.

  3. Sure, maybe a different topic, but always a good reminder: never close your mind from other impulses and/or new possibilities

Collapse
andreidascalu profile image
Andrei Dascalu

Well, on 3 ... where do we start ...

  • shared global mutable state: the session, a superglobal with no controls around it. Once. you start using it, it's debugging hell
  • the inconsistencies around "utility" functions (particularly arrays and strings). Sometimes the subject is first, other times last, sometimes it's passed by reference, other times it returns the changed item
  • still allowing require/include with code execution. Assuming the existence of parent-level variables is a sure-fire way to fool any static code analysis tools and an easy way to introduce bugs.
  • PSR standards are great but there's still no platform-level way to enforce routing, for example. Routing is still a mix of PHP and external pathfinding (from web server) which means that not only you're still allowed to hit random scripts that may be lying around but the only thing standing in the way of security is your ability to master not just the language but at least one web server. Which in turn hampers usability of PHP in cloud.
  • speaking of cloud, aside from inefficiencies of an interpretend language, when using PHP in a container orchestrated environment, you will still need an extra proxy in front (eg: in k8s a request usually goes through an external LB through an ingress controller, through nginx and then through FPM - that's an extra networking node not needed for other platform). => fortunately there are modern platforms like Roadrunner that are able to efficiently replace FPM.

Basically what I would expect from PHP 8 to fully stand its ground are:

  • no more includes, bake in autoload and that's it.
  • default to PSR7 and 15 at platform level, no more haphazard entry scripts
  • cut down utility functions. In PHP8 with JIT there's little difference between baked in array walkers and writing your own.
  • type inference when strict types are on
  • either wrap session in some collection (see how Symfony does it) or structured object or just be done with it.
  • have a multithreaded webserver already within the platform. Srsly, maybe just replace FPM with RR officially.

On a more general level, if you spend enough time with PHP and then look at things like Elixir or Go, it's natural to start question if there's a purpose to having so much tooling and conventions (standards) that on a higher level are all meant to make up for the shortcomings of the language and platform. Sure, PHP is not the worst offender in this regard (thinking Node/JS - but Node, aside from having its own lightweight runtime that doesn't need external tooling also has ReScript that helps with language issues).

Thread Thread
sroehrl profile image
neoan Author

Hm, so let's start with the obvious one:
Inconsistency of the standard library especially in utilities

Yes. Although I have seen arguments on how the libraries in itself are consistent, that doesn't help for userland.

Before going into the rest of your points, I want to clarify why I consider some of them as opinion: The opt-in approach to many features like typing, PSR etc while maintaining comparability to features like include have pros and cons. I can see how a team can say that there is too much room for bad practices and too much knowledge of side effects is required. On the other hand, I also understand the power of being able to grow within a language and disregarding these arguments with "of course you can use a knife as a weapon, but that doesn't make a knife a bad thing". As such, much of the following is my opinion.

Superglobals

With a huge amount of approaches available to create statefull apps, the more interesting question is why e.g. SESSION remains the standard implementation. You mentioned approaches yourself, so we don't have to go into it, but it's a nice example of many "we will stay compatible to X" that has defined discussions of PHP externals (and I of course internally) for years. The reason this is such a heated topic is in itself proof of different opinions even with very familiar and experienced devs. So yeah, if you can't live with these decisions, I guess you are not alone.

Routing

That's an interesting viewpoint and a new one to me. Ironically, one of the reasons I would opt for using PHP is when exactly that behavior is beneficial. Just like with asynchronous behavior and all the other features that nowadays are possible with PHP, I am not a fan of tweaking basic principles. So some of the points you make - and I may interpret that wrong, so please correct me - aim at a one-for-all solution, while other options (languages) might be a natural fit.

Thread Thread
andreidascalu profile image
Andrei Dascalu

"On the other hand, I also understand the power of being able to grow within a language and disregarding these arguments with "of course you can use a knife as a weapon, but that doesn't make a knife a bad thing"." - definitely, though the issues come when working with others.

If I would have to categorise the issues I have with PHP, aside from language issues, those would be:

  • cognitive load: language quirks + the need to know other infrastructure-related things (like Nginx/Apache) - plenty of gotchas to go around (though JS is a worse offender and you can see that just by how many "truthy/falsy values in JS" and "'this' in JS" articles appear every day when someone discovers how nonsensically it behaves that it bears another explanation)
  • legacy load: on a language level there will be a push to maintain compatibility but major versions are an opportunity to get rid of garbage and PHP 8 somewhat missed that. Seems that in PHP it aimed at deprecating behaviours, which is ok but here's the thing ....

There are load of people trained under old PHP versions (I myself started with PHP 4, although one of my favourite PHP WTF's happened in PHP5 where you had a DateTimeInterface which you couldn't implement yourself). These people will hang on to doing things their own way. The platform still allows that! It takes a lot to reframe people's minds and doing that when you happen to have someone used to PHP 5.6 on your PHP8 project is overload. I really think PHP evolution should do more to cleanup garbage and push for evolution, otherwise PHP 5 practices just get carried over and help preserve that bad reputation of the language.

Thread Thread
sroehrl profile image
neoan Author

Yes, I think I got your view the first time around. I understand these concerns and know that many devs feel that "disabling the possibility for bad behavior" is the solution. And it's not that I necessarily disagree. As you said, especially when collaborating a more opinionated structure can avoid a lot. All I am saying is that the reason why this is not what happened in PHP8 is due to the fact that arguments from the "other side" prevailed. I think in a few years we'll be able to compare this better as e.g. Rust promised to never have a version 2 (so no breaking changes ever). After all, it seems to me that the internals team settled for "deprecation over time" concerning some of your points.
I remember a discussion regarding laravel a few years back where security concerns based on the misusage of model methods were addressed. I found myself thinking that a dev should be expected to know what usage of certain features implies, while the vast majority took a similar position as you and argued that the framework itself should make it impossible to produce this vulnerability. The problem I see with this notion is that I wouldn't know where to stop: after all, if you know what you are doing, then opinionated structure is just a limitation to innovation as you automatically set certain things in stone. And the necessity in many cases isn't there. It not that tooling like e.g. precommit hooks can't address many team based opinions.

Thread Thread
andreidascalu profile image
Andrei Dascalu

"if you know what you are doing..." - well, it's a valid point, but I don't think there's an algorithm for it. It's valid to say it's a potential slippery slope but let's also consider that nobody's under any obligation here to set any hard thresholds. To me it's an issue when there's a sizable number of developers that build vulnerabilities using formerly valid practices. At some point it becomes hard to build enough conventions and practices (and hope that people will follow them under pressure) and it's easy to say "hey, that other platform/language is better because it prevents the things that make life hell for us". This is a lot of what cognitive load is about: I'm using language practices that are/were valid but they cause issues under a certain framework. I'd argue that either the platform OR the framework should prevent that. The number of things like this to keep in mind (in addition to all the gotchas and quirks) is much higher in PHP (for most of the very same things in JS, the TS platform actively fixes and deprecates stuff). Sure, as a PHP developer you should always know these (+ whatever framework you happen to use) but I'd argue that the platform and/or the framework should not be afraid to reduce the cognitive load.
"opinionated structure is just a limitation to innovation" - I've heard this before, and I know many people find joy in tooling as much as in the platform itself but IMHO innovation doesn't come from building often redundant tooling (sure, one static code tool is ok, but 10 is already too much) but from getting to code solutions.

Collapse
ravavyr profile image
Ravavyr

Love the article. Frankly for all developers, regardless of language-allegiance:

You don't know, what you don't know. Learn this lesson and accept that no matter how much you've learned, someone else will always come by knowing something you don't. This is the nature of web development.

I see many newbies talk crap about PHP because they don't know how to use it.
I see "classical programmers" talk crap about PHP, but they can't build websites any better than the average PHP dev without a mountain of dependencies and compiling. God forbid they try frontend html/css.
I mean, sure, you can "write" html and css easy, anyone can. But you can't make it crossbrowser, responsive, seo-friendly, accessible and perform well without some serious experience doing it. The same goes for using PHP for websites.

A lot of people list WordPress as to why they hate PHP, and most often it's because they've had one or two experiences with badly written themes. Let's blame the most popular CMS in use by 1/3 of the internet because it gets constantly attacked by hackers while keeping the bar to entry so low that a dev with zero experience and use it in one day.
Note that a great many themes were created by designers, not developers, or outsourced to the cheapest bidder, the end result, a marketplace full of crap, this isn't the fault of PHP.
Again, you don't know what you don't know.

As for the security flaws in PHP....yea, there are some. Does anyone using PHP daily care? No. Do experienced devs know how to secure their code? Sometimes.
I have sites I built 15 years ago that still run perfectly fine. Some have been hacked over the years, and we patch em, rebuild 'em or just spin em back up from a backup. That's part of web development, we are literally under attack 24/7.
Anyone who hasn't experienced that can just drop the subject because you don't know what you don't know.

As with any language, the language is never the problem, it's the developer's skill level that determines if what they produce is crap or not.

Collapse
ychanov profile image
Yavor Chanov

Well said, all of this about the security, experience, and the "what you don't know, you don't know" phrase :)

Collapse
sroehrl profile image
neoan Author

Oh, and in anticipation of some backlash: please state your

  • experience with different languages
  • years of experience with these languages

in your feedback. It helps me and others to filter through potential "fan-boy" responses and get to real arguments. Thank you!

Collapse
danjfletcher profile image
Dan Fletcher

There's a lot of misunderstanding around what PHP even is and what it's capable of. I agree that bashing it is uncalled for. I write a lot of PHP and have built a ton of applications with it that did and are still doing very well.

People should at least be informed before hating on it.

But that doesn't mean it doesn't have shortcomings.

For some people, the fact that PHP isn't a threaded language and likely never will be is a big deal breaker.

The way PHP applications spawn new processes with each request life cycle gives it a pretty significant hit against requests/second when benchmarked with other languages.

The fact that the same line of code can do more than one thing depending on the php.ini settings is pretty crazy to people coming from other languages. It's annoying at best. It's catastrophic at worst.

Or the fact that shallow comparison is rendered useless due to it's arcane inconsistencies and completely unpredictable behaviour. So why even have it?

It's type system is incomplete. Good luck auto-generating Swagger docs ever (and I don't mean hand writing annotations i.e docblocks).

Also, more of an ecosystem issue than a language issue but the fact that Type-Hints will coerce primitive arguments unless a script is in "strict mode" really sucks (in my opinion). For people coming from strongly typed languages especially, this is vomit inducing. But AFIK even loosely typed languages that support type annotations won't coerce types on you if you use annotations. Tooling could automate setting strict mode either through linting or a transpilation step but things like Hack never really went anywhere and most PHP devs don't bother with "strict".

Also, the most popular PHP framework is basically impossible to run in "strict mode" anyway so if you want true static analysis and type checking you have to use less popular choices (not the end of the world but still).

Until very recently error handling has been a mess. The fact that not all errors can be caught in a try..catch is asinine. I guess this is finally fixed in version 8 though? But how many people are even using 8 yet?

Language extensions are interesting but overall a PITA to work with and really just makes PHP impossible to use without VM's or Containers.

The core is complicated and maintained by volunteers with no backing from any major company. This could seem as a plus too but overall it means PHP is in kind of a tough spot. It's extremely difficult to contribute to, and few people really understand it. AFIK there's been a scent of burn out from some of the core contributors which is totally understandable but a little scary.

Another issue I see, although nit picky, is that for a new comer who is already an experienced programmer in another language it's probably pretty confusing. PHP doesn't look very "OOP" without 3rd party tooling. Autoloading is essentially like "linking" I guess? Only it's not handled by the language itself? Kinda weird. Plus installing and configuring PHP is quite the hurdle compared to other languages.

Collapse
danjfletcher profile image
Dan Fletcher

That said, I still have a distaste for the discouraging of new developers from learning PHP. That kinda seems like the trend for educational content now days. There's this weird lie (or denial?) that gets thrown around to aspiring devs that "PHP is a dead language".

Collapse
sharpninja profile image
The Sharp Ninja

I have been professionally developing web sites and web apps since 1994. I have extensive experience with Java, C#, VB, ASP, ASP.net, ASP.net Core, Blazor, Angular and Vue. I have also maintained many WordPress sites for people. For sheer quantity of crap code I have seen, the worst of it has come from PHP devs. And not the devs using PHP, but PHP itself. When you can expose a remote execution bug by using a specific name for a CONSTANT, that speaks volumes for the horrid mess that PHP is.

Collapse
sroehrl profile image
neoan Author

For sheer quantity of crap code I have seen, the worst of it has come from PHP devs

That is my experience as well, and flaws based on "why does PHP allow such a mess" is a complete topic in itself. But here I am focusing on "opinion" that isn't based on any real-life experience but sheer "trend"

Collapse
rmurray0809 profile image
Rmurray0809

I think really the problem with PHP is that it is so easy to get started with the basics that people who have no programming experience or training can jump in and start making something. PHP is really good at what it does and in the hands of someone who knows what they are doing can be hugely successful. On the flip side it allows people with no concept of security, maintainability, usability etc etc can create all kinds of crap.

So essentially its ease of use has created an atmosphere where professionals have to go in and clean up after people who shouldn't have been writing a program in the first place. This leads to the design of PHP being directly correlated to its perceptions by developers.

Thread Thread
sroehrl profile image
neoan Author

Yes, I think that is certainly a factor

Collapse
hasnaindev profile image
Muhammad Hasnain

Thanks for writing this article. I'm a MERN stack and PHP developer. In general, anyone who criticize a language like this isn't a mature developer. React/Node aren't the ultimate answer. Choose the right tool for the right task.

Collapse
sroehrl profile image
neoan Author

I 100% agree

Collapse
raigaurav profile image
Gaurav Rai • Edited

People has bashed Perl also a lot. I started Perl in 2012 and with all these years passed I am still not able to understand why people hate it so much. Yes constructive criticism are welcomed by everyone. But to form an opinion about something you have to use that thing for some time. Perl has evolved over time and Modern::Perl(> v5.10) is quite better.

A bad programmer can write bad code in any language.
P.S. Before Perl I used PHP also till 2011. :P

Collapse
ivanjeremic profile image
Ivan Jeremic • Edited

I still consider php a template framework and I mean this positive, looking at php you see a lot of similarities with React which I love.

Collapse
abhinav1217 profile image
Abhinav Kulshreshtha • Edited

Actually in past few years, It is almost as good a programming language as Java or c#. It was a template language in php 5 days, but now it actually feels like a proper programming language.

I contracted for a company last year which had a barebone custom framework actively maintained ( they upgraded 7.3 to 7.4 while we were working. ). Their CTO was experienced Java Architect, so our coding style, Module organization, OOP implementation etc were all inspired by Java. It was surprising even for me. He taught us all a lot about structuring code.

This year, I am working with PHP 8.0 API, Kotlin and VueJS. So far I am loving the stack. It is much better than my spring-mvc days.

Collapse
sroehrl profile image
neoan Author

Uff, I don't know. One one hand, I see what you mean by similarities to React, on the other hand, clean PHP usually leverages an MVC which React implementations usually don't use. Lastly, given the fact that modern PHP is often a pure API, I cannot agree with the template statement at all.

Collapse
ivanjeremic profile image
Ivan Jeremic • Edited

Well even the creator agrees with the template statement, because it was created as template engine and not a programming language, of course this changed now but you still see the templating features React took as inspiration.

Thread Thread
sroehrl profile image
neoan Author

Yes, I guess phrased like that I come to the same conclusion

Collapse
iamvpbhaskar profile image
Ved Prakash Bhaskar • Edited

As we know PHP is a programming language designed specifically for web development. It always had major designing flaws and for many years there were also
performance issues. However after that PHP became popular in late 90s despite its flaws and even was a standard for web development for many years,
Because its competitors of that era (Java, C/C++, Perl) were less suitable for web development.

Nowadays (25 years later) server-side web development technological landscape is extremely competitive and now we have few strong languages or platforms,
that are as good or even better than PHP for web development, while lacking its major flaws. PHP became stupid to catch. That is why PHP is going down by modern web developers.

Collapse
sroehrl profile image
neoan Author

I don't share this assessment. First, I don't think that Perl or Java were less suitable for the web. The developers using these languages simply didn't "adopt" web early on. Secondly, while there are many solutions addressing structural issues of PHP (for example GO), these aren't the popular alternatives. Instead, node "rules" the backends when it comes to sheer numbers, and that certainly doesn't produce an advantageous outcome. Lastly, especially with the rise of Laravel, PHP isn't "going down" either. It's still the most used language despite all the diversity we have today.