PHP development is one of our specialties at Freelock Computing. I've written quite a few PHP applications, some from scratch, some starting with other people's code, some as extensions for open source projects. I've also read a lot of criticism of PHP, and while some of it comes from knowledgeable programmers expert at PHP, most of it is uninformed hogwash. So in this post, I'm going to dispel many of the myths about PHP code, and identify its real strengths and weaknesses. Most myths have a kernel of truth in them somewhere, so I'll try to set the record straight by identifying why PHP has each myth. Ready? Let's get started.

1. PHP is crappy because there are so many crappy PHP programs.
This seems to be the biggest reason people think PHP is a bad language--there are a lot of bad PHP programs out there. Why is this? Probably because PHP is so accessible and ubiquitous that a lot of people without a programming background use it to learn programming. I've worked with programmers inside software companies who have much more formal background, or at least experience programming with others on a team. With somebody to guide them, they quickly learn the pitfalls to avoid, best coding practices, and development methodologies.

Most PHP coders on the other hand started out as web designers, putting together a web page for their neighbor, or their family, or a club of some kind. They have no formal training, no experience working on a development team, no guidance or knowledge about what makes for quality code. The result is inevitably spaghetti code, chunks cut and paste into place without real understanding of how they work, people fiddling with lines until it gives them the result they're looking for.

Naturally, this leads to a lot of crappy software out there, riddled with security holes, maintenance nightmares, poor performance, and many other problems.

That does not mean the language itself is at fault. There are plenty of well-written programs out there that do an excellent job of doing the task they're designed to do.

Result: Busted. Bad programmers does not mean its a bad language.

Let's get a bit more specific about these code quality issues.

2. PHP is crappy because it's hard to read all that HTML mixed in with programming logic.
Some argue that PHP is this way because it is a template language--it was designed to be an easy way to add basic programming functionality to a web site. And while that was its heritage, PHP has grown into a full-fledged powerful language capable of most anything you'd do with any other language.

Nothing in the language dictates that presentation code (HTML, Javascript) needs to intermingle with business logic. I consider the best programs to have a clear division of responsibility between these areas. We use a strong Model-View-Controller (MVC) architecture when creating custom applications, the same architecture provided by many frameworks, and advocated by experts for many other languages. And we're hardly alone in this.

We use the Smarty template system to separate out the templates into a presentation layer. Our model is usually made up of fairly lightweight data objects that own the corresponding database tables. The controller layer is typically a dispatcher of procedural code, often with helper controller objects. You can apply most design patterns to PHP as readily as other object-oriented languages.

Now, the tools you use to develop PHP don't enforce any of this. Unless you're using a framework, you need to create all this structure yourself. But we don't like HTML mixed in with our business logic ourselves, so we don't do it.

Result: Busted.

3. PHP is crappy because it's easy to hijack with all those global variables.
Funny how people try to create all these really easy ways to do things that turn out to be large mistakes from a security point of view. Microsoft has done this over and over. PHP has two particularly annoying "features" that have turned out to be security nightmares, originally there to make it simple to program: register_globals, and magic_quotes_gpc.

register_globals is a setting that takes any parameters passed in a request and automatically turns them into a global variable you can use in your script. The problem with this is that it's very easy for an attacker to pre-define a variable that the script assumes to be unset. As I was learning to program in PHP, I wrote a 500-line script to check and double-check that each variable I was expecting from the browser was legitimate, and that all of my other variables were suitably protected.

At its worst, register_globals turned out to allow an attacker to include a malicious PHP file from a remote web server before your script even started, by setting an autoload variable for a particular module.

register_globals is evil.

But its vulnerabilities are widely known, and PHP has been set with register_globals turned off for several years now. It's going away entirely in PHP 6.

magic_quotes_gpc is more of a pain. It was added to help prevent SQL injection attacks, and what it does is escape all of the values you receive from GET, POST, and COOKIE parameters, adding backslashes in front of any backslash or quote to make it so programmers who pass these variables straight into a database query have some protection built into the language. But it causes a lot of extra work, because your script doesn't know whether this is on or off. If it's on and you escape your strings, you end up with extra slashes in front of everything--and you end up with backslashes scattered all over your pages. We end up checking the setting of magic_quotes_gpc, and if it's on, stripping the slashes before the rest of our script interacts with it.

For any experienced PHP programmer, these are solved problems.

Result: Busted, but there is valid criticism here.

4. PHP code doesn't scale well.
Nonsense. This is purely myth. Here are some of the most popular sites on the Internet that run on PHP: Facebook, Flickr, Wikipedia, Digg, parts of Yahoo. All of those are in the top 20 most visited sites on the Internet.

Result: Busted. Very busted.

