6 ms·

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, yo

by nir 16y ago

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.

illumin8 16y ago
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.
- michaelbuckbee 16y ago
  While I take your point, the major factor at play here isn't what webserver you are using for development it is the fact that you (as the developer) are the only one hitting the server.
- hartror 16y ago
  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.
  - wisty 16y ago
    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. LAMP. The operating system, the web server, the database, and the scripting language. Plus HTML, Javascript, and CSS. And all the frameworks that "simplify" making these work together nicely. Then they have to figure out how to deploy on the test and prod servers. Oh, and they better back everything up. And some redundancy would be good. That's on top of the existing requirements: - VCS - Bug tracking - Documentation - Project management (Scrum? PMI? Flying-by-the-seat-of-their-pants?) - UX / UI design - Unit tests Not to mention having some domain knowledge. The above is fine for a to-do list, but they might also need to know how to solve "real" problems, not just do IT.
    - roel_v 16y ago
      "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.
- alinajaf 16y ago
  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.
- hdragomir 16y ago
  you don't code much php, do you?
- rb2k_ 16y ago
  > 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...
acabal 16y ago
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.
- X-Istence 16y ago
  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 [1] for an extremely small web server, look at the examples in libevent [2]. 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. [1]: http://cr.yp.to/publicfile.html http://cr.yp.to/publicfile.html [2]: http://monkey.org/~provos/libevent/ http://monkey.org/~provos/libevent/ see [3] [3]: http://monkey.org/~provos/libevent/doxygen-2.0.1/ http://monkey.org/~provos/libevent/doxygen-2.0.1/ (Event Driven HTTP servers)
al_james 16y ago
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).
jimktrains2 16y ago
It shouldn't be in the php binary. Even with ruby you have to have another program,

by nir 16y ago

illumin8 16y ago

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.

michaelbuckbee 16y ago
While I take your point, the major factor at play here isn't what webserver you are using for development it is the fact that you (as the developer) are the only one hitting the server.
hartror 16y ago
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.
- wisty 16y ago
  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. LAMP. The operating system, the web server, the database, and the scripting language. Plus HTML, Javascript, and CSS. And all the frameworks that "simplify" making these work together nicely. Then they have to figure out how to deploy on the test and prod servers. Oh, and they better back everything up. And some redundancy would be good. That's on top of the existing requirements: - VCS - Bug tracking - Documentation - Project management (Scrum? PMI? Flying-by-the-seat-of-their-pants?) - UX / UI design - Unit tests Not to mention having some domain knowledge. The above is fine for a to-do list, but they might also need to know how to solve "real" problems, not just do IT.
  - roel_v 16y ago
    "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.
alinajaf 16y ago
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.
hdragomir 16y ago
you don't code much php, do you?
rb2k_ 16y ago
> 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...

acabal 16y ago

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.

X-Istence 16y ago
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 [1] for an extremely small web server, look at the examples in libevent [2]. 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. [1]: http://cr.yp.to/publicfile.html http://cr.yp.to/publicfile.html [2]: http://monkey.org/~provos/libevent/ http://monkey.org/~provos/libevent/ see [3] [3]: http://monkey.org/~provos/libevent/doxygen-2.0.1/ http://monkey.org/~provos/libevent/doxygen-2.0.1/ (Event Driven HTTP servers)

al_james 16y ago

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).

jimktrains2 16y ago

It shouldn't be in the php binary. Even with ruby you have to have another program,