PHP’s Enterprise Strengths and Weaknesses, Take 2

Editor’s note: Some readers disagreed with the points made in our previous article, You Used PHP to Write WHAT?! in our series of the pros and cons of each dynamic language. We invited John Coggeshall, senior member of Zend Technologies’ Global Services Group, to provide his own enumeration of the dynamic language’s suitability for enterprise computing—both its advantages and disadvantages.

Just as a carpenter will tell you that it is much better to use a screwdriver rather than a hammer to secure screws into a wood plank (although arguably both would work), an experienced programmer will say that certain languages are better than others at certain things. So, in the digital toolbox of the developer, where has PHP been designed to work best? And where is it, perhaps, not the best tool for the job?

More on Web Development

You Used That Language to Write What?!

Beyond Ajax: The Future of Web Development

Five Compelling Reasons to use MySQL

Sign up for our Development & Architecture Newsletter

PHP was designed to solve what I (and others, such as PHP’s creator, Rasmus Ledorf) call “The Web Problem,” by which we mean the challenges found in the creation of dynamic server-side applications on the Internet or on an intranet. PHP was created to—and continues to evolve to—solve this single problem, which perhaps is the biggest reason why it’s been a (if not the) Internet programming language of choice for such a long time. In fact, PHP is the fourth most popular programming language in the world, according to the TIOBE Programming Community Index, above C++, Perl, Python and Ruby. (In all fairness, this probably represents the reality that more people are writing web applications and are turning to a language designed to solve that problem.)

While other languages can surely be used to solve The Web Problem, in this article I explain why PHP is the premier solution for server-side Web scripting.

The Web Problem and PHP

Unlike most programming languages, PHP was designed to function within the challenges of Internet development, which include statelessness, heterogeneousness, typelessness, and the short shelf life of transactions (that is, after all: a typical Web request lasts only a fraction of a second).

For example, PHP is a loosely typed language, which means a variable can switch from one data type to another. This is often a point of criticism for PHP, as developers coming from a traditional background would consider such a behavior sloppy and unpredictable. However, for The Web Problem, such behavior makes sense; after all, the data has no type coming in or going out so why should it have a fixed type in between? The biggest reason might be to add rigidity to the application, but I would argue such rigidity applies only to object oriented programming itself—and to that end PHP does support type hinting for complex types (such as classes, arrays and interfaces).

The Web’s stateless nature affects one architecturally significant difference between PHP and other Web languages. Without state, your “Web application” isn’t really an application at all. Rather, it’s a collection of atomic, individual and completely disparate scripts working in unison to represent a holistic application with no direct way to communicate with each other. To further complicate the matter, multiple copies of a single script can run concurrently for different users; you have to distinguish individuals from each other. (That’s where cookies come in, incidentally.)

Plus, each Web request script typically is built, runs and is destroyed within a fraction of a second. Only in a unique set of circumstances would a “traditional” development language be suited for this environment.

Every development language has a different solution to this notion of state. In Java, state is created by maintaining a persistent virtual machine backend. using an application server, to which each front-end Web request must communicate. The application server almost always requires dedicated hardware resources and can be a single point of failure. Plus, it is inefficient to open a second network connection for every incoming network connection, which often then results in a third network connection if the application server business logic must communicate with a database backend.

PHP takes a more simplistic approach because it was designed to live and die within the context of a single Web request. PHP instead relies on standard HTTP technologies, such as GET/POST variables and cookies, to “remind” a given PHP script what its state was (often stored in a database backend, although commercial products such as Zend Platform provide enterprise-ready session clustering alternatives). This architectural simplification has a significant impact on overall application complexity and performance—an impact that could not be achieved in a language originally designed assuming state and a long-running process.

Next: Platform Support and Security

PHP receives a fair amount of criticism in regard to platform support, especially when you’re trying to run it in non-*inx environments such as Windows. Because PHP was originally designed to work in Linux, historically it performed poorly in the vastly different Windows. Some of this was because PHP does not run well in a threaded environment, particularly Microsoft IIS. However, the introduction of FastCGI technology into Microsoft’s IIS Web server platform resolves this critical barrier to PHP’s success on Windows and has ultimately led to the recent certification of Zend Core (Zend’s certified PHP distribution) on the Windows Server 2008 platform.

Think of PHP as a sort of programmable glue. PHP supports 19 databases (including Oracle, MySQL, Microsoft SQL Server, SQLite and PostgreSQL) and all service-oriented-architecture protocols such as SOAP and XML-RPC. You can also work with other programming languages. In particular, there’s Com/.Net integration (free) and Java integration (available commercially although free versions exist) so PHP developers can work with .Net or Java classes.

