In this post, a polyglot dev (PHP included) says we need an alternative to PHP. By which he means a widely used replacement for PHP for web applications and web sites. The idea being that, if you get a simpler, more consistent, secure web app/site language that has built-in support for fun new technologies and techniques like HTTP/2, WebSockets, unikernels and concurrency/async primitives, they will come. “They” in this case being developers who wouldn’t normally know how to write good code in PHP and will magically do so in a language that makes it easier to do so.
The post concludes with no clear recommendation of an existing language, nor even “X language plus Y features”. And, more importantly perhaps, the post doesn’t tackle how that language would rise to fame; remember that we’re talking about an alternative that can take its place as the lingua franca of server-side programming in a web application context, ostensibly by providing killer apps for both new development and cross-language refactors I’ll come back to this omission in a minute. First, let’s do over the stated objections to PHP as it stands.
First, there’s the Apache problem: pulling in hundreds of thousands more lines of code than you actually need in order to run even a trivial PHP site in a production context…because the build in PHP web server isn’t meant for production environments and nginx is too hard to use from a code maintenance and configuration perspective. Matt is right about the built in PHP web server not being a good idea in a production context, but wrong about nginx; most recent PHP projects use the front controller pattern, which is simple to implement in web server configuration whether you’re writing .htaccess files or nginx directives. This should be the default in more places, but when you’re comparing a language switch to what is in all likelihood a few-hour configuration and package change from Apache to nginx, I think the latter wins out.
One follow-on to this is the idea of a 12 Factor app having its web server built in, allowing for HTTP/2 goodies at the language level. That’s a legitimate concern, and we may well start seeing nginx used as an HTTP proxy rather than a CGI proxy in cases where HTTP/2 is really useful. And this is likely a reason why proxygen (a web server) is built into HHVM at this point.
Another follow-on is that bootstrapping a shared-nothing environment at scale is expensive. The counterpoint, somewhat acknowledged in the blogger’s ideal language specs, is that the trap of persisting a large amount of state at the application layer across HTTP requests (which are stateless) gives rise to a whole class of potential bugs where you have to hard-restart your application server to fix them (looking at you, Node). The flip side of this is that a framework bootstrapping step could very well be implemented as an auto-prepend on serioids if services are immutable and pass around value objects. We’re already seeing discussions of that, and that sort of thing can fit into the existing FPM model to a fair extent, bringing an appreciable performance bump with it…while still maintaining enough shared-nothing-ness to allow for the dead-simple horizontal scaling that’s available in PHP applications with just a few best practices (namely persisting state in an external, centralized data store).
The next point in the list: security. Because XHP (auto-escaped HTML, CSS, etc.) and prepared statements don’t exist, and because even better sanitization libraries and safe-string checking aren’t under discussion and/or development right now by members of the PHP community. Except…they are. Additionally, if you abstract away queries-as-strings as a construct in the language (allowing for query building in userland), you run the risk of making it impossible to use relational databases to its fullest extent. Say what you will about join inefficiency, that’s a con when comparing an alternative to PHP.
Third in the list is language consistency. Welcome to the land of backward compatibility, where the syntax barely matters and the semantics…well…you get the picture. When the function lookup table starts out hashing my strlen(), you end up with decisions that in retrospect are, to put it lightly, odd.Similar to how the callback pyramid of doom is odd for those venturing into Node-land for the first time, or 2MB binaries for 150 lines of userland code is odd for someone used to interpreted code running on top of an everything-and-the-kitchen-sink runtime goes to compile a Go app. Maybe not a fair comparison, but one reason things haven’t been completely cleaned up is the PHP community doesn’t want to maintain 5.2 for the next four years because too many legacy code bases (end product or library) can’t easily straddle versions.
Going back to my earlier point, in order for a language to take hold, you need a killer app, a business case and a driving community force of some kind to set things into motion. The bar is set even higher when you want to take over the world in a way that, for example, Node has not By asking for an alternative language, you’re asking for something that WordPress, Drupal, Magento, Laravel, Express and Rails apps can all be rewritten into quickly, easily and with a solid benefit to those doing the work. In this case, you can’t be satisfied with a niche of skilled programmers who like hybrid-functional programming on the JVM (Scala), speedy compiled code with a runtime layer and solid concurrency primitives (Go), or the ability to run server-side code in JS, complete with async I/O. You have to pull from existing communities at large that see something so good that they’ll promote the heck out of the new solution to the problem. That’s a hard hill to climb if you don’t have a pool of developers already somewhat familiar with the language (Scala/Java, Node/JS, even Hack/PHP) to pull from, or at least a big name and a solid niche (Go).
It’s an even more uphill battle as developer time becomes more expensive due to competition for devs, so the ability to refactor to NewLang…or the ability to build NewLang…is called into question.
Lastly, you’ve got the problem of PHP and the ecosystem around it improving to allay concerns raised in the post, building in some features that resolve pain points in that post. Personally, I’d rather have a clear (2-3x performance increase seems clear enough) upgrade path for a large percentage of the web to a platform that goes a ways toward solving those problems than a new, admittedly awesome-looking, language that tries to solve the same problems and but misses a killer app that propels it to scale and scope. At the risk of drawing biased conclusions, that’s why I respect Python, Go and Scala, but am at best indifferent about Ruby, though I use things like homebrew quite regularly.
tl;dr: Fixing problems on a large (in terms of market penetration) system, while not as sexy as building a new thing, is likely a more productive use of time than hand-waving about that new thing, even if you have valid concerns…especially if the old system’s community is decent (particularly for userland libraries) and rapidly maturing.