Article

PHP5: Coming Soon to a Webserver Near You

Page: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

Of PHP, J2EE and .NET

It’s not unreasonable to say that over the next five years, choosing a server side platform for Web-based intranet, extranet and Internet applications will, for most, boil down to three main options: J2EE, .NET and PHP. This is not to say that others like mod_perl, mod_python/Zope and Coldfusion will disappear, but that none of those have the critical mass required to be regarded as a "major player" for the Internet.

So of "The Big Three", the first thing to spot is the platform that encourages use of dynamic typing. Unless you count JScript.NET or Jython, of the three options only PHP is committed to providing that sort of language level flexibility. Think of it this way: how often do you hear of a Perl, PHP or Python project that failed to deliver anything?

More interesting to consider is how PHP sits relative to the other two major alternatives.

In looking at the Object Oriented Evolution of PHP, one of the features Zeev emphasised was how PHP can interact with external component models such as Java, COM and .NET. In other words, you needn't necessarily choose PHP or… Instead, you can choose PHP and

Also notable is Sun's and Microsoft's views on PHP.

One of the fascinating developments from this year's JavaOne was that Sun and Zend are going to collaborate to Push Scripting for Java, which should deliver a Java Specification for Scripting Pages in Java Web Applications, PHP being the reference implementation. That's great news for PHP, as well as Java. We may start to see a growing number of developers with a Java background contribute their input to PHP, which would certainly boost standards of development, and increase the acceptance of PHP as an enterprise technology, although it's already getting there on its own. Should IBM, for example, make PHP a core component in WebSphere, it will be time to dust of those resumes...

Meanwhile, rumor has it that PHP is on Microsoft's radar as the number one "threat" to ASP.NET. Microsoft recently published Head-to-Head: PHP [version 4] vs. ASP.NET, which seems to be an attempt to enlighten PHP developers of the errors of their ways. Aside from being badly researched as far as its comments regarding PHP are concerned (the authors, according to Google, usually spend their time writing about .NET, which may explain the problem), this report also fails to come to a clear conclusion for or against either technology. And there are other signs that Microsoft hopes to sway PHP developers towards .NET.

My view on understanding these opposing strategies is that Java/J2EE has pretty much sown up the high end enterprise Web space with application servers like SunOne, IBM's WebSphere, JBoss etc. plus support in Oracle. At the same time, J2EE is not being seriously pushed as a technology for "the masses". Put another way, Sun et al. regard PHP as a complementary technology that could introduce Java to new markets, rather than as a competing technology.

At the other end of the spectrum, Eweek recently published .Net: 3 Years of the 'Vision' Thing, which suggests .NET has so far failed to make a serious dent in Java’s market share. Microsoft had hoped that, by riding on the back of Web services, they could gain a significant lead on Java, but the infancy of Web services has held them up, allowing Java to even the playing field. Pushing .NET into big companies represents an uphill battle. Meanwhile, there's this massive market of lower-end applications and sites built with PHP, which, when considered as a whole, represent very significant revenue to those selling the software used to build and run those sites.

If you’ve spent a little time playing with ASP.NET, you’ll know that when you compare it with PHP from a theoretical software engineering point of view, ASP.NET comes out looking very shiny indeed. ASP.NET is a fascinating study in OOP, and Web Forms in particular is something I'd like to see in PHP (watch this space).

But, by crass analogy, ASP.NET is much like driving a BMW 8 series, while PHP is more like a VW Golf. Although the extra comfort of a luxury car is nice, who cares when you just want to get reliably from A to B for a reasonable price? Put in blunt business terms, this comment pretty much sums it up.

One other issue that separates PHP from J2EE and .NET is that the latter two practically require the developer to use some form of IDE. Statically typed languages like Java and C# are too verbose, with class libraries that are too big to memorize -- a fact that deters most developers from spending much time hand coding them. Bruce Eckel made an interesting comment along the same lines in a recent interview, comparing Java and Python (from which PHP isn't so far removed):

"Another number that used to be bandied about is that programmers can produce an average of ten working lines of code per day. Say I open up a file and read in all the lines. In Java, I've probably already used up my ten working lines of code for that day. In Python, I can do it in one line. I can say, "for line in file('filename').readlines():," and then I'm ready to process the lines. And I can remember that one liner off the top of my head, so I can just really flow with that."

Now, maybe you're happy working with IDE's like Visual Studio, NetBeans and Eclipse. Or perhaps you're like me -- you get nervous and frustrated by having to learn how to use a tool that gives you a "dumbed down" version of events, and you’d rather stick to the humble text editor.

Given the budget constraints and productivity expectations that today’s developers have to deal with, only dynamically typed languages like Perl, Python and PHP make realistic choices if you like to work in a pure ASCII environment. In fact, I'd argue that a PHP developer can at least keep pace with a Java / C# developer working in an IDE when it comes to measurable results.

Anyway, the point here is not to get sidetracked into some kind of PHP vs. X debate, but rather to realise that PHP delivers something that appeals to both developers and businesses, and which continues to spur it to greater popularity. High brow software theory would argue that a language that doesn’t enforce the idea that "everything is an object" is fundamentally flawed. Instead of listening to "reason", PHP5 delivers something that, in my opinion, represents the best of both worlds: an object model approaching that of Java's, as well as continued support for the procedural paradigm.

Whether you see it as "the best of both worlds" or simply "a mess" is up to you, but like it or not, PHP just keeps on growing.

PHP: The Next Generation

PHP5 provides the foundations on which we can construct modular, component-based PHP applications. With the features PHP5 puts at our disposal, we can begin building the next generation of PHP applications with a mind to re-use, scalability, flexibility and all that Jazz.

Going back to the question of PHP's "problem" today – that of integration with existing PHP applications – this next generation might manifest in the developers of PHP discussion forums providing us with a set of authentication and messaging components that we could easily re-use to build well integrated Websites that were customized to our own particular requirements, the forum components acting as the "core" of our site.

Developing an ecommerce site to sell pets, for example, might simply be a case of combining a collection of third party classes available in other applications which have some of the features you need, then building the code specific to your site on top of these.

Starting a new PHP project would longer mean writing everything from scratch; it would be an effort that focused on the specific problems that project was trying to solve.

In other words less hair loss, more free time!

PHP6!

Just when thought it was finally safe to go back into the water, I need to tell you that the letters 'PHP' and the number '6' have been used in earnest.

One subject of note at this year's OSCON Parrot. Parrot is a virtual machine that’s being used as the underlying engine for Perl 6, and which is also being implemented by Ponie, allowing Perl 5 scripts to run happily alongside Perl 6.

What's interesting about Parrot is that it may eventually run Python and has caught Sterling's eye -- he's even tried a prototype.

Of course, they’re all pipe dreams at the moment, but imagine a world where you write PHP with both Perl's CPAN and Python’s classes at your disposal. The mind boggles...

Don't forget to download all the code included in this review.

Further PHP5 Reading


If you liked this article, share the love:
Print-Friendly Version Suggest an Article

Sponsored Links

Rate This Article

  • 1
    Poor
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
    Great

Comment on This Article

Have something to say?

Post A Comment

You need to be a member of the SitePoint Forums to comment on this post. Sign Up

Already a member? Post using your SitePoint Forums account: