PHP Gets a Bad Rap

In many developer circles, mentioning PHP (or even its cohorts MySQL and Apache) serves as its own punchline. On Reddit, someone asked for an example of a good PHP application, and someone snickered, “No such thing. Use a real language.” It warrants a chuckle for me as well, since I recall spending my early dev career sifting through thousands of lines of someone else’s non-OOP PHP code that was structured like a monolithic if-else statement. But is it fair to cast judgement when PHP has been the cornerstone of over 12 years of WordPress and almost a decade of Magento? I can hardly think of more battle-tested platforms.

Just for some background, my career shifted over 5 years ago from being a senior LAMP developer (which included getting certified as a MySQL DBA) to more of a management and product architecture capacity. That said, I still make it a point to write code in my off time, both for personal projects as well as helping colleagues. Not only is this crucial for me staying up to date in the bleeding-edge digital agency world, I also get a kick out of solving problems my own way, implementing whichever technology stack best fits both the project and the particular mood I’m in. Lately this usually involves installing the Express framework over the official Node.js image from Docker, often reaching for MongoDB and AngularJS to complete the “MEAN” stack, though I’ve been known to dabble in Python as well, especially when Selenium gets involved.

I often do end up helping others through some poorly written PHP, but largely this isn’t PHP’s fault. It’s a classic case of a bad carpenter blaming the tools. Here’s the thing: PHP has been around since the mid-90’s, and its early uses involved injecting small pieces of pre-processed data into otherwise static HTML. Even now, quick-and-dirty scripts have their place — if all I want is basic session data handling on a temporary “Coming Soon” page with an email signup form, this can be done with 1 line of session_start() and placing the data wherever it needs to on the page with an echo. If you’re using Laravel for that, you’re definitely overthinking it.

The problem comes when developers approach large applications like quick-and-dirty scripts. In the common case where a non-technical founder hires a dev team to build specified functionality, they have no visibility into how it is built, only that it does the thing that the user story says. Quick-and-dirty can make the functionality work, but not without incurring a large amount of technical debt. This means that over time, each poorly written piece of code has an increasing impact on site performance as well as the time and effort necessary to develop and QA each feature. Ever see a poorly running site with a hairball codebase that the founder says they’ve paid hundreds of thousands of dollars to build over the past 2+ years which should have taken a couple of months? Technical debt is often the culprit.

PHP gets a bad rap because many PHP developers on the job market today honed their craft in the early days and either forgot or never learned the fundamentals of OOP which predate web applications by several decades. Modern design patterns like MVC are natural extensions of this ideology. However there are also well-built frameworks for PHP like Laravel and CodeIgniter which provide solid architecture. Even older standards like Zend and Yii have undergone a lot of refinement and proper execution would produce proper results.

Node.js, Python, and Ruby, for example, are also not impervious to crappy code. The key difference is that these languages became popular during a time when using a framework for large builds was a given. In the majority of cases, they seem inseparable, like Python-Django, Ruby on Rails, etc. There are many disadvantages to this conformity, but as a baseline where most of the popular textbooks teach from, it means newer developers start with OOP+MVC, and modify as necessary. Deviating from that then becomes similar to knowing when to break grammar conventions for proper effect after you’ve learned how to fluently speak a language. Similarly, if best practices shift dramatically in the near future, you will then start to find a large populous of Node.js developers who still do things “the old way.”

So really it’s not that PHP is a bad coding language, they all have advantages and disadvantages, and I’d definitely hire a good senior PHP developer over a junior Ruby developer. From my observation, the problem is that there are many PHP developers who continue to get professional work, toting their years of experience, despite having subpar execution. So hopefully, with the right amount of tech oversight, companies can start catching this sort of thing earlier on before spending time and money on 90's-style code.