technically, apache has never had native PHP support....
by The Gecko
I know I'm splitting hairs here, but it's kind of a pet peeve. I think apache is just fine, but think PHP is a collection of bad design decisions.
mod_php isn't and has never been part of apache. Sure, when you build PHP, you can have it compile an apache module, stick it in apache's module directory and have it load the module, but it's never been part of the apache codebase. The PHP module is actually somewhat antagonistic to apache, as it is not threadsafe, so if you're using it, you can't use any of the threaded apache MPMs such as worker or event - you're stuck with prefork.
Kind of the same way that you can download search engine 'toolbars' for your browser (ugh), and they'll install themselves as extensions or plugins, but they're not part of the browser itself.
PHP is no more 'native' to apache than any other web language that can be set up as a module. The difference is that you can just drop a .php file into most LAMP setups, point a browser at it, and it will run. Many other methods (ruby on rails, python with WSGI, FastCGI) require that you run some kind of persistent application process that the webserver can talk to. This is beyond the scope of most casual users and the $3/mo oversubscribed web hosting packages.
Straight CGI is unsuitable for sites with heavy traffic, as it has to fork and spawn a new process for each request.
Apache + mod_php by necessity, has every user's script running as the same UID. That means that every file you upload (including things like configs with db passwords) is potentially viewable by any other user on the system (hello, shared webhosting!) You only have the sometimes-fragile "safe mode" access restrictions built into PHP keeping other people's scripts from potentially viewing your stuff rather than doing it at the practically rock-solid operating system level.
Sadly, PHP is (and looks to continue to be) the dominant language among commodity public webhosting setups, so that's where web developers making packages for mass public appeal are going to keep focusing their efforts. You're only really likely to see an application server type framework if pick a higher end hosting provider or roll your own.
You can certainly do some interesting things with setups like this though, security-wise. I think the best simple setup I've run is one in which each web application can run under its own UID (separate from the user who owns the files), sharing a GID between the owner's user and the application server's user. This way, you have relatively fine-grained control over what the application can read and write (set group read/write bits) without ever having to set anything as world-readable or world-writable.
You CAN actually do this with PHP now, using PHP-FPM. It's a good intermediate step when you need to host someone's stuff that requires php, but don't want to deal with the gotchas of loading mod_php into apache itself. While it's not QUITE as speedy, apache's worker MPM and a persistent application server can are pretty fast, and get far closer to mod_php performance than forking+CGI ever will. Plus, you can do some nifty things with using apache as a caching frontend like this, if your pages don't change very often (like serving up 6000 wordpress req/sec on a single-core VM running on commodity desktop hardware...)
OKAY, that potentially got offtopic and rambly.
Anyway, sadly, we have kind of a chicken-and-egg situation. Most sites people want to host are webapps written in PHP, so commodity hosting gives them PHP and nothing else, because they're selling on slim margins to a whole lot of users. Added expense, complexity and support mean they're not interested in python, ruby on rails, or what-have-you. So mainstream non-php webapps are pretty rare by comparison. I think cPanel (which is what a HUGE number of shared hosting sites use) even has modules for Ruby and its ilk, they're just not used.
I'd love to see a shift to these other languages. Okay, I think I'm done now! :)