When Mark Zuckerberg started coding the site that would become Facebook in 2003, PHP was the obvious choice for the young programmer. Many of the web technologies that we are familiar with today, such as Node.js, Heroku, the Catalyst framework for Perl 5.8 and others, weren’t around back in the early 2000’s.
Simply put, in 2003 PHP was the fastest way to create and rebuild sites. Since PHP is a dynamic language, you didn’t need to spend lengthy amounts of time defining parameters for all the routines in your code and, as a result, you could run it right away without compiling it unlike some of the other language options available back then.
While it can, and should, be argued that code should be judged based on how viable it is rather than which language it’s written in, many people question why Facebook had taken so long to migrate away from PHP.
Why was this such a popular question? To understand, we need to look back a bit in order to look forward. PHP would have worked well for Zuckerberg at the beginning as Facebook launched as a, “social mission to connect the world,” long before it became a giant enterprise with nearly $18 billion USD in yearly revenue, as was recorded in 2015.
The speed at which PHP allowed Mark to revise and reiterate early versions of Facebook, as new users flooded in, fit his hacker philosophy and guiding principal of, “move fast and break things.”
As Facebook scaled up, and continues to scale up, from it’s humble beginnings as a dormitory connectivity tool, far more servers are needed to run it as a PHP site than would be needed if it was using other languages and, as Wired notes, it would have been better to use a statically typed language, which may not be as fast since code needs to be compiled prior to running it, but in the end would require fewer servers and ultimately be easier to manage the code and keep it bug free.
Former Facebook employee Yishan Wong, who was a Facebook engineer during Facebook’s formative years (2005-2010), explained on Quora in 2011 why he believes Facebook had yet to migrate away from PHP.
Wong’s reasons for Facebook sticking with PHP for so long,despite its flaws include:
In recent years, Facebook has worked to make PHP better through its creation of HipHop Virtual Machine (HHVM) which is a PHP dialect that allows coders to use both dynamic and static typing in an effort to bring gradual typing to an industrial level. HipHop paved the way for Facebook’s Hack language which was released in 2014 and seamlessly interoperates with, and has deep roots in, PHP. With Hack, Facebook is advancing from the problems initially associated with PHP, while not distancing itself from the language entirely.
Facebook developers use, and have used, and a variety of both public, and secretive internal, PHP Static Code Analysis tools.
Facebook engineer Yoann Padioleau provides a some insight into which PHP static code analysis tools are used by Facebook on Quora. Among these tools is Arcanist, a tool written in PHP, which contains a number of lexical level checks, detects the use of undefined variables and drives many lint-like checkers. CheckModule, which is run by Arcanist, but now ported to OCaml using the pff static analysis infrastructure, detects the use of undefined functions, classes and constraints and includes style checks for globals, nested functions and others.
Additionally, there is also Spatch which refractors PHP code. Spatch allows developers to express and perform refactoring while using a familiar syntax, the patch syntax.
While Facebook has given back to the developer community at large by publishing to open source a number of its PHP scanning solutions, Jack Lindamood, a former Facebook engineer, notes that internally, Facebook uses at least one, more complex tool which would scan the entire codebase, but this remains internal and away from the public eye.
When it comes to PHP static analysis tools, there are a number of open source options available which may save you money, but also have a number of downsides. Take a look at this document to read about the downsides coming from open source static analysis solutions:
Sign up today & never miss an update from the Checkmarx blog
Interested in trying CxSAST on your own code? You can now use Checkmarx's solution to scan uncompiled / unbuilt source code in 18 coding and scripting languages and identify the vulnerable lines of code. CxSAST will even find the best-fix locations for you and suggest the best remediation techniques. Sign up for your FREE trial now.
Checkmarx is now offering you the opportunity to see how CxSAST identifies application-layer vulnerabilities in real-time. Our in-house security experts will run the scan and demonstrate how the solution's queries can be tweaked as per your specific needs and requirements. Fill in your details and we'll schedule a FREE live demo with you.