page updated on July 18, 2015

Why JavaScript and PHP Won the Web

Neither PHP nor JavaScript is great technology. If you look at both languages from a design standpoint, you won't find much exciting. In fact, you'll find a lot of disappointment.

This isn't a theoretical analysis from a research language perspective; plenty of languages in wide use avoid formal methods, fail to expose a core formalism, or even avoid basic type safety and inference from the 1970s. Indeed, one of the most popular languages still in wide use is the C programming language, which hails from the late 1960s. (Despite updates in recent decades, it's still essentially the same language as it was in its initial form.)

Why Did PHP Succeed?

PHP's initial design goal was to make it easy to generate web pages. At its heart, it's a templating language. Take a web page. Add a couple of loops and conditionals. Add some variables. You have PHP. Take all of that away, and you still have PHP.

This means that every web page ever written is a valid PHP document. It's a valid PHP template. Whoever runs your web server can configure that server to serve that page with PHP and it will work perfectly. As well, the Apache httpd web server soon gained an extension called mod_php which added support for PHP. When Apache httpd was the most popular web server on the planet, any server could enable PHP trivially.

PHP wasn't always the obvious heavyweight winner in server-side web programming. System administrators had to enable PHP themselves. It made sense to do that, though. PHP's execution model—the way PHP turns a web page with PHP commands into a web page—is very simple. Every request has its own memory. It gets initialized, the page gets served, and then that memory gets flushed. Absent any bugs in PHP itself, you can have a thousand distinct websites running on a single server, each with PHP, and none of them will know anything about the others.

Yes, PHP running through mod_php was more efficient than server-side programs running in the CGI execution model. If you were running a hundred different websites on a single host and any one of them had any popularity, the overhead of CGI could overwhelm the web server.

Installing mod_php was cheap and easy and teaching users how to modify an existing HTML page to use a few PHP directives was much easier than explaining how to set up a CGI script in Perl or shell or C, including setting permissions and moving things into the right file and adding necessary libraries, so there was little friction for web servers to use mod_php.

If you paid $4 a month for someone else to host your website, chances are they had PHP available. If you installed your own Linux distribution, chances are the Apache httpd installation it had in the default configuration included mod_php.

PHP succeeded because, at first, it was really easy to get there. It really really succeeded because it was already there. Do not underestimate the value of being there. Yes, it was relatively easy to get started—easier than Perl or shell or C, because any existing HTML page is a valid PHP document—but more important, it was already there. People learned it because it was already there, and people installed it because people had learned it and wanted it.

Hiring PHP Programmmers

Employers want to hire PHP programmers because the technology is pervasive (so there's little risk in going with the standard technology) and because there are so many PHP programmers to hire (making them cheap and easy to replace). Programmers want to learn PHP because it's easy to learn and there are a lot of jobs available. Of course, this situation was ripe to become a lemon market of programming language adoption—so it did.

Why Did JavaScript Succeed?

When the web first started, it didn't even have images. It had links between pages and that was just about it. This was a huge advantage over what previously existed.

Then came forms and server-side programming. You could interact with these documents. You could enter your email address and get email from websites. You could add the current date into a page or the total count of everyone who'd ever read it. The possibilities were endless.

Then came Java applets, which were little pieces of code your web browser would download from the server and run on your own computer. This was supposed to be a fast and easy way to do things without waiting on the slow Internet. Unfortunately, Java applets were prone to crashing and using lots of memory and not running fast.

Then came JavaScript, which wasn't an extension to the browser. It was a piece of the browser itself. You could have a browser without Java, but with Netscape Navigator you had a browser which included JavaScript. If you wanted to display the current time or move text around or show a cool effect here or there (when you check one button, pop up a window if you don't like the answer!), you could rely on people having JavaScript.

JavaScript wasn't everywhere—many people disabled it because it was prone to annoying things—but it was potentially everywhere. When the web saw its enormous rise in popularity, web browsers were everywhere, and they all brought with them JavaScript.

