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.
A Bit More History
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 originally had a syntax and variable
declarations similar to Perl's |
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.
|
PHP 5 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.
What's Next?
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.
ASP.NET Strengths
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.
|
Regardless of what the opponents of point-and-click
programming say, a great IDE can make coding much, much easier.
|
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.
|
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.
What Matters When Biting the Bullet
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.
Vulnerability Report on
Technologies from Security Focus: Gives us a good idea who is doing how from
Security Perspective.
PHP
ASP.NET
Apache 2.0