The single most popular server side Web programming language on the Web is PHP. I measure this not only by people writing applications in the language, else Java would put in a solid showing, as would a few others. Rather, I measure it also by deployments, and in how many people write code in the language merely to tweak things, to cobble together crappy one-offs, and so on. It is also worth noting that there are probably far more people learning PHP for their own purposes in Web development than Java, because the latter is so frequently learned for the primary purpose of servicing a daycoder career.
When one focuses on open source Web applications, the heavy weighting in favor of PHP gets even more distinct. Ignoring for the moment the people who focus on a single language while ignoring most else, get deeply involved in the community, and take note of every new development there, most people with an interest in Web development will have heard of more PHP-based CMSes than the next two most common languages used for such things put together. Drupal and WordPress easily arise in the minds of many. One of these is usually the first to come to mind, in fact.
There are two reasons generally cited as explanations for PHP's popularity success:
Accessibility: PHP is everywhere, on the servers maintained by pretty much every shared hosting provider that offers support for server side Web development above and beyond the humble SSI.
Accessibility: PHP is incredibly easy to pick up and use for the simplest tasks, such that for many it turns simplistic Web development into unskilled labor. Thousands of "dynamic Websites" are floating around out there, built in PHP by people who are not even aware of the difference between include() and require() in the language.
In some respects, both of these factors are simply different applications of a single factor, as I tried to make abundantly clear above: accessibility.
I believe that accessibility is one of the most important factors in the likely popularity of Web development languages at this point. It is possible this may change, given how quickly development technologies at the bleeding edge evolve, but I find it difficult at this time to conceive of a more important factor.
For server side development, no other turing complete server side development language is as available (first factor) as PHP and Perl. Perl is in fact still more available than PHP, via CGI scripting, but it falls short of PHP for accessibility because CGI is less approachable (the second factor) than markup-embedded templating. While markup-embedded templating options are available for Perl, they are not as widely available as for PHP, which offers such templating as its default mechanism for use on shared hosting providers.
For form's sake, let us deal with the two criteria I attempt to carefully include:
Eliminating "Turing complete" from our criteria, our field of languages is broadened to include such popularity heavyweights as SSI, SQL, (X)HTML, and CSS. I hope it would be reasonably easy for most developers to understand why all of these should be excluded from consideration here.
Eliminating "server side" from our criteria, our field of languages is broadened to include languages like ECMAScript and VBScript. VBScript, for the most part, is ignorable because of its more limited availability if nothing else -- especially given the waning dominance of the Internet Explorer browser even on MS Windows, a browser that also supports JScript (an ECMAScript implementation roughly identical to JavaScript).
ECMAScript's most widely-known implementation name is JavaScript, and is generally used as a client side scripting language with an interpreter implementation embedded in almost every browser in general use. It is, in fact, the one Turing complete language more available than PHP for Web development. It is also more approachable in some respects, because of the fact that little snippets of it -- such as the onload "event" -- are almost seamlessly integrated with the major markup languages of the Web. If any language is poised to take over the title of most popular server side Web development language from PHP, I believe it is ECMAScript.
ECMAScript is more widely deployed than you may think, in fact. It is not only the default, nigh-universal browser scripting language; it is also the language of Adobe Flash, Adobe Flex, and AIR (by way of Flash and Flex), implemented as ActionScript. Beyond scripting content delivered by the browser, the JavaScript implementation of ECMAScript is also increasingly used as the UI development language for browsers such as Chromium and Firefox. One can do some gnarly things to a browser's native interface using good ol' ECMAScript.
The language is even making its way onto the server, for server side Web development. One of the major steps in that direction was the development of Rhino, a stand-alone JavaScript engine written in Java; another was Spidermonkey, written in C. Both of these serve as the basis of several server side Web development scripting engines. Others have arisen as well, including Google's V8 JavaScript engine. The increasingly popular event-driven Node.js environment is built on V8.
Thus far, however, widespread availability of server side ECMAScript offered by shared hosting providers eludes us. It is difficult to get buy-in for a new language on shared hosting platforms when PHP is so popular and already available. Hosting providers, for the most part, would prefer to provide as little as possible; PHP is available mostly because it is a dire necessity of general purpose hosting providers that want to have customers who do their own server side development. SSI and Perl/CGI just don't cut it any longer. That universal availability supports PHP's popularity; PHP's amazing levels of server side popularity supports its universal availability. Server side ECMAScript has neither on the server.
Remember, I said that if any language is poised to take over the title of most popular server side dev language right now, it is ECMAScript. These hurdles are tremendous, and make the likelihood of its widespread adoption very small. This does not mean I was wrong about ECMAScript; it just means that the hurdles faced by other languages are even more prohibitive. Ruby may be the next most likely, via the Rails framework -- but while that has had more success making inroads to widespread availability on servers maintained by hosting providers (where the shared hosting providers are the lowest denominator), it faces a certain amount of resistance to growth at the high end of popularity thanks to the dominating aspects of PHP. After all, with Ruby on Rails you need to learn a specific framework to use it.
Any general purpose Web hosting provider that offers Ruby on Rails and Perl/CGI also offers Ruby/CGI -- or, at least, enough of them that the exceptions are negligible for our purposes. This also provides for a simple means of getting arbitrary, largely PHP-style templating, by way of a clever little hack-around known as eRuby. The way eRuby works is simple enough, from the perspective of the technically proficient: place an eRuby program in your domain's cgi-bin directory, and make sure your server is configured to recognize certain file types as needing to be parsed by the eRuby program. This last step is normally accomplished by adding directives to the .htaccess file on Apache hosts.
The popularity of Rails is a phenomenon not easily dissected and reproduced. It seems almost to have arisen spontaneously, and this is the basis of everything that has followed for Web development popularity of the Ruby language, including eRuby implementations. Some of this popularity could be leveraged by other languages (such as ECMAScript) by jumping directly to a CGI implementation, bypassing the other factors that led Ruby to the point of having its eRuby tool. For that to work, of course, one needs to actually implement the entire language within CGI rather than just create a template parser in the cgi-bin directory that passes code off to a non-CGI interpreter. While this latter approach is how eRuby is becoming widely available, it only works because of the growing ubiquity of Rails; without that kind of fortuitous foot in the door, other languages have to bootstrap themselves via CGI.
This is, naturally, a lot of work. Those eRuby implementations I have looked at do not implement Ruby as a whole without relying on some outside interpreter or VM. If there is a complete, isolated eRuby implementation that comes with its own embedded Ruby interpreter or VM and relies on no outside software to work from the cgi-bin directory, I have not encountered it. That does not change the fact that such a tool would be a huge boon to early availability for lowest denominator Web developers, using shared hosting providers that offer cookie-cutter server side programming options.
There are quite a few JavaScript engines out there, and there are many server side development options based on these engines, but growth of the popularity of ECMAScript as a server side Web development language is still tentative at this point. Something as "simple" (for lack of a better term) as a pure-CGI implementation of ECMAScript, complete with markup embedded template syntax support, would be a gigantic leg up on popularity. The same goes for just about any other high level dynamic language that has aspirations of widespread server side Web development adoption.
Unfortunately, even the CGI implementation approach is suboptimal. It requires the installation of the interpreter needed to do your server side development, and many people have enough trouble getting to the point where they can write valid PHP (which is pretty sad, given PHP's anemic syntax). Even worse, anything that depends on an outside implementation of yet another language that is not widely deployed on shared hosting provider servers, such as Rhino, is doomed to obscurity -- relative to PHP, at least.
If ECMAScript could somehow gain at least nearly the same availability on the server side as PHP has, that -- coupled with client side ubiquity and the near-PHP approachability of the language itself (in some ways greater approachability in the case of its client side scripting) -- could be all that is needed to push server side ECMAScript into direct competition with PHP for its currently unassailable position as King of the Hill where general server side Web development popularity is concerned. Considering the general superiority of language design of ECMAScript over PHP, it would be awfully nice.
In the meantime, I will use Ruby. I like Ruby more than ECMAScript, I know it better than ECMAScript, and it is a lot more accessible as a server side scripting language than ECMAScript. It is also a darn sight more pleasant to use than PHP. Such is life.