PHP has been thrashed a lot over the last years. While many critics are doubtlessly true, it is still the most used server-side language to create the web we use today and it is an easy to learn language to get started with developing for the web. There are several approaches to work around flaws in PHP, and I’ll give a short overview of typical representatives here.
PHP is Slow ¶
If this is true or a myth highly depends on the concrete scenario. In the case of Facebook, it’s certainly true, that even minimal performance gains have huge impact on the company’s overall outcome. Therefore the developers there started to mangle with the PHP core and finally published a PHP-to-C++ converter: Facebook Hiphop.
While it is overkill in almost any PHP scenario, it offers an interesting perspective for sites with high scaling needs. The carriers can hire PHP developers, who are significantly more numerous (and cheaper) than C++ developers, and still profit from the speed of a compiled language.
For all other uses of PHP, the gain in speed by optimizing SQL queries would most probably outweight the gain through HipHop by orders of magnitude.
Ugly Language ¶
Several features, existing or missing, of PHP don’t meet the taste of
more experienced programmers. They reach from simple ugliness, like using the
backslash \ to denote namespaces to major flaws, that make the
application of a certain programming style or pattern impossible. An example
for the latter are the non-existing (PHP < 5.3) or clumsy (newer PHP)
attempts to enable functional programming features.
The industrious Ruby community has brought forth a new (and still alpha) tool named Fructose. It’s basically a Ruby-to-PHP compiler, that takes a subset of Ruby as input and outputs PHP on the other end.
Another approach is using PHP only for minimal tasks, that can’t be done on client side. In the blogosphere crreating static HTML pages (“compiling” from a source in Markdown or ReST) instead of a full-featured server setup has gained quite an interest in the last time. For the compiling process PHP is not a useful choice. Perl, Python and Ruby come to mind more prominently. In fact this very blog is produced in such a way: A Python application takes in a bunch of source files and produces static HTML from it.
However, things like contact forms need some kind of server-side processing. Some parts can be outsourced to external services (as happened with the comments on this site, which are hosted on Disqus). But others cannot or should not. The task may be trivial and needs only a short couple of lines in PHP, so there is a viable solution: Produce static HTML for most parts, but PHP pages for dynamic parts of your website within the compilation process.
To keep this site as example, the contact form template contains PHP
statements. If an article chooses to use this template, the Python processor
automatically saves it with the .php extension. É voila, we have a
simple PHP script without having to code PHP.
Mixing PHP and HTML ¶
When PHP started off as platform for more and more complex applications, the once handy feature of mixing HTML and PHP in a single file became a burden. Templating solutions, like the famous Smarty try to solve this issue. However, to be capable to handle even basic features, much functionality already existing in PHP has to be re-coded in the template engine. The use of this approach has therefore been questioned a lot.
Another way is to restrict oneself to a certain programming pattern. MVC frameworks like CodeIgniter try to aid willing developers in coding this way. Logic and presentation are strictly separated, and mixing PHP and HTML is only admitted in the PHP files belonging to the “view” part.
At the end of the day, the statement remains: PHP’s primary value is being an easy to employ templating language. That were its origins and for this use it’s still perfectly equipped today. To say it with Jeff Atwood’s words: PHP sucks, but it doesn’t matter.