Add to that a vast amount of functionality for connecting with LDAP, “Web 2.0” identity management technologies (such as OpenID and information cards), and MVC (model, view, controller) architecture provided by Zend Framework…and you end up with an enterprise language designed with one purpose in mind: creating front-end highly integrated solutions for Web 1.0 and 2.0 applications.

Security and PHP

PHP has been criticized for not being a particularly secure language, which is simply incorrect. That is not to say PHP hasn’t encountered its fair share of security holes on a language level. But as with all enterprise languages, those holes, when identified, are almost always fixed before anyone encounters them being exploited in the wild. Rather then the vulnerability being in PHP itself, very frequently the vulnerability lies in the application that was written in PHP. This is true for all languages. A poorly designed application is likely to result in security holes that can lead to cross-site scripting attacks (XSS), request forgeries (CSRF) or a gamut of other injection attacks.

If there is a valid criticism of PHP regarding security, I think it’s much more balanced to say that PHP has—in the past—made it quite easy for a developer to write insecure code than to say PHP itself was ever incapable of writing a secure application. Thankfully, with the release of PHP 5 two years ago, it is much easier for developers to create applications that don’t lend themselves to such attacks as easily, especially when those applications also are built on a well-designed application framework.

Next: The Good, The Bad and the Ugly

The Good, Bad, and Ugly of PHP Application Development

I think of PHP very much like I think of chess: It’s very easy to learn, but incredibly difficult to truly master. This has led to the notion that PHP is useful only in a prototyping capacity: that it’s easy to build an application quickly but challenging to build an application quickly and properly.

That’s a fair criticism, and one that projects like Zend Framework have worked very hard to address. The Zend Framework provides an easy-to-use library of functionality that adds the structure that PHP itself does not provide. However, even with something like Zend Framework, there are certain quirks about the language that simply have to be worked with. Notable among them is PHP’s amazing lack of any sort of consistency in its APIs. Because PHP was developed in a very organic fashion (especially early on), developers find many curious decisions regarding the API naming conventions. This tends to make a developer’s life difficult until he commits the API names to memory (or uses an IDE, which does it for him).

To further complicate matters, developers cannot rely upon the API consistency from one PHP to the next, even in the same PHP version. This is because PHP’s functionality—nearly in its entirety—is derived from a very large group of C-based extensions (which can be enabled or disabled at the whim of the system administrator) and an entire library of other extensions that don’t ship with PHP (called PECL extensions), which may not be available at all.

The result, especially when a developer attempts to write applications to be used by the public at large, is a lot of wasted time and energy. She has to re-implement or otherwise create workarounds for functionality that may or may not be available in the end user’s particular PHP installation. Thankfully, if you aren’t writing applications that are going to be distributed to the public, this issue can be mitigated relatively easily, simply by standardizing the Web farm on a single version and set of functionality.

PHP has also been very weak in the area of enterprise tooling, especially when compared to other established languages such as Java. Unarguably, PHP can be improved in the spaces of development tooling, deployment and testing. Significant efforts are under way to do so, through projects such as the Eclipse IDE for PHP (Zend provides both a free and a commercial version) and open-source projects such as PHPUnit, which provides an extensive testing and code-coverage suite. The good news is that, while PHP itself is relatively weak in the steps leading up to a production application, substantial tooling is available to monitor and enhance your application if you need visibility into the application’s health, using software like Zend Platform (Zend’s commercial application server).

In the past three years, PHP has made significant inroads into making application development faster, stronger and easier. However, use PHP for what it was designed for: writing Web applications. Your best bet still is to use a development framework such as Zend Framework if you plan on maintaining your PHP applications for any significant length of time. Also, plan to spend more time than you may be accustomed to deploying your applications, as while the tools exist to make PHP deployments relatively simplistic and on a par with other languages, the responsibility is yours to piece them together in a way that suits your needs. Happy PHPing!

John Coggeshall is a Senior Member of Zend Technologies’ Global Services Group. He provides professional services to clients across North America and sometimes beyond. Coggeshall, who started with PHP in 1997, is the author of three books and more than 100 articles on PHP technologies. He is a active contributor to the PHP core as the author of the tidy extension, and also is a member of the Zend Education Advisory Board and frequent speaker at PHP-related conferences worldwide. His website is a resource for any PHP developer.