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 [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.
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.
It's not trivial to work with apache since it's an old bastard designed to run as a system service. It's fine for production but during development and testing it's a pain in the ass.
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.
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.
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.
"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.
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.
> 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.
Hopefully this will end the long-standing practice of novice PHP developers writing code and pushing it to production to test it (or worse, editing code on the production server).
Yes, I know you can set up Apache and mod_php or whatever, but starting a server from the command line is just awesomer. You'll see, guys!
This is probably the biggest potential win for this feature as long as said developers understand the difference between the inbuilt webserver and the production server (the difference between python paste and apache/mod_wsgi).
And for those, who want greater flexibility, https://github.com/indeyets/appserver-in-php is a Ruby-Rack/Python-WSGI style solution which gives you possibility to initialise objects, open db-connections, pre-warm caches, etc. before serving requests. Provides HTTP, SCGI and Mongrel2 interfaces
Seems like this would be useful for development. It'd be great to be able to print to the console for debugging purposes etc. while working on something.
While tail'ing apache's error log is how I debug PHP as well, it is not nearly as nice as the possibility to get full debugging within PHP much like Python does.
Also, this would make it easier to use Xdebug or something like that as it wouldn't require that to be installed in a possibly production system.
Also, most beginners using PHP start off with some shared hosting somewhere and get the directory include stuff wrong and now have live bad code on the web. At my university that was a big issue, but it is the only way these beginners had to test their website.
When working in Django (which uses a similar builtin webserver for development), I can do a `import pdb; pdb.set_trace()` in the middle of my code to drop me down into a Python shell. If you're used to working in a REPL, it's insanely helpful.
The best argument for PHP having it's own web server is to allow novice developers an easy way to code and test their sites. I'll go out on a limb and say I don't think the lack of a built in web server has hurt PHP's adoption in the past.
And a built in web server would only be good for the novice tinkerer. I don't see entrenched PHP shops switching, nor new applications being written specifically for the build in server when Apache w/mods, nginx or LigHTTPD offer better solutions (mature solutions) that are available now.
I guess no one really needs this bad but if someone's up to build it, why not?
If it's kept as simple as the RFC suggests, it should be stable real soon and there are definitely scenarios where I'd choose this over launching Apache or even installing it, depending on the task and environment.
Give it some time to burn in first. Always give any new webserver time to burn in first. I'm not sure that anyone has yet successfully produced a web server that does not ship with the trivial directory traversal vulnerability on day one, for instance.
I don't say this because it's PHP particularly either. Nobody seems to be able to avoid really trivial and massive vulnerabilities in new web servers. I've lost track of the number of times I've seen it. I'd link to a search of osvdb.org for "directory traversal web server" but it seems to be down.
One thing the Symfony2 framework does that I sort of appreciate is limiting access to the page to calls from localhost only by default. It seems like that might mitigate some of the (no doubt gaping) security issues.
I feel this is trying to solve a problem where there isn't one. You can easily install MAMP or XAMP and have access to a full stack if your developing on your local machine. There are so many other higher priority items for PHP to address.
Not true. I have developed in python, and php for many years. PHP has always suffered from the problem of having to install MAMP, or XAMP.
When using django, you just have to install django using something like pip. Then from your project folder you can launch a dev server without need to configure apache.
As Steve Jobs would say, 'it just works'. Projects like Drupal would benefit immensely from something like this.
As a PHP newbie many years ago jarin's comment resonated with me:
"Hopefully this will end the long-standing practice of novice PHP developers writing code and pushing it to production to test it (or worse, editing code on the production server)."
I was guilty of this because I just wanted to start writing code, not shave yaks for an hour to get Apache and everything else installed.
Rails definitely got this right, I doubt it would be nearly as popular if it weren't so freakin easy to get started on the tutorials. Not that PHP has a popularity problem.
There is practically never a valid excuse for uploading testing code to production, unless the site is down and you already have everything under revision control.
It's not just for absolute beginners. I tried the vaunted "running Passenger locally" method of Rails development but I didn't really like having to configure it and all that (even PassengerPane was a pain). Much easier just to cd into the project directory and type "rails server".
I'm trying to help a friend get started with PHP and she is thoroughly confused by XAMPP for some reason (I wish she was using Linux or a Mac!). A server like this will be useful for beginners who have a lot to think about before HTTP or database servers.
I really hate this idea. Coupling the server to the language seems like a weakness in both django and rails to me, since it means deployment becomes more of a scary hurdle, with possible changes in environment between your dev server and production.
One of the strengths of PHP has always been for me that your development and production environments are pretty much the same, and deployment is just a matter of finding a way to copy the files over (and you can be as simple or clever about that part as you like).
Teaching a newbie how to run the PHP server is not that much less complicated than getting a default apache install running (especially with all the LAMP and WAMP installers out there to do it for you), and then you'd have to teach them about apache anyway before they pushed to prod.
I think that advice flies in the face of best practices.
1. Your dev box isn't supposed to be very similar to production, this is why you have staging servers. My dev boxes have weird tooling and debug tools. They also run all services on a single box rather than distributed. Don't pretend dev is at all like prod, this assumption will disappoint you.
2. App servers, which generally speak HTTP and use a standard interface (in ruby Rack, in Python WSGI) and speak HTTP to a load balancer (probably nginx). Are simple and just work. They're less pain than setting up apache. `cd myproject && rails server` is nice.
3. There are about 10 billion things you can get wrong with setting up a production server. If you can't figure out how to proxy requests to an app server you have no business setting up a server in the first place. You've probably already lost.
1. My dev system is a series of VMs that mirror that same box deployments we have in production, the only difference being that systems we duplicate for redundancy in production are singular in dev. I've found that this prevents accidental dependencies between libraries and processes that would otherwise complicate deployments and scaling.
2. For me, "apt-get install apache" once is much simpler and cleaner than running a dev server every single time, but I have been doing it this way for more than a decade, so perhaps you are right and I am just set in my ways.
3. If you can't set up a production environment you can't set up a production environment, and it doesn't matter which architecture is involved.
I have to say that php-fpm does FCGI very nicely and works well with Lighttpd and Apache (even on the same host).
It basically sets up a separate instance that runs PHP and requests are shuttled to the backend. Unfortunately there is no way to talk to it directly like there would be with rails and django's built in Python servers.
They are the same in that they are both based on PHP under Apache, and therefore system and global variables are available in the same pattern. Obviously a development environment is not going to be the same as production, just architecturally the same.
NodePHP anyone? heh, afraid that would be a little more then just a SAPI implementation though, we'd have to throw out a good chunk of the standard library and very few if any extensions were coded for asynchronous execution.
I don't really get it as the RFC clearly compares two different things. Web servers included in frameworks to ease the development (django/ror and others like web.py) and a web server included in a cli interpreter which is more or less the engine itself.
For me there is a huge difference and mind gap I'm not ready to do.
I genuinely think that php is a convenient language for a lot of things but implementing a simple class (like SimpleHTTPServer) looks more natural to me than adding a server directly inside the cli.
As much as I'm not so sure about the overall idea, it had never occurred to me to look at cli php from this angle before. Rather than homegrow the listener/invoker there I wonder how hard it would be to do this with xinetd.
Then there's the apc cache question, there would have to be some way of persisting/sharing it.
This is nice for a PHP cloud PaaS. Imagine the instructions for testing an app locally before deploying it to the cloud. Instead of trying to coach the user on setting up Apache (or whatever) in a way that mirrors your platform, you just point them to "php -S".
I would agree if the webserver was a functional replacement for apache in a production machine. What I mean is that, if the built in server is more efficient than apache and it can be used with performance gain (lets skip the middle man)
I know its kinda useless for anything other than "just because i can" but anyone can code their own webserver in for PHP using PHP. Just saying. Might be useful for development on your own machine or something.
Django has this built in, Rails too.
PHP went a step further and put this in the core language and that makes sense because PHP in itself is meant for the web, and is not a framework over some other language.
Actually, it is. PHP is a Web framework for C, except it uses its own syntax. Or to be more precise, PHP is a templating engine for C, only it got out of control.
If they mean for it to only be used for development and not production, it would be funny if they hard coded a specific set of 'normal' ports that it would not work on!
I'm just thinking this would be better suited for a quite simple php script/framework you could download, since it's not in any way meant for deployment.
Oh god... as if configuring Apache for a non-trivial site wasn't complicated enough, now we'll have the full genius of those responsible for PHP's function naming conventions writing their own web server? Is this really necessary? Why not spend the time making PHP's namespace support not suck, or working on the SPL?
Curious as to why you think PHP's namespace feature (I'll assume you mean the real one introduced in 5.3) sucks.
It seems like you didn't read the whole RFC. The configuration is actually very simple (just the command line options), and not meant to be a front-facing HTTP server.
Off the top of my head, because when I want to reference My.Namespace.MyClass.Foo(), I have to do something like:
use \My\Namespace;
$var = new Namespace\MyClass();
$var->Foo();
I have to remember and type the parent namespace for every imported class I want to use. In a big project this gets to be too much typing and too much for my brain to remember. Contrast with say, C#:
using My.Namespace;
MyClass var = new MyClass();
var.Foo();
You import a namespace, and the compiler figures out what goes where without you having to remember anything.
Plus the weird exceptions required for backwards compatibility, and the global namespace: I often forget where a root \ is required and where it isn't (not when declaring a namespace, but often--not always!--when referencing one). And of course there's the monstrous choice of namespace separator.
End of the world? Not really. Sucks? Yeah. And possibly a dealbreaker for me for larger projects with complicated namespaces and lots of classes.
I'd love for this to be just a misunderstanding on my part, because it would make my life a lot easier if PHP namespaces where more like C# ones!
Your PHP example is possible to write in a way that is nearly identical to the C# you provided. Why are you prefixing Namespace\MyClass(); when you declared your namespace scope in 'use \My\Namespace'? Your assignment can just be:
$var = new MyClass();
This brings it pretty much in line with your C# example. Have you read the PHP docs on namespaces?
I was taken aback when I tested this for myself as my initial reading of the PHP docs lead me to a very different conclusion. You are indeed correct, and in my opinion that is very broken. Touché.
Why? Web Applications and Web Servers are two very different things with different language requirements. Seems sensible to pick the strongest languages with which to build the whole package.
I guess you don't push web servers. They're "apps", not system software. Anybody who deploys non-trivial web-apps knows this. Per-app web servers, standing behind a proxy, with a shared session-db is the most ideal way to get things done.
At this point in the game, Apache-class servers are glorified proxies, and occasionally dole out static data when you're not using a CDN.
I have customized my web server so much, I would've had to wait for years to see the changes in Apache, nginx or lighty, if ever.
I don't really see how this would help. Thats what FastCGI is for. You would have to be dumb to expose a php internal HTTP server to the world, and configuring a FastCGI backend is no harder than setting up a HTTP backend in apache/nigix/whatever. If its just for testing, most apache installs come with PHP by default, its just another command to learn.
The idea isn't to open the server to the world. The RFC states that it's meant to be used in a similar way to django's manage.py runserver, for development and internal testing.
Django phrase it in their tutorial as:
"We've included this with Django so you can develop things rapidly, without having to deal with configuring a production server -- such as Apache -- until you're ready for production.
Now's a good time to note: DON'T use this server in anything resembling a production environment. It's intended only for use while developing. (We're in the business of making Web frameworks, not Web servers.)"
As long as the PHP documentation includes similar caveats and guidance, an HTTP server isn't a bad thing.
Yeah, the first thing I thought of when reading this was Ruby's WEBrick and how it's used in Rails to provide an out-of-the-box local development server.
Don't see how that would be a bad thing. Something simpler and quicker than installing XAMPP or configuring the webserver that comes with your OS/distro.
PHP FPM is nice and all, but the issue still is that it is a FastCGI server, so you need something that can route to it. This php -S proposal doesn't have that requirement.
That's not exactly true. You still need an HTTP server to proxy to the FastCGI back-end. This could be useful for a number of things outside of local development instances. One could avoid having to setup Apache/nginx/whatever to pick up the HTTP request from a reverse proxy and instead just spin up PHP on its own.
Seems like the built in server would be most useful for newbies to get an application running. Think if how much easier it is to get a basic Rails app running to start learning compared to configuring Apache and PHP together.
It isn't too hard for someone who is already familiar Apache. On OS X, mod_php is not enabled by default, requiring new users to dig in and learn about apache config files and document roots. I'm not saying it is difficult, and it is obviously important to learn, but it would be nice to be able to have a 1 page "get started with PHP" tutorial.
Having webrick out of the box was awesome when I first started using Rails. The big difference, however, is that Rails includes a web server because Rails is a framework for developing web applications, while this proposal seems to want a web server included as part of the PHP distributable. PHP isn't exclusively used for web applications, so I don't think it makes too much sense IMO.
Any idiot can write a snarky comment about PHP. Very few get to write code that has anywhere near the impact it had.