Via the Seattle Tech Startups list, I came across probably the most vehement, well-written, detailed critique of the PHP language I have seen yet. The author, "Eevee", writes:
> 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.
It's really a great read, and will have you questioning why you would ever want to use PHP at all. It is written for programmers, with very specific criticisms of particular language functionality -- all PHP developers should read it to understand some key issues. I can't really disagree with anything the author has written, either, about PHP itself. But I can at least address some of the criticisms. Mostly by laying out how we deal with the issues he raises.
3 things in particular: Language, missing features, and security.
Language
PHP at its base seems to be fuzzy. As someone who began as an "empowered amateur" I found PHP to be the first language I could just put stuff together and it worked, straight out of the gate, with minimal fuss. The barrier to getting started is very low.
This is a good thing if your goal is to get stuff working, get things done, without a massive amount of study before hand. It's also a dangerous thing on today's web -- it's filled with a lot more people out there trying to break into things, hijack your servers and intercept your customer's credit card account numbers.
PHP has changed a lot since I first started using it, and some of the old crufty shortcuts and inconsistencies are still in there. But most of these language quirks are mitigated by two key things:
- php.net. The web site is a fantastic resource, not just detailed documentation of every function, command, and structure in the language, but also detailed, helpful comments from people making use of those functions. You can directly reach the documentation for any function by adding it to the URL of php.net -- to get the date syntax, for example, this will get you straight there: http://php.net/date .
- Limited number of modules. This is one of Eevee's criticisms, that there is no proper module system. Functions are all declared in the global namespace. While this does cause a lot of function collisions and makes it hard to organize a big project, it makes it quite easy to find a function to accomplish a task. Most other languages, you need to learn specific libraries to accomplish your task, load them as needed, and while there are a huge number of benefits to this approach, having a flat global everything-available namespace I argue makes it quite a bit easier to learn.
Missing features
Eevee's list of missing features are all things I don't see as missing at all -- largely because we have libraries and applications that provide these missing features. And Drupal provides most of them right out of the box -- it's one of the main reasons we have settled on Drupal in the first place. Let's go through them:
No template system. There’s PHP itself, but nothing that acts as a big interpolator rather than a program.
Actually, there are several, you just need to pick one. Before using Drupal, I worked with the Smarty template system quite extensively, and still like its syntax.
Drupal does allow multiple template systems in its theme layer, but most everybody uses "PHPTemplate," which basically uses PHP itself as a template language. Not great for designers, but if you're already a developer, it's easy and nothing new to learn.
No XSS filter. No, “remember to use htmlspecialchars” is not an XSS filter.
Another thing we like about Drupal -- we've got several. filter_xss is the most direct, and there's also check_plain, check_url, and a whole configurable filter system to leverage as well.
No CSRF protection. You get to do it yourself.
Drupal's Form API has built-in anti-CSRF/anti-replay protection.
No generic standard database API. Stuff like PDO has to wrap every individual database’s API to abstract the differences away.
Once again, there are several. For years I used PEAR::DB. Drupal 7 now uses PDO. Who cares what PDO has to do under the hood, as long as it gets the job done?
No routing. Your website looks exactly like your filesystem.
> Many developers have been tricked into thinking mod_rewrite (and .htaccess in general) is an acceptable substitute.
Once again, Drupal has a very extensive routing system based on its menu callback structure. It looks very much like the pattern Eevee points to as being effective. Sure it uses mod_rewrite to get there -- but it works.
No authentication or authorization.
Drupal has a fairly broad authentication system, with plugins for native password authentication, LDAP (which works with Active Directory), OpenID, OAuth, Facebook Connect, and more.
Drupal has an extremely granular, customizable authorization system. We regularly use modules to enforce authorized access to whole types of content, individual content items, individual fields on a content item, content in particular groups, and content tagged with particular tags. And you can easily extend with your own criteria.
No dev server.
Ok. This one I don't understand... but maybe that's because we've built our own deployment systems, with dev servers. Our developers generally run Apache locally, we have development servers with debugging extensions installed, and we use git and drush for managing deployments.
If it's not in a language, that doesn't mean you can't do it. We just use other tools to accomplish the task.
No interactive debugging.
http://pecl.php.net/package/xdebug . True, many PHP devs don't have a clue how to debug, but it's not because they can't -- it's only that they haven't installed XDebug and configured an IDE to talk to it.
No coherent deployment mechanism; only “copy all these files to the server”.
Well, this is how the web was built in the first place -- CGI, static files, etc. And we have plenty of tools for the job -- we use git primarily for managing deployment, drush with Drupal's built-in database upgrade scripts for managing database schema changes, and the Features module for deploying other structural changes to Drupal objects.
I'm not going to tell you that Drupal/PHP deployment is easy. But we've developed tools and strategies to manage it, and it's not a complete disaster.
Security
Eevee's points about poor security in PHP are all really well-taken. And it highlights the problem of having an easy-to-approach, less-rigorous language to develop on -- it's easy to develop bad habits, rely on sub-par approaches to addressing security.
Frankly, the ease of creating security vulnerabilities in PHP has led to a substantial amount of business for us. We've been called in to clean up dozens of sites after they have been hacked. As a result, we have some hard-earned experience learning how people break into PHP sites, and how to prevent it.
However, there's a misconception that using widely-used applications like Drupal and WordPress might make you more vulnerable to an attack. I would argue that trying to roll your own application in PHP leaves you more vulnerable -- because so few people have tested your code. Obscurity is not security, when it comes to web attacks -- automated tools can often break into your application with no knowledge of how it's built. These automated tools attack Word Press and Drupal sites all the time -- and these projects then fix the vulnerabilities discovered. As long as you stay on top of applying updates, and use good security practices in general, you're best off using a widely tested application rather than rolling your own.
Is PHP worse than other languages in this regard? Quite possibly. The question then becomes, which is going to cost you more?
- Finding a non-skilled PHP developer who doesn't take security into account but is cheap
- Using a well-tested PHP platform like Drupal as a base, and a higher-paid Drupal developer who knows how to extend it safely
- Finding a Java/Ruby/Python/Perl/.NET developer who can get the job done in another platform
We think we can deliver more functionality with less risk of break-ins at lower cost using Drupal than the other two options.
And ultimately, that's what it's about, isn't it? Getting the most value out of your investment in a web application?
We've had to develop systems, practices, and knowledge to mitigate the shortcomings of PHP, and as a result we have this process down. We can make very sophisticated applications at what we think is a reasonable cost, with a pretty high level of confidence in the security of our solutions. If you're using PHP without Drupal, you're probably missing some essential features or not adequately dealing with the risks of exploits (or spending more on testing to be sure). If you're not using PHP at all, you might have a lot more to build in the first place to deliver the features you need.
The one thing PHP has going for it is popularity. There's an awful lot of PHP code out there. A huge amount of it is total crap, but enough is used in highly visible, highly targeted sites for us to be confident in the solution.
So what's your take? Please leave a comment below!
Industry
Add new comment