Facebook’s Association With PHP

According to the history described on the Wikipedia page for Facebook, Zuckerberg wrote the initial code for Facebook in October 2003.

Consider what other web technologies might be considered, and whether they existed in 2003:

• Ruby existed, but no Rails yet (1.0 was introduced July 2004).

• Java 1.4 with JSF 1.x or Spring 1.0.

• Perl 5.8, but no Catalyst framework (it was introduced February 2005).

• Python existed, but no Django framework (it was introduced July 2005).

• The term Ajax for web programming was coined in 2005, but the use of asynchronous XML requests was still nonstandard, too early to be used with for broad browser compatibility.

• C# 1.0 and .NET 1.1 (C# 2.0 was introduced June 2006).

• JavaScript existed, but no Node.js (it was developed in 2009) and no jQuery (it was introduced August 2006).

• Amazon EC2 was released in August 2006.

• Heroku was founded in 2007.

• Go first appeared publicly in 2009.

The point is that Facebook’s choice of PHP was perfectly reasonable for the time it was created.

And Why Facebook Has Not Done Away With PHP?

The reason Facebook hasn’t migrated away from PHP is because Facebook’s engineers have managed to work around many of its flaws through a combination of patches at all levels of the stack and excellent internal discipline via code convention and style. The worst attributes of the language have been avoided and coding style has been rigidly enforced through a fairly tight culture of code review.  Engineering management has never had to take a strong hand here. This arose largely due to key internal technical leaders just sort of pushing everyone else along.

There is also a lot of industry precedent indicating that re-writing an entire codebase in another language is usually one of the worst things you can do, so at all levels there is a reluctance to do that.  The preferred strategy is to write new components in a decoupled manner using a better language of choice (C++, python, Erlang, Java, etc).

This is easily facilitated by Facebook’s early development of thrift, an efficient multi-language RPC framework.  This also helps avoid the worst effects of PHP: it can be totally avoided in subcomponents where the language is grossly-unsuitable.  The broad effect is that the overall codebase slowly evolves away from depending as heavily on PHP, with the components that are still in PHP being written in tightly-controlled, disciplined ways by veteran members of the staff.

The flavor of PHP used at Facebook, Hack, is very far removed from what we typically think of when we picture PHP. In almost every way it has been ahead of JavaScript. It had static typing, generators, async/await, tuples, anonymous functions, classes, and XHP for a long time, often years before they were available in Node. As a result the Hack codebase is very close in spirit to a modern JS application.

So, to summarize it, Facebook has internally upgraded features of PHP by using its own unique methodologies. Hack, their flavor of PHP is far better than most of the other options and hence they have stuck with it, and are likely to in the near future as well.