PHP has garnered a bad reputation in the software market. Many developers hold strong opinions against the language and to some extent, that's correct. Over the last few years, although PHP has gone through an evolution and is it the same "Fractal of Bad Design"?
This post was originally made to my blog: Twodee's Kitchen. I would love for you to visit that and show some love.
Yes, I admit it. PHP sucks.
And I shamelessly write PHP code, so I must suck too, right?
As popularly stated in the famous article PHP: a fractal of bad design :
PHP is an embarrassment, a blight upon my craft. It’s so broken, but so lauded by every empowered amateur who’s yet to learn anything else, as to be maddening. It has paltry few redeeming qualities and I would prefer to forget it exists at all.
The article has only gotten popular over the years, and it's still being circulated over Quora (One of them being the founder himself, Adam D'Angelo).
And while the article came out, yes, it was right. It was badly designed and badly implemented. The users made it worse. While PHP came along, it didn't originally plan to be as massively used as it is today. Since it was so easy to adapt to, people started using it everywhere. It worked to some extent.
As soon as the web got more popular, we changed, our needs changed. PHP didn't. It was still stuck behind, probably due to the community? It was inconsistent with its naming, it had the insecure mysql_* functions built into its design. There were a lot of gotchas in the language, and having used PHP for a long time, I know that it is a pain.
But this is 2019. The article was written in 2012. I am surprised people still keep quoting that article everywhere!
C'mon people, PHP has changed (evolved) a lot, don't tell me the public eye is too blind to see it.
PHP has had some major pushes like the HipHop to HHVM movement from Facebook and PHP 7. Developers have recognized the issues that came along with it, and they have been addressing it so far. If you are living in 2019 and still writing mysql_* functions (or blaming PHP for having that), you seriously need to learn to RTFM.
So why this hatred still?
Well, as long as something's popular - people will hate it. People hate Java, people hate C++. When millions use your product, you cannot expect everyone to be happy customers with every design decisions that you make. There will be people who don't like your approach and that's true for any remotely popular language.
People often compare Python to PHP in the web context. I have nothing against Python, I think it's a great language that fits the purposes it was intended for (scripting?) and purposes it was adapted popularly for (AI/ML/Data Science?).
But here's where Python fails to impress me against PHP:
It's slow. Not a deal-breaker (especially on the web), but I am making arguments for the sake of making arguments. If you still complain about PHP being ugly, I can complain it about being slow.
It needs a framework for anything web. Initially, when I just wanted to get a Python application up and running for the web, I had the community continuously push me over to use Django or Flask. I hate being coupled to a framework, as many others would (and should) be too.
Whitespacing? Not a fan. Again, it's not a deal-breaker, but having whitespace mean something doesn't make sense to me. I understand that it was a design decision to keep the lines cleaner, but when things break because I missed an invisible whitespace - it hurts my feelings.
Its Object-oriented model is alien to me. Access specifiers are done by enforcing conventions with underscores? Okay. No. Maybe it works for some folks, but I like things being implied explicitly rather than implicitly.
But okay, Python is a great language. It works great, it's got a great community and yet - there are people who hate it. And that's okay if you are remotely popular anywhere - you will have people not liking you.
Javascript on the other hand - It's something I really don't like. It's a matter of personal opinion. Especially after the fact that some Javascript dudes who are a few years older than me were trying to shove Node.js down my throat and bashing PHP for the time I was in front of them. Asserting that Node is far superior, safe and faster than PHP (and anything else for the web) and I should learn Node right away.
They went as far as saying that PHP invented SQL injection. I stopped trying to speak at that point.
Coming back to PHP:
Do you still have/write legacy PHP code that follows the arcane PHP 5 approach?
I have a list for you:
Start writing OOP
While you can still write procedural PHP, the community has moved towards an object-oriented approach. It simply fits the new model and works great to have you structure the code well. With object-oriented, several clean coding practices like SOLID and DRY are automatically implied.
OOP silently enforces clean structuring of your codebase and keep things separated better. Of course, it's optional, if you like writing spaghetti code, no one's stopping you. You can make the worst out of PHP and give yourself a bad name. But that's entirely up to you, any language will allow you to do that. Not just PHP.
Strict type as much as you can
While we are at the subject, also use Strict Types. It's as simple as: <?php declare(strict_types=1) at the beginning. Static typing surely helps you keep things consistent and safe. Yes, PHP is a dynamically typed language, and we need to squeeze that feature out of PHP sometimes. But in most cases, going by the safer path with strict types can save you from a lot of weirdness and unpredictability at runtime.
Namespaces, please
The include statements on top of the page are no more common and the community recommends that you use namespaces to "import" modules you need to "use". Its a means of abstraction over your raw PHP files that allows you to encapsulate the include logic.
Yes, it could be weird to use \ as the namespace separator at first, but you'll get used to it. Get rid of those includes and start using namespaces to put things into their correct places. Which brings me to my next point:
Composer
If you are planning to start a PHP project, get composer immediately. It's a dependency management tool which allows you to define your dependencies, your application and test entry points and load dependencies from the central Packagist repository as you need them. It generates an autoloader for you, and that's the only thing you should include in your entire project.
Throw away mysql_*
All the mysql_* functions have been deprecated for a long, long time and it has been removed in PHP 7 for good. So if you are still complaining about mysql_* functions being bad, please upgrade your PHP version. The best way to deal with a database as of now is to use PDO with prepared statements. It's a generic API that works quite well with a vast array of databases.
The things that I like about PDO are: it's clean, relatively modern design, object-oriented and consistent. You will move to exclusively use PDO in no time once you start a project with PDO.
Again, don't create DB wrappers like DBConnection extends PDO. Just don't. If you need some sort of abstraction over PDO, check out the Data Mapper pattern and some ORM like Doctrine (and not some evil Active Record variant).
Separate your concerns
Most of the bashing PHP gets today is because new developers mess it up so bad, that it smells worse than Javascript (I am opinionated, sorry). Because its easy to learn and get started with, newbies just can't resist themselves from writing hacky code and deploying it to production.
Other languages don't get this because
a) they have a steeper learning curve
b) they give out a strict design strategy beforehand.
c) It takes time to get them up and running.
Fix this by separating your concerns. I remember once I used to copy-paste portions of long functions to other files to do the same thing, but slightly differently. I understand why beginners do that.
Start off by making your functions smaller.
Break your codebase down to small pieces acting independently doing exactly one thing. Read more on SOLID and DRY principles.
If you have a User class, don't allow it to be able to create a message, encrypt the message and also send the message to another user.
Incorporate libraries from the internet, people solved your problems with better testing well before you did. And they did it better. Whilst we may be tempted to have everything custom made, we tend to deviate from the actual business needs. Focus on your business logic, use what's already available.
But no tight coupling.
PSRs to the rescue
And finally, follow coding conventions and read on PHP-FIG. The PHP Standards Recommendations (PSRs) will allow you to have a consistent codebase that others can easily understand and extend. The standards will help you to write code that can be compatible with other code written by others, and that will save you from cursing yourself 3 months after you write some bad PHP code.
This recommendation applies to every language in general. Follow coding conventions and strive to write better code. Of course, no one can stop you from being a "code-rebel". We don't have the technology to stop you from that yet.
(Yes we do, coding standards checks during integrations can keep idiots at bay)
A few concluding words
Yes, PHP sucks. So does every other language. You just gotta deal with it.
It's up to you and your team to write code that looks like poetry rather than an ugly war cry. You can write severely bad Java code even with its verbosity and static typing.
You were scared about starting your next project with PHP because your coworkers will judge? Go right ahead and do that. It's your job and it's your tool.
Your coworkers are probably too free, maybe their code is still compiling.
Latest comments (41)
PHP is fine. Everyone should use composer and PHP-FIG.
Then why aren't composer and PHP-FIG part of PHP?
PHP is fine.
Thanks for sharing the links that you did. I got to read the amazing "PHP: a fractal of bad design" and saw the people who build PHP itself. I am a MERN stack developer and I started to explore PHP and WordPress theme development.
Ooh boy, the ecosystem, design principle in PHP and WordPress are just so bad! They are extremely bad. I'm not saying this because I have anything against PHP, I willingly came to learn it with an open mind and I will keep studying it.
But as a PHP developer now, I must say, PHP is a badly designed language and things like WordPress complement bad design further.
That every language has problems does not mean that the problems in languages are equivalent to each other or have the same number or severity of them.
Most problems in sane languages are either something small that was overlooked or is a consequence of having to make tradeoffs. The vast majority of PHP's problems are from pure ignorance and lack of any design. It doesn't even rise to the level of poor design because that implies that there is a design to it.
removed
PHP language and community is a mirror that JS look into in order to avoid the same fate of being a joke.
If you complain about using a framework with Python and then happily write you use composer and that Doctrine is good then no one should take you seriously.
"Your coworkers are probably too free, maybe their code is still compiling."
You realize most Go applications are small and compile within 3 seconds, right?
Your arguments are just invalid. Active record is not evil. The thing that is evil here is Doctrine with the insane amount of abstraction which makes doing things efficiently impossible.
Doctrine is a great example of what is wrong with PHP and the people who invented it didn't help the cause. It makes it slow down to a halt with inefficient queries and cluttered classes.
still in the process moving my code from php to nodejs..., I am lazy and prefer to do everything in 1 language
Something funny I think we all forget is that there is a book out there famously titled "Javascript: The Good Parts". Where we all poo poo'd on javascript for being a bad language because we all implemented bad patterns and didn't fully understand prototypical inheritance. Back then we were throwing the term Javascript Sucks.
I do hope that we remove this idea that "PHP Sucks" because it really doesn't.
What you are forgetting, or simply do not realize is that the point of the book was to point people away from the bad parts, which never have to be used. There is a powerful and sane subset of JS.
No such subset in PHP. The poorly thought-out and mind-melting idiocy weaves throughout the language. It is impossible to write "PHP: The Good Parts" and still have a complete and useful language.
That PHP end users don't understand this, or understand CS concepts in general, is an indictment on the entire PHP ecosystem.
It is not just your comment, every pro-PHP comment lacks any technical sophistication or understanding. That is PHP in a nutshell.
PHP: for amateurs, by amateurs.
I generally agree with the summary even though the points are not entirely consistent and it severely misses the big picture of "sucking".
Even though the strictly technical criticism of the cited article no longer applies to newer PHP, PHP as a language and ecosystem sucks a lot largely due to its maintainers but also the community.
PHP 5 had several problems that are at the root of that:
You offer some advice for PHP5 users and you also mention using strict types. Do you know that strict types are a PHP7 thing, right? You're basically telling people to upgrade, which comes with a learning curve, particularly for OOP practices. It's a costly upgrade and factor in that of all PHP applications in the wild almost 60% use version 5, people's opinion of PHP will stick to version 5. No wonder people still refer to that article!!
Also .... you tell people to follow PHP-FIG. Do you mean all standards? (that would be nice) or you just mean coding standards (aka PSR-2 - which incidentally was deprecated, but people still follow it and quote it out of inertia). I'm asking because one of the most famous frameworks (Symfony) isn't compatible with the most needed standards: PSR7 and PSR15. It's mind-blowing that incredibly useful components like HttpFoundation (I love working with their requests and responses) don't provide builders for PSR7 and PSR15. Yeah, they provide a bridge as a separate package which only adds to boilerplate.
Speaking of composer, I wouldn't be so eager to jump into packages. My usual tooling for APIs involves PHPDI's container, theleague's router and stuff like Monolog and Doctrine but that's about it. A recent nightmare involved mailgun and some sms sending API that each had the same dependency locked at different versions. It's a matter of time before running into version conflicts that, in the happy occasion when there's a resolution, ends up with using the lower common acceptable version (which, given the way most libraries go for compatibility, means code from PHP5 era - a great example for the developers that end up using it). In the case of node, for example, older packages aren't that problematic since even what's considered older at the moment (think node 6) isn't as old as vanilla PHP5.
And last, my personal gripe with the PHP ecosystem is that in many cases the tendency is to copy Java. Java-fication is most obvious on frameworks like the defunct Silex or Symfony. Fortunately now there are some nice alternatives (Symlex, Ubiquity) that are embracing PHP7 for what it is, instead of trying to copy another language. Add to that application engines like Roadrunner that bring true performance and nowadays we have something workable.
But there's also the tendency to get stuck in OOP world (I get it, PHP has be so slow to evolve that I've seen developers jump at OOP as if they suddenly discovered sliced bread - most OOP 'benefits' are a myth and while it did help promote great practices like SOLID, they aren't tied to OOP and apply regardless of core paradigm). Other languages offer functional programming alternatives or strong code support for it, PHP only got Swoft framework fairly recently and it's quite in its infancy.
I think you started with a great post but deviated in the middle of it.
If you step back for a second you can see the irony in the post.
You're asking people that hold strong opinions against PHP to open their minds a little and see the evolution of the language. The key component here is "strong opinion". It is the core of all these discussions.
Your article is packed with strong opinions such as "you shouldn't use a web framework", "you should use strict typing", and "active record is evil".
At the expense of trying to convince strong opinionated people that PHP dont suck you end up spreading your strong opinion against one of the largest PHP community: Laravel. A web framework without static typing build with Active Record in mind.
It makes your article read as: "Hey people, you have some pretty bad strong opinion about PHP. Here are some up to date strong opinions you should hold so that we can collectively hate on other communities instead".
My reply may seem like I have some strong strong opinions of my own and to a certain extent that is true, but what I've been learning is that it's best to keep ripping strong opinions apart and being accepting of the diversity. As an example, you could have said that with PHP you're not forced into a web framework if you dont like to be bound to one, but for those that do like it we have some great ones like Symfony, Laravel and Slim.
TL;DR: Try not to advertise against strong opinions with more strong opinions.
I understand what you mean by that. And yes, I do hold strong opinions on my own. But the fact is, I'm not forcing any of those ideas to anyone.
Strict typing is optional, as I mentioned in the post, in a dynamically typed language of course you'd like to use the dynamic typing. What I wanted to convey is: use dynamic typing when you need to, otherwise stay on the safer side with predictability.
Also, I am not targeting any particular framework. Laravel has its problems and so does every other framework. Choose what you need to, when you need to. I personally like taking pieces off Symfony and wiring them up together. I never said, "never use a web framework". I recommended to not get tightly coupled to one framework.
About Active Record: yes, I do believe it's an Anti-pattern. And I would advise anyone against it.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.