| |||||||||||||
PHP 5.4.0 releasedPHP 5.4.0 releasedPosted Mar 2, 2012 18:08 UTC (Fri) by jmalcolm (guest, #8876)In reply to: PHP 5.4.0 released by rfunk Parent article: PHP 5.4.0 released
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".
(Log in to post comments)
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.
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.
|
|||||||||||||