PHP vs. ASP.NET Redux
by Sean Hull

Many programmers rely on warm, fuzzy feelings for their technology choices, but managers have to ask different questions. PHP 5 serves both communities

In a previous article on this topic, "PHP and ASP.NET Go Head to Head," I discussed PHP and ASP.NET, compared and contrasted the two technologies, and provided some food for thought about choosing the best technology for a development project.

That discussion sparked quite a debate. Interestingly, there were those in both camps claiming that the article was biased toward the other. Folks on the ASP.NET side claimed a PHP bias, and some on the PHP side claimed an ASP.NET bias.

This follow-up addresses some of the issues and explains in more detail my thinking and conclusions. It also goes a bit more in depth with these two technologies and, in particular, discusses the new release, PHP 5, as well as the MONO project. Finally, it compares these technologies in terms of which is the best for your next Web-based development project.

PHP had humble beginnings. It was a project in 1995 of Rasmus Lerdorf, who wanted a tool that would help him track accesses to his Web pages. At that point, it was just a set of scripts, but as he added functionality, he rewrote his Personal Home Page Tools in C, adding database access and building on the functionality of the original. In true open source tradition, he chose to release his tools to the community. This release he dubbed PHP/FI (Personal Home Page/Forms Interpreter), and PHP as we know it was born.

PHP at that time was heavily influenced by Perl and had a syntax and variable declarations similar to Perl's. It also was a bit inconsistent, as any budding open source project tends to be in the beginning. Being released into the wild, it began to draw a following of other programmers who found its functionality useful and made critical contributions to it.

In 1997 PHP 2 was released to the small yet growing PHP community but dragged on in beta for some time. At that point, it was undergoing a lot of changes and feature additions. Rapid growth can make software a bit volatile, but as it turned out, the genesis of PHP 3 was even more interesting.

Around that time, Andi Gutmans and Zeev Suraski were working on a university e-commerce application with PHP 2. Version 2 didn't quite cut it, so they rewrote it from scratch. Apparently this decision was unilateral at first, but in an effort to build on the already strong PHP user base, Gutmans, Suraski, and Lerdorf decided to join forces and release the rewrite as PHP 3.

PHP 3, officially released in 1998, brought new extensibility features. These attracted many new developers and really broke open the field for collaborative development among members of the community. By now the language was really coming into its own, with installation on up to 10 percent of all Internet Web servers.

Version 4 came out in May 2000 and brought with it a host of new features. The new PHP engine—dubbed Zend, after its creators' first names—was designed to handle more sophisticated applications efficiently and provide support for more Web servers, as well as new features such as HTTP session and new security capabilities.

What Makes PHP 5 Special?

PHP 5, released in July 2004, marks the maturing of PHP. The addition or fine-tuning of numerous object-oriented features brings you a better language in which to build sophisticated Web-based applications.

By default, PHP 5 passes objects by reference. To provide by-value functionality, PHP has a clone function for making a copy of an object if you need it. Passing by reference, though, is just passing a pointer around, which is more efficient than having to duplicate memory structures. This new version of PHP expands object-oriented support, such as providing the INSTANCEOF keyword as well as better constructors and destructors, which were absent in previous versions. It also adds private and protected variables. Private variables are available to the object itself within member functions, while protected variables are available within object itself in member functions, and member functions of subclasses of the object, but are not available from code outside the class.

PHP 5 also introduces other common OOP features such as abstract classes, which allow you to build prototype classes; the FINAL keyword, which prevents subclassing of a member function; and the CONSTANT keyword, which defines a member variable that-surprise, surprise-is permanent. You'll also find new, sophisticated exception handling with the TRY, CATCH, and THROW syntax. An error during the execution of your program means throwing an exception; for instance, you can use TRY when you do a division to protect against divide by 0. Your CATCH section can display a message saying, "You just tried to divide by zero inside routine X, and this shouldn't happen."

PHP now also supports function overloading, not to be confused with default values. With default values, PHP will use the default if you don't specify a variable. Function overloading allows developers to create several different implementations of the same function, with different input variables. The beauty of this capability is that the engine will figure out which function you mean to use at runtime, depending on the type of variables with which you call it.

PHP 5 clearly has a lot to offer. If you're one of many who have been clamoring for better object-oriented features, you'll be happy with Version 5. And if you've hit a wall in the past with application complexity and PHP functionality, many of the new object-oriented features in PHP 5 are meant for you.

