The whole "start up a little webserver in the same language" trend makes everything much* easier to develop.
Where PHP still has an edge is deployment for non-development. If you just want to drop in some software and use it on the web (e.g. a bulletin board), PHP is still easier in many cases for novice users. But that's not development, it's just deployment.
I would even hazard that correct deployment of that software in a secure way is made harder by PHP's ease of deployment, as you have to rely on permissions in lieu of separate locations that have no remote read access, as many frameworks implement.
I actually agree, but that's not the approach that's pushed. In python the "tiny http server" is explicitly advertised as insecure and unsuited to production use. In Java, embedding Jetty involves dozens of arcane lines and manually translating suggested XML files into code - not something a beginner can do. What other language than PHP can I dump a single file on a shared host and have it be running?
(Ironically Java is actually a legitimate answer here, if the shared host ran an application server like Tomcat and accepted .war uploads. But I don't think I've ever seen a shared host that offered that?)
Sure, but we're talking about developing, and that's a pretty easy way to get started.
In Python, don't you have Gunicorn, Tornado and Twisted?
In Perl there's Mojolicious and Dancer.
Ruby has Rails, Sinatra and probably a least a few more.
Java... Well, IMO Java has a habit if either not delivering simple smaller projects, or communicating they exist very poorly (but I'm not really in the loop so my opinion may be very uninformed). Tomcat was too big and complex to fit this need a decade ago, so I doubt it does it well now (but maybe I'm wrong?).
> What other language than PHP can I dump a single file on a shared host and have it be running?
My point is that needing a shared host to get started is actually a step you often don't have to wait for now. If you're a developer, it's easier to just start up your dev locally and work out hosting in a bit.
If you're developing something beyond the simplest things, the host allowing drop in scripts is not actually a problem I think. For anything that's super quick and dirty, you still have CGI.
That's the point I was making. The drop in script support isn't really all that beneficial to PHP developers, but it is very beneficial to regular user that just was to deploy a PHP webapp of some sort, such as a bulletin board or blog software.
> My point is that needing a shared host to get started is actually a step you often don't have to wait for now. If you're a developer, it's easier to just start up your dev locally and work out hosting in a bit.
I have to disagree. It's silly to try to develop something you can't actually run. Getting your software in front of actual users is the critical path; everything else is secondary. (And exposing your dev laptop as a web host on the internet is pretty complex in practice for most people, quite aside from whether it's a good idea)
> For anything that's super quick and dirty, you still have CGI.
Do any of the frameworks you listed (Gunicorn or Mojolicious or Rails or...) support running as CGI? Is it documented in their tutorials?
It's trivial to run. Get a minimal AWS instance, or a small digitalocean instance, or whatever. Hosting is not a problem these days. Godaddy is offering managed (they patch and provide support) VPS instances for $18/mo right now. Surely not as cheap as some dedicated host, but also more secure and if you're actually spending your time developing something, not a lot to pay.
Nobody is saying expose your laptop to the internet. But getting started isn't about getting someone to look at your stuff, it's about actually getting started and getting some code written.
> Do any of the frameworks you listed (Gunicorn or Mojolicious or Rails or...) support running as CGI? Is it documented in their tutorials?
When you control the webserver running a subprogram as CGI (which is what I was referring to) is trivial, and can be handled in a few lines of code.
If you're talking about whether the framework has instructions on how to run as a CGI, I'm going to go out on a limb and say yes, they all do because that's step one in telling people how to run your stuff when making a framework, where it makes sense. In some cases it's just a WSGI/PSGI etc server and you can interchange them. It may not make sense to run twisted as a CGI, but if you write WSGI you can just use django, which does support deployment as a CGI. Mojolicious and Dancer support it. I'm pretty sure Rails and Sinatra do in some way to.
These trivial things matter when you're getting off the ground. Dropping money on that idea you were playing with in your evenings is a big psychological step. A couple of hours faffing with server admin can be even more offputting.
> Nobody is saying expose your laptop to the internet. But getting started isn't about getting someone to look at your stuff, it's about actually getting started and getting some code written.
Disagree. The goal isn't to write some code, the goal is to get a viable business, and these days business concerns - the famous product-market fit - are a much bigger risk factor than technical ones. A mostly-static page with a simple text form that can start getting you actual customers puts you much closer to that than any amount of code running on your dev laptop. (It's different when technical innovation is at the core of the business - when the actual code is the biggest risk factor - but in that case you're probably not doing web stuff and probably not using any of these languages).
> If you're talking about whether the framework has instructions on how to run as a CGI, I'm going to go out on a limb and say yes, they all do because that's step one in telling people how to run your stuff when making a framework, where it makes sense. In some cases it's just a WSGI/PSGI etc server and you can interchange them. It may not make sense to run twisted as a CGI, but if you write WSGI you can just use django, which does support deployment as a CGI.
It's never "just" though; these differences are important. Every extra step beyond "upload this file to the host" probably cuts the number of projects that get off the ground in half. And a lot of these frameworks will tell you how to "run" them in a one-off way but completely gloss over how to set them up so that they'll still be running after you restart the server you're hosting on.
I just had a quick look through the django tutorials to check I wasn't talking nonsense and it's even worse than I thought. The "installing" page gestures vaguely in the direction of virtualenv (which is how people actually use django in practice) but it's not integrated in the tutorial at all. The 7-page "beginner tutorial" only ever uses the officially-not-secure-enough-for-production local development server. I was excited by the link to an "advanced tutorial about creating reusable apps", but turns out that's just telling you how to package up your webapp so that other people can run it locally with the development server. Nothing about WSGI, not one word about how to actually put your "webapps" on the web. I don't mean this as an attack on django specifically - I like django, and it's documentation and tutorials are better than a lot of options - but no wonder people keep using PHP.
php has builtin webserver since 5.4. that's like 5-6 years ago
Telling potential users to spin up a VPS or type some command line instructions to install code is too complicated for many users, even though it may seem trivially easy to a developer.