An important thing to remember about PHP is that it really isn't stuck in 1996: When we say PHP you need to think WordPress, or Drupal, or CakePHP or Symfony, since that's what one actually uses nowadays. Novices are steered away from code that pipes SQL injections directly to the database, and toward one of these frameworks, which does the heavy lifting for you so that you don't need to reinvent the wheel.
For years I consoled myself by calling myself a "Drupal developer". I'm not a PHP developer; if I weren't using Drupal I wouldn't touch the language with a ten-foot pole.
But I agree that basic PHP is optimized for the style of web development that dates back to 1996: Server-side rendering of HTML templates. (More powerful PHP - the underpinnings of the PHP frameworks, the stuff one gets in the latest versions like objects and namespaces and closures - basically turns the language into the equivalent of every other scripting language, though obviously much more inconsistent; there's no great reason to choose any of that over Python or Ruby except that it degrades gracefully to PHP, which may actually be very important, but only so long as what you're building looks superficially like a server-side-rendered HTML template from 1996.)
One reason why I'm spilling 10,000 words on PHP is that I've been working with it for five years now, but I'm having trouble getting excited by its future. It has a long future, because 1996-style web sites are not going anywhere: WordPress.com has a zillion users and Drupal is taking over the enterprise and, well, Facebook. But one eventually gets tired of living in 1996. And PHP is useless for client-side-rendered "HTML 5" views, or mobile app client development, and its advantages as a templating language become moot if your server-side code is just an API coughing out JSON objects RESTfully. No newb can figure out that stuff today - even wizards can't agree on the proper semantics of REST, for example - and if ever we do develop a framework for designing RESTful APIs that's as easy for novice programmers to pick up as PHP is for 1996-style templating, I'm betting that framework won't be built in PHP.
I actually find php well suited to client-side rendering. Implementing a web service in php is pretty easy. The only thing i use php for is building json-rpc and soap services using zend framework's service classes, wrapping around zend framework's database classes. The app itself is all javascript.
True, and if this is all your server-side needs to be, while there's not much reason to prefer PHP for this above anything else, there's also no reason not to just keep on cruising with PHP.
My experience running PHP cloud services suggests that, operationally, PHP is a dream. It's the least problematic layer of the LAMP stack, at least once you've learned what the words "APC cache" mean.
For years I consoled myself by calling myself a "Drupal developer". I'm not a PHP developer; if I weren't using Drupal I wouldn't touch the language with a ten-foot pole.
But I agree that basic PHP is optimized for the style of web development that dates back to 1996: Server-side rendering of HTML templates. (More powerful PHP - the underpinnings of the PHP frameworks, the stuff one gets in the latest versions like objects and namespaces and closures - basically turns the language into the equivalent of every other scripting language, though obviously much more inconsistent; there's no great reason to choose any of that over Python or Ruby except that it degrades gracefully to PHP, which may actually be very important, but only so long as what you're building looks superficially like a server-side-rendered HTML template from 1996.)
One reason why I'm spilling 10,000 words on PHP is that I've been working with it for five years now, but I'm having trouble getting excited by its future. It has a long future, because 1996-style web sites are not going anywhere: WordPress.com has a zillion users and Drupal is taking over the enterprise and, well, Facebook. But one eventually gets tired of living in 1996. And PHP is useless for client-side-rendered "HTML 5" views, or mobile app client development, and its advantages as a templating language become moot if your server-side code is just an API coughing out JSON objects RESTfully. No newb can figure out that stuff today - even wizards can't agree on the proper semantics of REST, for example - and if ever we do develop a framework for designing RESTful APIs that's as easy for novice programmers to pick up as PHP is for 1996-style templating, I'm betting that framework won't be built in PHP.
But maybe I'm wrong. Hence, deep thought.