5. PHP is mainly a vehicle for Zend to get business.
I didn't hear this one until just recently. Zend is a company with a strong stake in PHP. It controls a lot of the code, it has a decent editor with a debugger, a powerful framework, and a PHP accelerator available as proprietary add-ons. I've had a couple developers suggest that Zend has such a controlling interest in the language that it keeps others out, and you have to buy from Zend to make PHP work best.

Yet this ignores the other options out there. Zend does not have a monopoly in any of these areas. There are several other editors with good PHP debugging support, dozens of frameworks, and a handful of PHP accelerators out there, several of them completely free and open source. Now if you're trying to change the core PHP language, you may need to work with Zend, and I have heard they aren't necessarily the easiest to work with--they don't readily accept changes to core features, and a few developers have left the PHP project because of disagreements over the direction of PHP. And some of these have been serious, related to hardening PHP to prevent some of the preventable security attacks through the language itself.

But as a PHP user, these issues seem far removed. PHP 6 is in development now, promises some decent improvements such as Unicode support and removal of some of the vulnerable settings.

Result: plausible, but not relevant to most PHP developers

6. You can't compile PHP, so it will always be slow.
PHP is an interpreted language, and it doesn't have a built-in compiler. The same is true of other web languages, at least Perl. Python has a built-in runtime compiling system, so you get compiled byte-code without having to do anything. I don't know that much about Ruby in this area.

But you can accelerate PHP quite similar to Python, by adding an accelerator. Zend has a proprietary one. We use eAcclerator on our servers, and there are several others out there. These provide what is called an "opcode cache." When PHP is executed, the interpreter makes two passes: first a conversion to native bytecode, and then execution of the bytecode. An opcode cache stores that first pass to disk, so subsequent calls can use what is essentially the same as compiled code. While it's not permanent, and probably not as efficient as other compiled languages, it does seem to allow our servers to accommodate about 40% more traffic before bogging down.

Combining this with other caching strategies can allow PHP sites to scale up to serve the largest sites.

Result: Plausible, but workarounds available.

7. You can't develop in PHP as fast as other languages. Like Ruby on Rails.
Ok. Now we're getting to the ridiculous one. First off, Rails isn't a language, it's a framework. And by many accounts, it's a good one, providing a lot of really powerful features right out of the box. It might have set a new high standard for developer-friendly frameworks. But it's hardly the only one out there, and because it's open source, many of the conventions it established have spread widely to other frameworks as well. CakePHP is a framework that aims to be the Rails for PHP.

Rails has its downsides as well. The CEO of Dreamhost has an interesting post about his experiences trying to get Rails to scale. While it may be fast to develop in, it may be at the expense of running fast enough to handle large loads. You also need to learn Ruby, which has quite a bit different syntax than PHP. PHP is quite similar to C, Java, Perl, and other popular languages, so it's immediately familiar to many other programmers.

The biggest problem I have with Rails is the dogmatic nature of many of its practitioners. And it has gotten such widespread buzz in such a short period of time that in some ways it's become the new PHP, the new pet technology by a lot of inexperienced programmers due to a low barrier to entry. If you're a web designer and not already a programmer, you would probably choose Rails to get started in today, instead of PHP, because of all the hype. I think that's going to lead to the same proliferation of lousy code that permeates the PHP landscape now.

While Ruby may be a nice language, there's a lot more support for PHP right now, in available talent, web servers, scaling experience, and breadth of libraries available. And by starting with an application that meets 90% of your needs today, you can work on what makes your particular problem unique. Since so many applications and libraries are available for PHP that need very little customization to meet many business problems, developing from scratch with a powerful framework isn't necessarily the fastest way to get the job done.

Result: Busted. While Ruby on Rails is nice, it's not the only way to build an application quickly.

9. PHP is only good for web applications--it's no good for anything else.
PHP was built to be a web application language, but it has a command line interface, a GUI toolkit based on GTK, and other features that mean you can feasibly write just about any kind of application you can think of in PHP.

However, nobody does. I have not seen a single PHP desktop application in use. While we do use it for scripting a few web server-related tasks, they tend to be maintenance tasks or a forked process from a web application. There aren't lightweight PHP libraries optimized to run on embedded devices.

As I look over options to write software for the OpenMoko platform, for example, PHP does not appear to be a compelling option. Likewise, it seriously lacks the ability to interact with hardware or much on the OS level without calling a shell to start some other program. Perl has long been used for these environment, but Python has been taking these environments by storm.

So while it's possible to use PHP for purposes other than web applications, it's not convenient, conventional, easy, or widely done.

Result: Confirmed.

10. It's not a real language--you can't do proper object-oriented designs, objects are copied, etc.
PHP was never designed by computer scientists. You could argue it wasn't designed at all. It was built from the beginning to solve a specific problem: to make active web sites. And it's successful because it's done that exceedingly well.

