> So what language is actually better suited for the job that PHP is used for all the time
I am not here to bash PHP although it might come off a bit like that. I have two answers depending on context:
1) If we mean, "better" at creating "professional" server-side web applications
Depending on your definition of "professional", the answer would be pretty much any other language commonly used on the web. This would include Ruby, Python, Java, C# and others. I think that the reason most people deride PHP is because it's natural style and internal inconsistency does not meet their definition of "professional".
2) If we mean, "better" at cranking out dynamic web pages with a minimum of theory, infrastructure, ceremony, and magic then PHP stands almost alone (which is probably your point). It is worth pointing out though that the primary reason for this is because almost everybody else has abandoned the inline script style of web development. For example, both ASP (Microsoft) and JSP (Sun) are years behind us but both were very PHP-like.
If I remember correctly, Microsoft Web Pages (their Web Matrix intro environment) is a lot like PHP but without so many of it's warts. Also, you can at least mature in that environment to a full ASP.NET MVC paradigm with reasonable continuity. You can do it on Mono as well if you want Open Source. That statement might cause a flame war so I will just point out that Microsoft themselves use Mono in a few places (including tryfsharp.org and some apps/games in the iPhone App Store as examples).
Of course, the PHP community is quite diverse and there are, for example, MVC frameworks available for PHP. At that point though, the uniqueness of PHP goes away. Other than already knowing PHP, I am not sure I see the advantages of a PHP MVC framework over choosing something else.
Posted Mar 2, 2012 17:24 UTC (Fri) by rfunk (subscriber, #4054)
[Link]
The big advantages of PHP are its ubiquity on servers (where we don't always get to dictate what's there), ease of deployment, and ease of finding someone who knows it. (Though most of those people aren't actually very good at it.)
It's easy to find languages that are better at any other attribute you could name, but those two or three are the reasons PHP is still used, even by those who dislike it.
PHP 5.4.0 released
Posted Mar 2, 2012 17:44 UTC (Fri) by niner (subscriber, #26151)
[Link]
So in short: PHP is used because PHP is used. Jay network effects! Keeping garbage technology alive for decades...
PHP 5.4.0 released
Posted Mar 2, 2012 18:08 UTC (Fri) by jmalcolm (guest, #8876)
[Link]
Hosting gets mentioned lot and it was true at one point. Honestly though, that statement is no longer true as far as I can tell. It may be that there are hosts that only support PHP but it is certainly easy to find good quality hosts at any price point that support lots of other stuff as well. Ruby, Python, Perl, ASP.NET and others are all pretty common even on $7/month plans.
If you pick a host at random, I expect that they will support ASP.NET at the same price points as PHP.
"Finding someone who knows it" is an interesting one. Skills in other languages are not exactly rare but I imagine that it is probably true that there are more people exposed to PHP. If we change the task to finding somebody "who knows what they are doing", it could be argued that it is no easier to find this in PHP-land than elsewhere. In fact, the task may even be easier for other languages.
Deployment is also interesting; I could say a lot about it but I will give you that one. Well, I will say that if you find a dev "that knows what they are doing" it pretty much becomes a non-issue. One of the things that many people (that I have known) really love about PHP is the ability to edit in-place in production. That is of course really nice and completely horrifying at the same time.
PHP obviously fills a need as it keeps on going strong. One might expect a competitor to emerge that addresses PHPs warts while offering it's attractive characteristics. I think that your three issues ("broad exposure, ubiquitous hosting, and no-fuss deployment) are big factors. If I create a "better PHP than PHP" I will not attract many Node.js, Rails, or ASP.NET developers. Sadly, the lack of millions of tutorials and hosts for my "better" platform will keep the would-be PHP devs away too.
PHP keeps evolving though. With the addition of traits it has something many languages lack (including C#). The need to stay compatible holds the language back but someday (far from now) there may be a subset of PHP which is nice. Keep your eyes peeled for the book "PHP: The Good Parts".
PHP 5.4.0 released
Posted Mar 3, 2012 0:23 UTC (Sat) by rfunk (subscriber, #4054)
[Link]
Who among us wants to do ASP.NET? :-)
Part of hosting is in the corporate world, where things are slow to change. One major client I work with gives the option of Java or PHP for hosting -- and until recently that was only PHP 5.2.
And that leads into the deployment issue, where PHP is really the only major platform where an Apache module is a viable option. (Yes, mod_perl and mod_python exist; the former is painful in my experience, and I never hear about anyone using the latter. Then again I've never been a Python guy, and I find most Perl work painful anymore.) Everything else either uses CGI (slow), or uses a separate application server architecture, with inherent complexity. With that sort of architecture, having someone who knows what they're doing is necessary, but that doesn't make all the pain go away.
I'll be interested to see if Node.js, or something like it, ends up going more toward the PHP-ish route, or more toward the Ruby/Rails-ish route. (Ruby and Rails are already more on the Java path.)
I definitely like the "Good Parts" idea for PHP... except that the book already exists. http://shop.oreilly.com/product/9780596804381.do
It's not nearly what the Javascript original was though.
PHP 5.4.0 released
Posted Mar 3, 2012 7:47 UTC (Sat) by Cato (subscriber, #7643)
[Link]
If you want some degree of security, you need to use CGI not mod_php on any host with more than one application owner, e.g. shared web hosting. And CGI is slow, so it's better to use FastCGI (i.e. separate PHP server to web server) so your web app can run as the right userid yet not pay the CGI startup overhead. This is essential for more complex apps or higher volume websites, which also tend to require some security.
I believe Ruby and Python are often deployed in the same way.
PHP 5.4.0 released
Posted Mar 3, 2012 14:50 UTC (Sat) by rfunk (subscriber, #4054)
[Link]
PHP-FPM is a much better solution than fastcgi if you need that sort of thing; people who are running Apache (and therefore don't have huge traffic issues) generally don't though. For shared hosting, suPHP improves security greatly by running as the user who owns the file. (However, I haven't really paid much attention to shared hosting myself.)
I can't speak for Python, but the Ruby world abandoned fastcgi years ago because of its many problems, in favor of Java-style middleware layers.
PHP 5.4.0 released
Posted Mar 3, 2012 15:28 UTC (Sat) by Cato (subscriber, #7643)
[Link]
Actually PHP-FPM is a FastCGI implementation, with the F standing for FastCGI: http://php-fpm.org/
suPHP is similar to suexec and often used with CGI but that doesn't change my point that mod_php is not used on shared hosting (or at least responsible shared hosting).
On Python and Ruby, I just meant the principle of having a persistent interpreter process running outside the web server, not FastCGI specifically.
PHP 5.4.0 released
Posted Mar 3, 2012 15:47 UTC (Sat) by rfunk (subscriber, #4054)
[Link]
Ah, sorry, I was actually thinking of suexec when I said suPHP. Either way, I'm not very much concerned with shared hosting.
I see a big difference between fastcgi and using an application server, possibly because I remember the pain of using fastcgi with Ruby, and the major differences when I set up an application server instead.
PHP 5.4.0 released
Posted Mar 5, 2012 8:39 UTC (Mon) by colo (subscriber, #45564)
[Link]
Not necessarily true; using Apache's mpm-itk, you can achieve the same level of security/privilege separation that you have with (f)cgi and suexec with e. g. mod_php as well.
PHP 5.4.0 released
Posted Mar 5, 2012 8:50 UTC (Mon) by anselm (subscriber, #2796)
[Link]
Privilege separation isn't the only advantage of setups like FastCGI or WSGI that keep the language interpreter separate from the web server. Another advantage is that you get to proxy only those requests to the language interpreter that actually need it, while requests for, say, small static image files don't occupy expensive language-interpreter-containing Apache processes. This is probably the #1 thing you can do to speed up dynamic web sites.
There are of course other ways of achieving this – e.g., by putting a more lightweight web server in front of your Apache/mod_php to serve any static content and have that server proxy only the PHP stuff to the actual Apache, or by serving static content from a different server altogether –, but mpm-itk isn't one of them.
PHP 5.4.0 released
Posted Mar 3, 2012 16:47 UTC (Sat) by jmalcolm (guest, #8876)
[Link]
Thanks for pointing out "PHP: The Good Parts". I should have done a search before making that comment.
Is it worth a read? I do not do much PHP but I am curious what that book would have to say.
PHP 5.4.0 released
Posted Mar 5, 2012 8:04 UTC (Mon) by cmccabe (guest, #60281)
[Link]
> Thanks for pointing out "PHP: The Good Parts". I should have done a
> search before making that comment.
>
> Is it worth a read? I do not do much PHP but I am curious what that
> book would have to say.
Unfortunately, all the pages in the book are blank, for obvious reasons.
Ok, ok, sorry. I couldn't resist.
PHP: The Good Parts
Posted Mar 5, 2012 21:30 UTC (Mon) by rfunk (subscriber, #4054)
[Link]
I have the book (or I thought I did, though so far I've only found my epub file), but haven't spent much time with it. It starts off with PHP basics, and I'm familiar enough with PHP that I wasn't motivated to dig further at the time.
PHP 5.4.0 released
Posted Mar 3, 2012 20:28 UTC (Sat) by jmalcolm (guest, #8876)
[Link]
> Who among us wants to do ASP.NET? :-)
> PHP is really the only major platform where an Apache module is a viable option
I think that mod_mono makes ASP.NET quite viable on Apache. So, I guess that would be one reason. Technically, mod_mono invokes mod-mono-server so I guess it means what you mean by "application server". As far as complexity goes, it is just a couple of lines in your httpd.conf (or a .conf that httpd.conf refers to).
I need to get off the Mono advocacy stage though. This is a PHP thread.
PHP 5.4.0 released
Posted Mar 2, 2012 21:40 UTC (Fri) by Kit (guest, #55925)
[Link]
> 2) If we mean, "better" at cranking out dynamic web pages with a minimum
> of theory, infrastructure, ceremony, and magic then PHP stands almost
> alone (which is probably your point).
This is exactly what I was getting it. PHP is nice because you can just sprinkle a little bit on some raw (already existing!) HTML and then have some server-side magic on your website. I'm not talking about creating a web _app_, which seems to be the only thing anyone else considers a legitimate use case anymore.
I also see value in allowing non-developers to be able to do server-side processing on websites, without having to spend an inordinate amount of time learning largely superfluous concepts for their actual needs. PHP has never seemed amazing in that regard, due to some simple ways to shoot yourself in the foot (Remote File Inclusion being the biggest IMO)... but, it seems that there's no other language that even tries. It seems everything else targets either very low, or very high, with nothing much really even coming close to that middle ground.
PHP 5.4.0 released
Posted Mar 8, 2012 22:19 UTC (Thu) by HelloWorld (guest, #56129)
[Link]
> This is exactly what I was getting it. PHP is nice because you can just sprinkle a little bit on some raw (already existing!) HTML and then have some server-side magic on your website.
Pretty much any language can do that. There's HTML::Mason for Perl, Spyce for Python, eRuby for Ruby etc.. People just keep making up fairy tales about how PHP is so much easier than the alternatives, but it's simply not true.