But isn't avoiding bloat what PHP is all about? If I have lots of object-oriented code, isn't it going to mean greater memory usage and, ultimately, slower code?

Yes and no. Bloat is really about loading code that doesn't get used, whether it is libraries of your own making or part of PHP. This also goes for loading unnecessary data or making calculations that aren't necessary. In each case, you, as a programmer, have control.

Here's one example of how you can avoid this issue. Say you're using the XXX class of PHP, but only in very particular situations. Instead of putting the REQUIRE statement right up at the top (which leads to cleaner, more readable code), you can put it immediately preceding the object. Given various conditionals that may never execute, that REQUIRE won't get hit in many cases and therefore those classes won't load. Problem solved.

With a look around at some related PHP projects, you might guess where PHP is moving in the future. There is a project called PHP-GTK. Why? PHP is for Web development, and GTK is for client/server applications on the desktop. Well, that's the curious thing. You can actually write scripts in PHP, just as you can in Perl, or bash, with the familiar #!/usr/bin/bash at the top of your script. Yes, you can write PHP that is not intended for the Web, and some have argued just that.

So if PHP is looking to grow to be a language for writing desktop applications, then it does have its sights set on the full range of ASP.NET functionality. Many have noted the similarity between the latest version of PHP and Java syntax. It's no surprise, then, to see PHP expanding into this arena, and many of the changes support this direction.

OK, let's take a look at ASP.NET. In response to my previous OTN piece, some readers commented that I was clearly biased against ASP.NET. Overall, I would say that whatever you want to do in PHP, you can most likely do in ASP.NET, and vice versa. Where one routine seems to be missing, there are likely two or three other ways to do the same thing, albeit with different code and calling different libraries. Hence, I emphasize "getting things done," licensing, and server platform as the paramount concerns when you're choosing a Web technology. But more on this later. Let's concentrate on ASP.NET now.

Visual Studio .NET Obviously, one great advantage of ASP.NET is the Visual Studio .NET IDE. Regardless of what the opponents of point-and-click programming say, a great IDE can make coding much, much easier and even seasoned developers more productive—that's a fact. It can highlight syntax, let you know when the wrong stuff is commented, do command completion, and just plain help you organize better. Visual Studio has a really nice debugger. And what's more, you can now manipulate Oracle Database objects directly from within the IDE with the Oracle Developer Tools for VS.NET add-in.

The .NET Framework and Markup Abstraction What about the .NET framework? .NET provides classes for markup abstraction, meaning that, behind the scenes, it takes care of the various browsers with which you might be connecting to the site. Want to connect with a PDA or a WAP phone? No problem. Want to connect with a standard HTML browser? You're good to go. It renders the various markups as needed. This can be a blessing or a curse, depending on your perspective. Trusting Microsoft to serve HTML properly may well put certain browsers, such as Firefox, Opera, or other Internet Explorer competitors, in a tough position. On the other hand, in .NET as well as PHP, you, the developer, are free to write your own HTML library, managing different stylesheets for different clients to your heart's content.

Reader Feedback Revisited My previous article on this topic drew an extraordinary range of reader responses, so I couldn't possibly address them all. However, the following issues did pop out. One reader comment mentioned Apache::ASP, so I did a bit of research on this option. Certainly, if you have already invested in a heap of ASP code and want to move your Web servers from IIS to Apache, this seems like a viable alternative. But for those embarking on a new development effort, there will likely be some resistance at the management level to using a non-Microsoft-supported server platform. Over and over in e-mails from PHP developers, I've heard one comment loud and clear: One of PHP's greatest strengths is its strong function libraries and modules. If there's something you want to do—such as creating PDFs, Flash SWFs, and many image formats and handling e-mail—libraries are likely already available to help you do it. Another common point in the pro-PHP comments was that a real developer community has grown up around PHP. This means that bugs are found and fixed quickly. A wealth of email lists are devoted to PHP; and as mentioned earlier, there are an endless number of community-created libraries for doing just about anything. Licensing has been mentioned as a big factor to help you decide which technology to go with, but some reader comments sparked further debate and emphasis on this issue. One comment was that you need a license for the server, and that's it—so developers can go ahead and install ASP.NET on their client machines. But the hidden costs are that if you want to get the latest ASP.NET or IIS but are running older versions of the OS, you have to upgrade first, which will, of course, cost you. Effectively, your OS does not last as long as it can and does in the open source world. Or suppose you have a handful of Win2000 servers and you add a new server. It'll come with the latest version of the OS; say Win2003. Your apps won't run on this incongruous setup, and inevitably you'll have to upgrade the older servers to take advantage of newer IIS and ASP.NET versions. The IDE issue was emphasized frequently, so I'll mention it again here. .NET comes with Visual Studio, which has a very good debugger and editor and lots of other goodies. This is certainly a great advantage to developers, but to be fair, you can get Zend Studio on the PHP side, although it is not free. It also has a host of excellent features. Various other open source editors and debuggers are available for PHP, including PHP EDIT and DBG, respectively.

