The premise of PHP was taking a C language based workflow for web applications, keep the general idea of C intact, but simplify it down to the absolute minimum lines of code & thought needed to write web applications.
A Web form in C - Before PHP
Equivalent web form in PHP 1.0
Rasmus Lerdorf, the inventor of PHP, had this to say about web programming back in '93:
“That was getting pretty tedious, I’m not that interested in programming, it’s kind of tedious and boring, so if I could reduce the amount of time I had to spend programming and maximize the output and get to the solution quicker – that was my goal with PHP”
Looking at the code example above, we think he did a killer job. That's approximately 1/4th of the code to perform the same work.
The language has grown since, adding object oriented programming, and features from more advanced languages such as C++ and Java. Despite this advanced functionality, a beginner can still use it in the simple procedural way, and then later move on to advanced object oriented programming.
Today, PHP is still the only language built specifically for web backends. For this reason, it's still an easier fit for web backends than languages that were designed for another area of programming and repurposed to build web backends: Python, Ruby, Javascript, Go, etc.
Since then, many people have attempted to improve upon PHP, but this has turned to be really difficult!
Here's why we think PHP is still king:
It could have something to do with PHP's "skeleton in the closet".
register_globals and magic_quotes were dangerous features in PHP during it's first 22 years. These features increased the convenience of the language but were infamous for creating accidental vulnerabilities in code, and were hard to mitigate. PHP gained a reputation for being insecure at a time of peak adoption mainly due to these features.
This caused a lot of professional programmers to look into other languages by the late 2000's when cybersecurity started to become a real concern.
The PHP team was hesitant to remove these features because it would break tons of code written in PHP. These features weren't fully removed until 2015, 20 years into the programming language's life.
We think the PHP team made the right decision, but too late. The PHP team has since learned from their mistake, and have done an excellent job balancing security with programmer convenience since then. PHP today is secure as any other programming language.
PHP has faced plenty of criticism since then, but a lot of it is sadly misinformed or doesn't come from experience and following PHP's changes over time. Here's our take.
| Point | Counter-Point |
|---|---|
| PHP can't scale | Sorry but this one's a whopper. Facebook ran regular PHP instead of their current PHP derivative until 2014. In 2014, they had 1.39 billion users, and may have been the largest and most trafficked website at the time other than google. Facebook's secret weapon to scaling PHP was using Memcached instead of direct database access; the bottleneck turned out to be MySQL ( as usual! ), not PHP. PHP today is easily 2x faster than the version that Facebook ran in 2014 ( somewhat thanks to Facebook's optimizations from 'hack' being rolled back into PHP. ) |
| PHP is slower than Node.js or something else | Nope. PHP is extremely fast, as of today ( 09/2023 ), there is only one dynamically typed language faster than it: Julia ( https://julialang.org/ ), which doesn't fit the web well, so it's almost a moot point. A majority of benchmarks comparing PHP to other backend languages run PHP via Apache/Nginx whereas the other languages are outputting directly without the additional overhead of the 'web server'. This skews it's performance in an extreme way by amplifying the instantiation overhead of PHP, which becomes a majority of the load during lots of a large volume of tiny requests. A classic example is to put node.js against PHP running through apache. Node.js will definitely pull ahead. However, if we have node.js requests going out via Apache, node.js is always significantly slower than PHP. When PHP is used with an alternate wrapper such as the case with Swoole, the true performance can be seen. For example, as of 2023, PHP with swoole/openswoole is 3x faster than node.js. Source: TechEmpower benchmarks You can also see this high performance during scripts that run for a long time and do lots of computational work without using Swoole. In truth, a web application is very unlikely to include lots of tiny 'hello world' like requests, making these simplistic benchmarks a lot less useful. PHP is an exceptionally fast language considering how simple it is. |
| PHP is insecure! | No language that's written with the C/C++ language as a base can claim to be any more secure than PHP, and this would include Python, Javascript, Ruby, basically 99% of what runs the web. The majority of PHP security flaws these days can be traced back to C/C++ level memory management issues that have plagued everything built on it for decades, including the browser and operating system you are using right now. PHP has had it's flaws studied and patched more than any web development language thanks to it's massive usage. It's no more/less secure than anything else today. |
| Pay for PHP programmers is lower compared to other languages | Actually... this is true. PHP is easy to get into, and that means there's tons of people who know how to work with it - so it's a more competitive job market. Due to the language's brevity and well developed frameworks, less time is also needed to construct web apps in PHP than most other languages. There's just less problems to figure out on it's well tread path. But.. the people writing programmer's paychecks would probably disagree that this is a negative! |
| There are a lot of inconsistencies in PHP! | This is true, however, we also don't know of a language that is significantly better in this regard; no language is without it's warts. PHP has been been completely redone/rethought 4 times, being gutsy enough to break codebases early-midway through it's life. The same cannot be said for many languages who have serious design problems dating back decades. Like with all languages the response to a minor wart is to wrap the offensive functionality in a function and get on with life. We've certainly done this in PHP land, rendering the minor issue a lot less irritating. "There are only two kinds of languages: the ones people complain about and the ones nobody uses." - Bjarne Stroustrup, C++ Language inventor |
| PHP isn't asynchronous | Sorta. PHP is a primarily synchronous language. However, there are plenty of ways to achieve asynchronous-ness. For example, the CURL, MySQL, email, and shell commands can all be used asynchronously. Technologies like Swoole exist to make fully asynchronous PHP possible; so PHP *can* be asynchronous. But asynchronous behavior is not a breeze in any language. It can add significant complexity and room for error in code. Synchronous code is far easier to write, debug, and think about. Unless your application has non-standard needs, Synchronous code will work >99% of the time. Why not start there, and add asynchronous behavior later in spots that require it, rather than impose the burden of asynchronous code on the whole codebase? We think that, serving the goal of simplifying programming, PHP made a good choice here: synchronous-first was the right choice. |
| PHP is old! | We'd estimate that >95% of development done in 2023 is in languages that are 30-50 years old. There are plenty of valid reasons for using 'old trusty' instead of one that hasn't matured, which can take decades. The risk with a new, non-battle tested programming language is high. The wrong choice could lead to a complete loss of that code when a wall is hit. Shops like ours tend to pick what's tried and true to minimize this risk. In our case, we have yet to be impressed enough by a newer programming language to risk being a pioneer. PHP's oldness ( and refinement ) is an asset. |
"Code is bad. It rots. It requires periodic maintenance... the more code you have, the more places there are for bugs to hide. The longer it takes a new employee to make sense of your system. If you have to refactor, there’s more stuff to move around.
...Engineers have n^2 communication costs, and all that code they add to the system, while expanding its capability, also increases a whole basket of costs. You should do whatever possible to increase the productivity of individual programmers in terms of the expressive power of the code they write..."
Rich Skrenta, Former Software Engineering Director for Facebook
At Courtesy, we primarily service small businesses who don't have the deepest pockets. Software development is expensive for them, and we find that PHP allows us to deliver the best value and long term costs on a software project due to how it simplifies and speeds up the programming process.
In 2020, we began developing our own internal software to improve our business, and hopefully one day, improve other people's business. We got to feel how financially painful it is to pay for software development, and it lit a fire under our ass to simplify the software development process even more, for the benefit of us, and our clients!
We developed a framework called Zerolith and it's goal was to cut the amount of programming time by at least 25%, while also simultaneously improving performance.
At one point, we considered a Zerolith port to Python or Ruby to take advantage of their shorter syntax and provide even better value, however, those languages are not capable of supporting most of the features in Zerolith that improved our programming efficiency.
Also, neither were capable of having an in-language debugging tool, which we find very important as it reduces the time to find a bug by ~90%. In addition, we found the slower performance in Ruby and Python meant that we'd have to spend more time optimizing it. The small gains we might have realized in programming efficiency was far outweighed by other negatives. Both also had issues with 'fitting in the web' that PHP doesn't have. What a bummer!
If a business were to ignore the negative consequences of 'slightly faster to program but way slower to execute' languages like Python and Ruby, then they will eventually notice it in their server bill.
So, we think that for business concerns, PHP is also the best choice today. And we are open to the possibility that can change.
We hope this article has been informative from both the programming and business side of PHP.
Thanks for reading!