(Back in those days, the web was a wild place. One browser would add a feature and the others would rush to copy it. JavaScript's stewards wisely submitted the language to a standards agency, ECMA, which helped to control fragmentation even when Microsoft tried to take over the web with Internet Explorer.)

JavaScript isn't a perfect language. It had ten days of design and it shows. As well, it suffers many of the same problems as HTML: a modern web browser has to be able to display web pages written in 1993 along side web pages written in 2013. Things have changed a lot in 20 years, but old pages must still work. JavaScript is the same way; old code written for Internet Explorer 4 must still work. This makes implementations of the language more complex, because they have to support weird old edge cases, and it makes programming the language more complex, because JavaScript programmers have to account for these weird edge cases.

This shouldn't have made JavaScript a success. In fact, its success was inevitable. Just as no web browser is really usable by non-technical end users unless it supports images, no web browser is really usable by non-technical end users unless it supports JavaScript. When Google Maps demonstrated the amazing things you could do with JavaScript, the game was over. JavaScript had won. That's why the tablet to your side or the phone in your pocket (to say nothing of the laptop on your kitchen counter and the desktop on your desk at work) all have at least one web browser which supports JavaScript.

This means two things.

First, despite its flaws (one of the first among them being the utter lack of a library system, by which you can argue that there are several competing library systems, all of which interact barely at all unless they're all very disciplined and which either bloat the single-page download or rely on very precise versions and browser and proxy server caching systems which are too Byzantine to explain even in this technical parenthetical note), you can count on JavaScript being present on every Internet-capable device which allows unfettered access to a web browser. Every one of them.

Unlike the case of PHP where it's possible that an installation of a web server doesn't include mod_php or where the administrator forbids the use of PHP, you can safely assume that any Internet capable device will have some form of JavaScript. Phone, tablet, computer, TV, console, whatever.

Thus, if you want to write software which runs everywhere there's an end user, JavaScript is an option. It's easy to deploy and it's supported everywhere.

Second, every one of these environments with access to a keyboard (even if it's one of those awful screen keyboards you have on phones and tablets or consoles) is, potentially, a JavaScript programming environment. You don't have to learn about IDEs and compilers or how to set them up and you barely have to learn about file paths on your device. You can start programming in JavaScript right there. Like PHP, JavaScript documents can start as simple HTML documents. You can add to them as little or as much as you like and they still work.

Blurring the Lines with Server-Side JavaScript and JavaScript Client Frameworks

Programmers love consistency so much that they'll go out of their minds with the time and effort and resources required to make multiple seeming inconsistencies more consistent. It's like looking at a pair of knotted shoelaces and spending the entire afternoon untying them. Sure, it's satisfying to your aesthetic sensibilities, but what have you accomplished for it?

With complex applications such as Google Maps written primarily in JavaScript, the inevitable question arose. "What good is the server, if all it's doing is sending some data that a program on the client has to rearrange anyhow?"

Instead of JavaScript being an enhancement to a perfectly functional web page—a dash of spices to add flavor to a nutritious meal—the web page thus became merely a delivery device for an entire program written in JavaScript, executed on the client, which produced the real output the web browser would display to the client. It's not an enhancement. It's the chef.

The interoperability format of this data was, of course, JSON, which is itself a way of representing JavaScript data structures. Given a complex client-side JavaScript application requesting JavaScript data structures from the server, does it makes sense for Perl or Python or Java or even PHP to take data from a database, manipulate it as Perl or Python or Java or PHP data structures, then transform those to JavaScript data structures and send those to a JavaScript application running on the client?

(Things get more amusing when it's not a real database, whatever "real" means in this context, and it's a JavaScript application which contains JavaScript documents, but that only proves the point.)

Why not instead run JavaScript on the server, send serialized JavaScript data to the client, and run JavaScript on the client? Allow the programmers the consistency of using the same language on the server as on the client. After all, you have to use something on the server and you only have one choice on the client.

Hiring JavaScript Programmmers

Employers want to hire JavaScript programmers because the technology has no competition. (Java applets have little adoption, Flash is gone, and unless you want to write the same code three times for desktop users, Android users, and iOS users, there's only JavaScript for tablets, phones, and other mobile devices.) Programmers learn JavaScript in part because there's no competition and in part because it's a ubiquitous programming environment across all of their devices.

Unlike PHP, there's no credible competition. Like PHP, there's no shortage of willing developers. Unlike PHP, the lack of competition has not hurt the quality of available developers. The awkwardness of supporting multiple browsers with JavaScript implementations of dubious quality produced support libraries such as jQuery which help to enforce coding standards (if only inasmuch as they often provide usable extension systems and a consistent set of behavior across wildly divergent implementations). Because the developers of JavaScript implementations tend to want to retain the web's backwards compatibility, a JavaScript program written in 1996 has a good chance of running unmodified in a web browser released in 2014.

JavaScript hasn't suffered from a lemon market of hiring the same way PHP has, probably due to the lack of competition. A good JavaScript developer must stay a JavaScript developer or switch away from client-side development altogether. (This may to some degree explain the desire to use JavaScript on the server side of development: it is an alternative way to continue to program JavaScript while avoiding poor quality employers interested solely in client-side development.)

Quality and Adoption and Winning

Both PHP and JavaScript have grown dominant in their niches for similar reasons, and yet the important details of those reasons are different. Both PHP and JavaScript allow users to start from an existing HTML document and gradually enhance it with programming. PHP does require installation (though you can assume it's available everywhere, because it's cheap to install and configure and everyone wants it), while JavaScript is available everywhere in the same way that a web browser is available everywhere.

None of this addresses the quality of implementation or user experience or design or experience. Technical quality is a secondary consideration to product market fit. From a technical point of view, it's difficult to argue that either JavaScript or PHP is better than its competitors. First, both languages and ecosystems have flaws that other languages and ecosystems lack. Second, and most important, neither really has competition.

Both languages succeeded because they're everywhere and both languages continue to be everywhere because they are everywhere.

If that sounds circular, it is. If that sounds discouraging to potential competitors, it probably is. The only likely way to dislodge PHP or JavaScript from a position of dominance is to provide something essential on a new platform which is even more dominant than the existing platform. Yet as long as the existing platform continues to evolve—compare HTML 5 to HTML 2.0—the chances of replacing either with something better are slim.

Perhaps a competitor will arrive which provides an order-of-magnitude improvement in performance, ubiquity, or ease of support. (Notice how none of those are specific technical concerns about the quality of design.) Yet unless and until that happens, the web will be stuck with PHP and JavaScript—and if this thesis holds true, more the latter than the former.

The lesson to take from this might be very simple inasmuch as it is exceedingly difficult to achieve. Find a dominant platform which is still growing. Attach yourself as an essential part of that platform. Continue to be essential.