What's the deal with the negative comments? You basically get this feature as a gift. If you don't use it, you won't be affected by it in any way. If you do, you get to enjoy the author's labor for free. Where's the problem here?
Any idiot can write a snarky comment about PHP. Very few get to write code that has anywhere near the impact it had.
It's manpower spent on a feature that's more or less already solved with 'apt-get install apache2 php5 && a2enmod php' that could instead be put towards improving the language basics or building out the SPL or other libraries.
And I think that lots of people (myself included) already see PHP as a pretty bloated system; throwing an entire web server into what is a scripting language won't do much to keep it lean.
Edit: instead of downvoting, can you explain how this isn't already a trivially solved problem and why including an entire custom web server with what is a scripting language isn't bloat? Installing Apache really is that easy, even in Windows, if we're just talking about a dev machine.
Developers don't want to spent time setting up an entire LAMP environment. There is a reason why Django and Rails are doing so well and that is it is extremely easy to start development and start testing. With SQLite as the database you don't have a need for a full DB to start developing.
Being able to launch a quick server to do testing is absolutely fantastic. I use poole.py for my site (to create a static portfolio website) and I use its built in web server to view my changes before committing them and pushing them live.
If PHP development became as simple as launching a quick web server just like in Python or Ruby I might once again take an interest in it, at the moment I am just not too interested in working on it, as either I have to set up and run Apache with mod_php on my local machine or I need to set it up on a remote machine, and then files are no longer local, and testing becomes a deploy/test cycle instead, or I am editing files remotely over a possibly slow SSH session, or having to FTP them on save.
No, a built in web server in PHP that does the handling of requests would be absolutely fantastic. Having a simple web server doesn't have to add much bloat at all, it isn't bloated in Python or Ruby either. Look at publicfile  for an extremely small web server, look at the examples in libevent . A web server built into PHP only has to do the bare minimum, serve requests. It doesn't need all of the functionality that Apache has. It isn't meant to be used in production.
But it's not that hard to set up a bare-bones Apache serving PHP on localhost! It's literally as simple as the two commands I posted above on a modern Linux box, and as simple as downloading and running the Apache installer on a Windows box. The installers do it all for you. IIRC after running the Apache Windows installer you can access http://localhost serving PHP right away!
In fact that's part of the reason why PHP became so popular: 1) it's free, 2) it's easy to do basic html manipulation, and 3) it's easy to get a basic setup running.
Why bundle a custom web server with a scripting language when literally all you have to do is visit one more web site and download and run one more installer? I feel like I'm missing some huge key revelation here because I keep getting downvoted for these thoughts. Should PHP also bundle their own custom MySQL engine so I don't have to run 'sudo apt-get install mysql'? Or a copy of Tuxracer too so that I can play it when I need a coding break without having to run the installer?
Edit: in fact, at the risk of further downvotes, I would go so far as to say that if it really is that difficult for someone to do a basic Apache/mod_php install in their OS of choice, they should probably do more reading/tutorials before proceeding down the PHP rabbit hole any further. Figuring out how to install a dev instance of Apache isn't more difficult than reading the documentation for getting this new embedded PHP server running.
> Why bundle a custom web server with a scripting language when literally all you have to do is visit one more web site and download and run one more installer? I feel like I'm missing some huge key revelation here because I keep getting downvoted for these thoughts.
I suspect you're thinking of this in the context of getting a single PHP app running on your box. What if you have several? Or what if you want to have several branches of the same codebase checked out and running? It's doable with some VirtualHost kung fu, maybe a wildcard ServerAlias, but it's no longer as simple as 'apt-get apache'.
Much simpler to tell someone, "Do a 'php -S' in whatever project you're working on at the moment."
It's not as simple as you make it seem! After installation, you still need to edit your DocumentRoot, enable mod_php, maybe set up a virtual host, maintain which document on your machine corresponds to which port on your machine, ...
Your scenario of running a simple test.php from the default DocumentRoot is a very contrived one, one that only the very first beginner will ever use, and even then only because he doesn't know how to configure Apache. Plus it assumes a lot of things: that it's on Linux, that it uses the distro-supplied packages, that they use a setup that is the very basic one, ... OK for beginners, but serious friction ('friction', not 'unsolvable problem' - that still doesn't make it unworthy of being addressed) for many experimentation scenarios.
sorry, but from scratch (no apache, no mysql, no php) to running 2 php/mysql sites in different virtual hosts takes less than 10 minutes on a modern ubuntu box (and probably most of the time will be spent configuring the site, not the servers). plus, i don't want to run a php -something in a shell each time i want to test something. also, while modern ORM's abstract away most of the database , I still wouldn't use sqlite on the dev machine for a site which will run on mysql in production
I'll skip you the drama, but take my word for it, getting AMP to work well together (and working with AMP) is not a trivial task and requires literally years of experience. There are about 1000 ways you can screw it up. You might laugh at this statement with your "apt-get" or your Windows-based Apache setup.exe, but what happens afterwards? And what happens if there is a problem?
Having provided support for so many years, I can tell you it can be a nightmare for some people.
- You only consider one development scenario. It takes 15 mins to download/install/configure/set up vhost at the very minimum, that is: when you've already done it so often that you know all steps and download location by heart. In all other cases it takes a multiple of that.
- All unnecessary steps to get a task done creates friction. Having to set up Apache for the 100th time is downright irritating. Eliminating friction = good.
- "And I think that lots of people (myself included) already see PHP as a pretty bloated system" Yes, well because "lots of people" think its true doesn't necessarily make it so. "Bloated" usually means to complainers "has functionality that I don't use", more often than not followed by a euphemism for "please take away functionality that others use so that I don't get confused by all the options".
- The practical merit of a programming language is not defined by its syntax, or even library. It's defined by those things plus its ecosystem plus its tools plus it community plus all things around it. Ease of use is one of those things too, and a simple way to run scripts is a great boon to this ease of use. Python has an interactive shell, should that not be part of the default package? Some languages come with a build-in debugger, should that not be in the default package? All these tools increase the practical use of the language - one can debate where the line should be drawn, but an argument along the line of 'it's not strictly a part of the language or core functionality so it shouldn't go in' does not make sense.
I don't see many commends negative to PHP itself. Instead the negative comments about this idea point out that it does not really bring that much to the table, and that the resources given to this could be better spent elsewhere.
Also, just because a feature is offered 'as a gift' does not mean it should automatically be included in a OSS project. Thats how projects become bloated (this is not comment for or against the idea, just a general point).
The problem is that this encourages lazy development. Many developers love the ability of tools like Tomcat that allow you to run your web app inside of the application server itself, rather than having to configure a pesky Apache server.
The problem this creates is that once a developer has it running on their own machine inside Tomcat (or now this PHP built-in webserver) the app is probably coded in such a way that it will ONLY run inside this server, and will never scale. What's more, they often turn it into a production application with real customers depending on it, and blame you if you can't make it scale to handle hundreds or thousands of users.
This is the problem with using "built in" webservers. It encourages developer laziness, and encourages people to kick bad code over the fence to the operations team who has to make it reliable and run in production. Never mind that a built in PHP webserver will never scale to meet the needs of more than a few users.
Sounds more like a procedural issue being created by poor programmers and bad management. Not testing it on a production-like environment is a capital offense whether you are using a development server or apache/lighttpd/nginx.
I think it's better if the devs run something close to the production environment.
The problem is, web developers already have a lot on their plate.
"I think it's better if the devs run something close to the production environment."
I used to think so too, but I changed my mind a few years ago. Have diversity in the environment in the phases leading up to staging/testing leads to many problems being uncovered early - hardcoded paths, platform assumptions, potential performance issues that only show under some circumstances, ...
I think it improves the code if various devs use different installation paths, DB's, development tools and even OS's. I've seen many deployment issues that would have trivially been detected if devs had different environments.
> the app is probably coded in such a way that it will ONLY run inside this server
Isn't this exactly what developers are currently doing? A lot of projects are heavily relying on .htaccess files and having the webserver do redirects/pretty URLs for them. They're putting part of the application logic in the webserver...
PHP in general encourages a whole lot worse things than lazy development. If we've already agreed to overlook it's other shortcomings by saying "good developers matter, the programming language doesn't" then we can overlook this too.