Compiled Code vs. PHP Interpreted Code .NET compiles code, such as C#, into what its creators have termed MSIL, or Microsoft Intermediate Language. This roughly resembles Java's bytecode, the "binary" you have after you compile the source code. PHP, as an interpreted language, doesn't really have an equivalent here. I use quotes because it is different from the binary you get when compiling C, C++, and so on. In those cases, you compile to a machine language specific to your processor— essentially, coded instructions that only your processor can understand. A C program compiled on a Mac OS X compiler would produce different code from that same program compiled with a Linux C compiler. With bytecode, or MSIL, you have an executable that cannot run directly on any machine without a runtime environment. That is what Microsoft's .NET Common Language Runtime (CLR) provides. That layer would differ on different platforms implemented to execute those binaries and convert them to machine language at execution time.

Saying that PHP is strictly interpreted and that ASP.NET code is compiled is a bit misleading, as evidenced by the common language runtime environment I've described. What's more, with PHP as well as ASP.NET pages, you can configure your respective Web servers to do connection pooling and caching of those pages, so they don't have to be recompiled each time. Inevitably, those PHP pages will compile into smaller pieces than the equivalent ASP.NET page, because there is more overhead with the intermediate compilation with the CLR. Ultimately, this will mean greater memory requirements on your Web server.

What About MONO? MONO is an open-source project that brings the .NET server technology to non-Microsoft platforms such as Linux, HP-UX, Solaris, and Mac OS X. .NET is more than just a Web application development framework, and this project aims to provide that framework as open source. Although Microsoft is starting to embrace its shared source model, in which some development partners can get source code, it will be quite expensive and retain many limitations of closed source. The open source model still guarantees that there are no restrictions and encourages customizing and redistribution.

MONO is worthwhile in itself as a development platform. There is some chance that Microsoft will change the specification or make undocumented changes, although it has shown some interest in other implementations of .NET. Again, however, there is no true support from Microsoft.

In the ASP.NET realm, we're really talking more about mod_mono, the Apache module that implements MONO for Web services. Like the MONO project itself, this project is still under development and is not a completed implementation of the ASP.NET framework. Because MONO is still under development and relies on many libraries that don't fully implement the Win32 platform, it's safer to think of MONO as a third option for Web development, after PHP and ASP.NET, but one that has a lot in common with ASP.NET. As such, it provides much of the functionality and framework of .NET, including a C# compiler, but is not a Microsoft-supported development environment. You're dependent on the community for developing the code (and indirectly Novell, which is supporting the project). In that way, it has a lot in common with PHP for Web development, because you can choose Apache for your Web server, build mod_mono as a module just like PHP, and sidestep all the licensing issues related to traditional ASP.NET development on Windows servers.

So again, you face a dilemma: You have two competing environments and technologies to choose from. Of course, programmers are going to tend to gravitate toward day-to-day needs. They will tend to ask questions such as these: What type of libraries are available, and what is the development experience? Is there an IDE, and how good is the debugger? Can I get the job done easily? All these questions are important, and many programmers rely on warm, fuzzy feelings about certain languages, technologies, and past experiences with them.

Managers, however, are going to ask different questions: How hard is it to get programmers who work in this language? What are the licensing issues? Will development on this platform maintain the security of my enterprise? Will it weaken the security of other infrastructures? Will the servers be cost-effective to maintain? What type of uptime can I expect?

The bottom line is with the release of PHP 5, PHP is a more appealing technology than ever, offering you object-oriented features for building large, sophisticated Web-based applications, with the efficiency of a tool that will get the job done. What's more, you have as your Web servers solid, reliable Linux-based servers running Apache to bring you performance and unmatched uptime.