Over time, it has accumulated modules that do just about anything you might want to do in a web application, from talking to just about any database system out there to requesting pages from other servers to processing financial transactions to generating images and even PDF files. It added object orientation in PHP 4, and made it much more robust and similar to other languages with PHP 5. While it still doesn't do multiple inheritance, or threading, or similar advanced programming techniques, you can implement most common design patterns, objects are now passed by reference, there are constructors and destructors and all sorts of things that give it as much power as any other language for most web applications.

While PHP certainly has its shortcomings, for the vast majority of web applications, it provides exactly the right combination of sufficient power to do the job, and a relatively straightforward way of getting the job done.

Result: Busted, for all but the most specialized applications.

That's enough for now. In a future post, I'll discuss the major drawbacks and benefits of PHP. Stay tuned!

Actually, you can run a compiled version of the Perl bytecode. However, it is usually only slightly faster than interpreted Perl. That is because Perl reserves most decisions for runtime. In addition, modules such as regex are written in C and are already highly optimized. In fact, Perl runs regexes faster than standard C does.

@ak: Lerdorf admitted what? Thanks for the link, interesting article. But my interpretation of this story was that Lerdorf says the Internet is broken, especially Internet Explorer--and that PHP can be used to fix it.

Ugly, unmaintainable, and vulnerability-ridden code can be written in any language. I'm sure more of it is written in PHP than most other languages, but that's mostly due to its success as an easy language for non-programmers to pick up.

@Jonathan: I haven't done that much with Perl, but it sounds like compiling Perl is similar to using an opcode cache with PHP. Many PHP modules are compiled C programs, and there's a repository for third-party PHP modules (PECL).

I have no doubt that there's a lot more for Perl--it does seem like you can find just about anything you might want somewhere in CPAN... FWIW, Perl-compatible regular expressions are quite a bit faster in PHP than POSIX regular expressions...



I want to add to 9. that PHP's garbage collector is utterly broken, making it very hard to run a PHP program longer than the usual time span taken by a typical web page request.

The garbage collector is unfortunately unable to detect cyclic object references and cannot free the memory occupied by objects which contain cyclic references. It can be worked around, but this is associated with some programming overhead and a lot of discipline, which requires the programmer to explicitly unset and destruct objects as soon as they are not needed anymore.

Having created a huge object-oriented web application framework in PHP for myself, I stumbled over all these nasty technical problems and had to solve them in order to keep the memory consumption to its "standard" 8M limit.

I guess, that's a big reason why using PHP for running services or desktop applications is currently not a bright idea.


I agree with this article, but number 7 isn't quite right.... ruby is fairly easy to pick up, but rails is incredibly slow compared to other frameworks at the moment. All this is slowly coming to change, so i think that number 7 should not be included in your list. Aside from that, it was a great article.

php and perl are both excellent cgi langs.

HOWEVER, do not use PHP image modules or image magick commands on shared servers, or their admins will shut off your site without notice claiming your using up to much CPU seconds!! lmfao

PHP is the most versatile of web languages, the only problem with it is that it's really limited to web applications and sites, yeah you can create an actual desktop program out of it but it's too clunky and unnecessary and you should rather spend your time with C or VB or Delphi, etc to make such desktop programs. PHP is surprisingly resilient and can do some incredible things with the given addons and extensions.


PHP is a great scripting language no doubt. It has made possible, for programmers ranging from dumb to geeks, to create fascinating server applications possible. And even, let them able to create live websites and applications, as PHP/Apache combination is available on all servers linux or windows, with least cost as compared to others. But...

There is a very big problem, when programmers opt php as a career as compared to .NET, Flex/Flash, C, C++, JAVA. The reason mainly, it is not centrally controlled, when it comes to providing jobs through PHP. As PHP is opensource, it is taken up by companies, that are notorious as job-masters. While the companies that make .NET, Flex/Flash, C, C++, JAVA etc. have to maintain reputation of being good job-masters ( atleast in theories). However i know, there is no direct relationship, but this works indirectly. I have almost always seen PHP companies, working on weekends, with there programmers engaged giving 16 hours a day. As i said, this is just indirect and blame cannot be put on PHP only. However, it's opensourceness and probably the lack of central control can be blamed. Not sure. :)

In my opinion any programming language has pro and cons but php is efficient and less time consuming to develop.

Add new comment

The content of this field is kept private and will not be shown publicly.

Filtered HTML

  • Web page addresses and email addresses turn into links automatically.
  • Allowed HTML tags: <a href hreflang> <em> <strong> <blockquote cite> <cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h1> <h2 id> <h3 id> <h4 id> <h5 id> <p> <br> <img src alt height width>
  • Lines and paragraphs break automatically.
This question is for testing whether or not you are a human visitor and to prevent automated spam submissions.