23 ms·

It's always pleasant to see PHP occasionally get a positive moment in the limelight on HN. It's oft scorned yet powers a very large chunk of the web. With the w

by donatj 10y ago

It's always pleasant to see PHP occasionally get a positive moment in the limelight on HN. It's oft scorned yet powers a very large chunk of the web. With the work done on 7 it's also one of the fastest scripting languages around and deserves a little more credit if I'm honest.

hliyan 10y ago
I wholeheartedly agree. I've seen many cases of PHP being scorned in favour of Node.js in problem domains where PHP is a clear fit (I've been guilty of this myself). It's not at all a bad language in the hands the right person.
- Dibes 10y ago
  out of pure ignorance -- what are the correct domains that either fit into?
  - mschuster91 10y ago
    nodejs is imho best suited for two groups of tasks: 1) APIs/programs relying on high concurrency and parallelism, especially where the handler(s) have to wait a lot for stuff like DB accesses 2) streaming (in the sense of websockets servers), PHP iirc can't even be used as a websocket server 3) Any API that can be implemented without needing too many async calls - you'll end up in callback hell or promise hell otherwise PHP on the other hand has other use cases: 1) stuff that needs to be massively and easily deployed - you can grab PHP/MySQL/Apache hosting everywhere for either dead cheap or totally free. Examples include Wordpress, Drupal and MediaWiki 2) stuff that is highly complex in its flow. If your API requires dozens of DB calls, filesystem access, networking or just involves thousands of SLOC, you're better off writing it in PHP as it (since PHP5) carries a solid OOP stack - and even if you're not writing OOP code, being able to write program flows without dozens of promises is a breeze. 3) stuff that requires weird extensions to PHP. Basically there are bindings for everything and it's trivial to write your own binding to a library if it does not exist yet. For example, I have used PC/SC to interface with crypto smartcards, and it works surprisingly well. 4) shell scripts. PHP interpreters are widespread - OS X includes PHP by default and it's a $package_manager install php away on most Linux distributions. Perl and bash have their own strengths but honestly, Perl is outdated and PHP abstracts a load of stuff away, so you can write shellscripts that work on all major platforms without having to account for stuff like "does the OS have GNU grep, busybox grep or BSD grep".
    - geon 10y ago
      > PHP iirc can't even be used as a websocket server True, if you run it behind a web server like 99.999% of all users. If you run it as a cli script, you can implement pretty much anything. I saw a ftp server once. Crazy. Still, even on a normal web server, php can do long polling perfectly fine, which is often enough. > being able to write program flows without dozens of promises is a breeze It is a breeze with async/await too.
      - LinuxFreedom 10y ago
        what would be a good hardware spec and server configuration to have 5000 users do long polling with a php backend?
        geon 10y ago
        If you care about performance and traffic, perhaps php isn't where you should start anyway.
        mschuster91 10y ago
        Uh. You do realize that Mediawiki, powering nearly all wiki systems including Wikipedia, is written in PHP. Or Facebook, they were able to go with PHP for iirc 500 M users? PHP is in any case a better choice, performance-wise, than Python or, god forbid, Java.
        cutler 10y ago
        PHP performs better than Java? Care to offer evidence?
        mschuster91 10y ago
        Can't disclose much in public, but our PHP CMS hosting requirements tend to be waaaay cheaper than our Java-based CMSes. Also, deployment of PHP apps is (in my experience) faster and easier.
  - tannhaeuser 10y ago
    PHP started out as a language you could embed into otherwise static HTML via SGML processing instructions. While useful, the problem was (and still is) that embedded PHP templating operates at the string level and has absolutely no concept of HTML-awareness so can't escape the strings it injects into HTML - it's trivially easy to build a PHP app taking user input where the user sends malicious <script> tags and PHP placing it happily into generated HTML (eg. XSS attacks). PHP apps typically also build up dynamic SQL from user input by string concatenation, which has resulted in uncountable SQL injection attacks. PHP apps and frameworks like WordPress and Drupal initially have worked around these limitations by using ad-hoc measures, then grew into meta site template engines and generators themselves, resulting in code bases without much architectural oversight. These dangerous properties, and PHP's really bad standard library, in combination with PHP being used as a beginner language for web sites, have resulted in PHP's bad reputation. Since experienced developers have avoided it, PHP also has a bad presence at StackOverflow, which contains thousands of low quality answers answers to PHP questions. On the plus side, PHP really owns managed hosting. You can install WP etc. via "panels" even without any admin experience and go from there by installing a mess of "plugins" and "themes" (which, due to lack of modularity, can do all kind of things to your site). Node.js generally requires your own VM (there is no managed hosting) and due to it being run in a single process (or process cluster) generally requires that you know what you're doing so that a single error doesn't bring down your whole site. Its attractiveness comes from the fact that you can use JavaScript both server- and client-side (unlike PHP which runs server-side only). While Node.js has the edge in web apps, the options for content-driven sites are limited on Node.js; there's nothing like WP or Drupal for Node.js, and some say Node.js also lacks a canonical framework for rapid creation of database-driven web apps such as Rails or Django.
    - sbarre 10y ago
      > While useful, the problem was (and still is) that embedded PHP templating operates at the string level and has absolutely no concept of HTML-awareness so can't escape the strings it injects into HTML - it's trivially easy to build a PHP app taking user input where the user sends malicious <script> tags and PHP placing it happily into generated HTML (eg. XSS attacks). > PHP apps typically also build up dynamic SQL from user input by string concatenation, which has resulted in uncountable SQL injection attacks. You can make these beginner mistakes in any language that outputs HTML to the browser, and accepts user input via the browser. I'm not specifically defending PHP here, but I hope you're not implying that these problems don't exist in Ruby, Python, Java or even Node for that matter... The issues you are describing are unsafe coding practices and have nothing specifically to do with how PHP works, and it's "trivially easy" to make those mistakes in almost all web programming languages. It's also not true that PHP "can't escape the strings it injects into HTML". There are standard library functions to do this (and have been for probably 10+ years, since the late PHP 4 days), as well as many well-tested community packages to do this at the framework or application level. Also your explanation of "plugins" and "themes" is a concept tied to applications such as Wordpress, Joomla, and other CMS products (and again are not concepts specific to PHP). It's certainly true that PHP's low barrier to entry has led to many badly coded websites getting onto the Internet, but I think it's ignorant to claim that PHP can't be used correctly and safely to develop web applications, or that most of the problems you describe are not easily avoidable. All languages and frameworks have their pros and cons, and their caveats, but it helps no one when people spread FUD and outdated (or straight-up false) facts about web development. Whether you code in it or not, you should probably refresh your knowledge of the PHP language and ecosystem if you're going to make public statements about how it works and what it can and can't do.
  - matsemann 10y ago
    One thing I like about PHP for quick prototyping or one-off projects is that an error doesn't bring the whole server down. For instance, I held a workshop where I hosted a server the students were to do some requests to. I had written a simple Node application that read the json they sent and returned a result. What I didn't anticipate was that them sending malformed json would bring the whole server down. So then I had to add error handling and stuff. Of course one should normally do that, but in PHP the malformed requests would just fail, leaving other requests unharmed, which would be acceptable for this kind of project.
    - bpicolo 10y ago
      Every web framework out there (express + nodejs included) will handle exceptions properly and not blow up the server on exception.
      - matsemann 10y ago
        You're not refusing my point by insisting on adding more complexity (a huge framework), when simplicity and rapid prototyping of a small script was the goal. This question is what I mean, extra stuff one has to keep in mind: http://stackoverflow.com/q/5999373/923847 http://stackoverflow.com/q/5999373/923847 Does it matter for a real project? Probably not, just some boilerplate. Does it matter when I want something quick up and running? Yes.
        bpicolo 10y ago
        > a huge framework I contest the idea that sinatra-style frameworks are "huge". Python + flask is about as low-overhead as one can get. No need to set up any extra (apache || nginx). PHP's model of "just chug along returning null" by disabling most relevant errors is a massive antipattern in production code.
        innocenat 10y ago
        PHP has lower overhead still. You don't need to import, explicitly define route, etc. PHP Built-in dev server doesn't require anything extra either.
aphextron 10y ago
It has come a long way. My last job was at a big PHP shop, which had a heavy focus on doing PHP The Right Way. The result was a fairly decent, maintainable codebase. I came to really appreciate the flexibility and ability to just "make things work" that PHP has, while finally having a proper development environment with real dependency management and IDE support.
- david-given 10y ago
  Do you have any pointers to the recommended Right Way to do modern PHP? I'd be interested to explore it; I have a number of places where I want to add tiny bits of interactivity to otherwise static web pages, and this totally seems to be what PHP does best.
  - jdpedrie 10y ago
    http://www.phptherightway.com/ http://www.phptherightway.com/
  - Mahn 10y ago
    http://phptherightway.com http://phptherightway.com is a good place to start, if you haven't read it before. It's opinionated, and not necessarily a guide follow down to the letter, but it can put you on the right track.
    - david-given 10y ago
      Ha ha --- I should have thought to search for that! It seems to be a bit light on advice in places. e.g. the section on comparison operators lightly mentions the difference between == and === but doesn't say anything about when they should be used. As that's one of the traditional PHP gotchas I would have expected more there. Anyway, thanks; I'll check it out.
  - matthewn 10y ago
    O'Reilly's "Modern PHP" (270 pages) is a fantastic introduction to the new way of doing PHP.
deleted 10y ago
[deleted]
kyriakos 10y ago
PHP does not deserve most of the negativity it receives. It matured a lot recently and even though there are many alternatives tha probably can do better under some scenarios php still does what it does very well.
- jpalomaki 10y ago
  It is also quite interesting the PHP introduced many (or at least some of us) to the ideas of server-less computing already 20 years ago. That's how I got started. I paid some small money for local ISP and got in exchange FTP user account and account on their shared MySQL Server. I would write my code and deploy via FTP. I believe some companies ran a cluster of servers, providing cloud like scalability for these deployments.
  - viraptor 10y ago
    That's not what the server-less idea is about. You're describing a standard shared hosting.
    - _wmd 10y ago
      You're in software land, what is old is always new again. Try to dance around with the Wikipedia definition for serverless and get back to us when you've found a way to exclude the majority of old-style PHP hosting environments from it: > Serverless computing, also known as function as a service (FaaS), is a cloud computing code execution model in which the cloud provider fully manages starting and stopping of a function's container platform as a service (PaaS) as necessary to serve requests, and requests are billed by an abstract measure of the resources required to satisfy the request, rather than per virtual machine, per hour.[1] > Despite the name, it does not actually involve running code without servers.[1] The name "serverless computing" is used because the business or person that owns the system does not have to purchase, rent or provision servers or virtual machines for the back-end code to run on. For example, nearlyfreespeech.net neatly fits even the pay-for-what-you-use billing definition here
      - 10y ago
agumonkey 10y ago
Gotta admit that since the PHP ~6 days they made more than impressive efforts in many domains.
- innocenat 10y ago
  There weren't PHP6 though.
  - agumonkey 10y ago
    hence the ~ IIRC it's after that time that PHP saw very important changes vm and language.
    - jerryszczerry 10y ago
      > PHP ~6 Ah, you mean good old PHP 4294967289?
malza 10y ago
Honestly. I think its main problem is it's not hipster enough. It's too popular. I bet if you made it difficult to use (for most people), added features that make certain aspects a nightmare to scale and gave it a weird name then it would do well here. Obviously don't let anyone know about the origin... say you built it at a series of obscure coding bootcamps.
- amiga-workbench 10y ago
  You hit the nail right on the head there. Some of the nightmarish build configurations to get some Javascript projects going are just beyond belief.
  - nilliams 10y ago
    It's unfortunate if you've encountered that because there's really no good reason for it. Thankfully now however most/all major JS frameworks & libs are moving to/have moved to 'zero configuration' cli tools (ember-cli, create-react-app, angular-cli, ...).
- simias 10y ago
  I think that's unfair, the reason PHP has a bad reputation is not because of silly hipsters. It's because for a long time it was a terribly designed language. It was a laughing stock for a good reason. The whole "hobby-grade templating language turned general purpose with complete disregard to how programing languages are designed" thing. Now I'm willing to believe that it's improved a lot since then, but it's got a very bad reputation to overcome, and it's deserved. The languages seems headed in the right direction at least, maybe in a few years we'll forget what PHP used to be.
  - drspacemonkey 10y ago
    I'm pretty sure a substantial part of PHP's reputation is the nightmare code produced by PHP developers.
    - 10y ago

by donatj 10y ago

hliyan 10y ago

I wholeheartedly agree. I've seen many cases of PHP being scorned in favour of Node.js in problem domains where PHP is a clear fit (I've been guilty of this myself). It's not at all a bad language in the hands the right person.

Dibes 10y ago
out of pure ignorance -- what are the correct domains that either fit into?
- mschuster91 10y ago
  nodejs is imho best suited for two groups of tasks: 1) APIs/programs relying on high concurrency and parallelism, especially where the handler(s) have to wait a lot for stuff like DB accesses 2) streaming (in the sense of websockets servers), PHP iirc can't even be used as a websocket server 3) Any API that can be implemented without needing too many async calls - you'll end up in callback hell or promise hell otherwise PHP on the other hand has other use cases: 1) stuff that needs to be massively and easily deployed - you can grab PHP/MySQL/Apache hosting everywhere for either dead cheap or totally free. Examples include Wordpress, Drupal and MediaWiki 2) stuff that is highly complex in its flow. If your API requires dozens of DB calls, filesystem access, networking or just involves thousands of SLOC, you're better off writing it in PHP as it (since PHP5) carries a solid OOP stack - and even if you're not writing OOP code, being able to write program flows without dozens of promises is a breeze. 3) stuff that requires weird extensions to PHP. Basically there are bindings for everything and it's trivial to write your own binding to a library if it does not exist yet. For example, I have used PC/SC to interface with crypto smartcards, and it works surprisingly well. 4) shell scripts. PHP interpreters are widespread - OS X includes PHP by default and it's a $package_manager install php away on most Linux distributions. Perl and bash have their own strengths but honestly, Perl is outdated and PHP abstracts a load of stuff away, so you can write shellscripts that work on all major platforms without having to account for stuff like "does the OS have GNU grep, busybox grep or BSD grep".
  - geon 10y ago
    > PHP iirc can't even be used as a websocket server True, if you run it behind a web server like 99.999% of all users. If you run it as a cli script, you can implement pretty much anything. I saw a ftp server once. Crazy. Still, even on a normal web server, php can do long polling perfectly fine, which is often enough. > being able to write program flows without dozens of promises is a breeze It is a breeze with async/await too.
    - LinuxFreedom 10y ago
      what would be a good hardware spec and server configuration to have 5000 users do long polling with a php backend?
      - geon 10y ago
        If you care about performance and traffic, perhaps php isn't where you should start anyway.
        mschuster91 10y ago
        Uh. You do realize that Mediawiki, powering nearly all wiki systems including Wikipedia, is written in PHP. Or Facebook, they were able to go with PHP for iirc 500 M users? PHP is in any case a better choice, performance-wise, than Python or, god forbid, Java.
        cutler 10y ago
        PHP performs better than Java? Care to offer evidence?
        mschuster91 10y ago
        Can't disclose much in public, but our PHP CMS hosting requirements tend to be waaaay cheaper than our Java-based CMSes. Also, deployment of PHP apps is (in my experience) faster and easier.
- tannhaeuser 10y ago
  PHP started out as a language you could embed into otherwise static HTML via SGML processing instructions. While useful, the problem was (and still is) that embedded PHP templating operates at the string level and has absolutely no concept of HTML-awareness so can't escape the strings it injects into HTML - it's trivially easy to build a PHP app taking user input where the user sends malicious <script> tags and PHP placing it happily into generated HTML (eg. XSS attacks). PHP apps typically also build up dynamic SQL from user input by string concatenation, which has resulted in uncountable SQL injection attacks. PHP apps and frameworks like WordPress and Drupal initially have worked around these limitations by using ad-hoc measures, then grew into meta site template engines and generators themselves, resulting in code bases without much architectural oversight. These dangerous properties, and PHP's really bad standard library, in combination with PHP being used as a beginner language for web sites, have resulted in PHP's bad reputation. Since experienced developers have avoided it, PHP also has a bad presence at StackOverflow, which contains thousands of low quality answers answers to PHP questions. On the plus side, PHP really owns managed hosting. You can install WP etc. via "panels" even without any admin experience and go from there by installing a mess of "plugins" and "themes" (which, due to lack of modularity, can do all kind of things to your site). Node.js generally requires your own VM (there is no managed hosting) and due to it being run in a single process (or process cluster) generally requires that you know what you're doing so that a single error doesn't bring down your whole site. Its attractiveness comes from the fact that you can use JavaScript both server- and client-side (unlike PHP which runs server-side only). While Node.js has the edge in web apps, the options for content-driven sites are limited on Node.js; there's nothing like WP or Drupal for Node.js, and some say Node.js also lacks a canonical framework for rapid creation of database-driven web apps such as Rails or Django.
  - sbarre 10y ago
    > While useful, the problem was (and still is) that embedded PHP templating operates at the string level and has absolutely no concept of HTML-awareness so can't escape the strings it injects into HTML - it's trivially easy to build a PHP app taking user input where the user sends malicious <script> tags and PHP placing it happily into generated HTML (eg. XSS attacks). > PHP apps typically also build up dynamic SQL from user input by string concatenation, which has resulted in uncountable SQL injection attacks. You can make these beginner mistakes in any language that outputs HTML to the browser, and accepts user input via the browser. I'm not specifically defending PHP here, but I hope you're not implying that these problems don't exist in Ruby, Python, Java or even Node for that matter... The issues you are describing are unsafe coding practices and have nothing specifically to do with how PHP works, and it's "trivially easy" to make those mistakes in almost all web programming languages. It's also not true that PHP "can't escape the strings it injects into HTML". There are standard library functions to do this (and have been for probably 10+ years, since the late PHP 4 days), as well as many well-tested community packages to do this at the framework or application level. Also your explanation of "plugins" and "themes" is a concept tied to applications such as Wordpress, Joomla, and other CMS products (and again are not concepts specific to PHP). It's certainly true that PHP's low barrier to entry has led to many badly coded websites getting onto the Internet, but I think it's ignorant to claim that PHP can't be used correctly and safely to develop web applications, or that most of the problems you describe are not easily avoidable. All languages and frameworks have their pros and cons, and their caveats, but it helps no one when people spread FUD and outdated (or straight-up false) facts about web development. Whether you code in it or not, you should probably refresh your knowledge of the PHP language and ecosystem if you're going to make public statements about how it works and what it can and can't do.
- matsemann 10y ago
  One thing I like about PHP for quick prototyping or one-off projects is that an error doesn't bring the whole server down. For instance, I held a workshop where I hosted a server the students were to do some requests to. I had written a simple Node application that read the json they sent and returned a result. What I didn't anticipate was that them sending malformed json would bring the whole server down. So then I had to add error handling and stuff. Of course one should normally do that, but in PHP the malformed requests would just fail, leaving other requests unharmed, which would be acceptable for this kind of project.
  - bpicolo 10y ago
    Every web framework out there (express + nodejs included) will handle exceptions properly and not blow up the server on exception.
    - matsemann 10y ago
      You're not refusing my point by insisting on adding more complexity (a huge framework), when simplicity and rapid prototyping of a small script was the goal. This question is what I mean, extra stuff one has to keep in mind: http://stackoverflow.com/q/5999373/923847 http://stackoverflow.com/q/5999373/923847 Does it matter for a real project? Probably not, just some boilerplate. Does it matter when I want something quick up and running? Yes.
      - bpicolo 10y ago
        > a huge framework I contest the idea that sinatra-style frameworks are "huge". Python + flask is about as low-overhead as one can get. No need to set up any extra (apache || nginx). PHP's model of "just chug along returning null" by disabling most relevant errors is a massive antipattern in production code.
        innocenat 10y ago
        PHP has lower overhead still. You don't need to import, explicitly define route, etc. PHP Built-in dev server doesn't require anything extra either.

aphextron 10y ago

It has come a long way. My last job was at a big PHP shop, which had a heavy focus on doing PHP The Right Way. The result was a fairly decent, maintainable codebase. I came to really appreciate the flexibility and ability to just "make things work" that PHP has, while finally having a proper development environment with real dependency management and IDE support.

david-given 10y ago
Do you have any pointers to the recommended Right Way to do modern PHP? I'd be interested to explore it; I have a number of places where I want to add tiny bits of interactivity to otherwise static web pages, and this totally seems to be what PHP does best.
- jdpedrie 10y ago
  http://www.phptherightway.com/ http://www.phptherightway.com/
- Mahn 10y ago
  http://phptherightway.com http://phptherightway.com is a good place to start, if you haven't read it before. It's opinionated, and not necessarily a guide follow down to the letter, but it can put you on the right track.
  - david-given 10y ago
    Ha ha --- I should have thought to search for that! It seems to be a bit light on advice in places. e.g. the section on comparison operators lightly mentions the difference between == and === but doesn't say anything about when they should be used. As that's one of the traditional PHP gotchas I would have expected more there. Anyway, thanks; I'll check it out.
- matthewn 10y ago
  O'Reilly's "Modern PHP" (270 pages) is a fantastic introduction to the new way of doing PHP.

deleted 10y ago

[deleted]

kyriakos 10y ago

PHP does not deserve most of the negativity it receives. It matured a lot recently and even though there are many alternatives tha probably can do better under some scenarios php still does what it does very well.

jpalomaki 10y ago
It is also quite interesting the PHP introduced many (or at least some of us) to the ideas of server-less computing already 20 years ago. That's how I got started. I paid some small money for local ISP and got in exchange FTP user account and account on their shared MySQL Server. I would write my code and deploy via FTP. I believe some companies ran a cluster of servers, providing cloud like scalability for these deployments.
- viraptor 10y ago
  That's not what the server-less idea is about. You're describing a standard shared hosting.
  - _wmd 10y ago
    You're in software land, what is old is always new again. Try to dance around with the Wikipedia definition for serverless and get back to us when you've found a way to exclude the majority of old-style PHP hosting environments from it: > Serverless computing, also known as function as a service (FaaS), is a cloud computing code execution model in which the cloud provider fully manages starting and stopping of a function's container platform as a service (PaaS) as necessary to serve requests, and requests are billed by an abstract measure of the resources required to satisfy the request, rather than per virtual machine, per hour.[1] > Despite the name, it does not actually involve running code without servers.[1] The name "serverless computing" is used because the business or person that owns the system does not have to purchase, rent or provision servers or virtual machines for the back-end code to run on. For example, nearlyfreespeech.net neatly fits even the pay-for-what-you-use billing definition here
    - 10y ago

agumonkey 10y ago

Gotta admit that since the PHP ~6 days they made more than impressive efforts in many domains.

innocenat 10y ago
There weren't PHP6 though.
- agumonkey 10y ago
  hence the ~ IIRC it's after that time that PHP saw very important changes vm and language.
  - jerryszczerry 10y ago
    > PHP ~6 Ah, you mean good old PHP 4294967289?

malza 10y ago

Honestly. I think its main problem is it's not hipster enough. It's too popular. I bet if you made it difficult to use (for most people), added features that make certain aspects a nightmare to scale and gave it a weird name then it would do well here. Obviously don't let anyone know about the origin... say you built it at a series of obscure coding bootcamps.

amiga-workbench 10y ago
You hit the nail right on the head there. Some of the nightmarish build configurations to get some Javascript projects going are just beyond belief.
- nilliams 10y ago
  It's unfortunate if you've encountered that because there's really no good reason for it. Thankfully now however most/all major JS frameworks & libs are moving to/have moved to 'zero configuration' cli tools (ember-cli, create-react-app, angular-cli, ...).
simias 10y ago
I think that's unfair, the reason PHP has a bad reputation is not because of silly hipsters. It's because for a long time it was a terribly designed language. It was a laughing stock for a good reason. The whole "hobby-grade templating language turned general purpose with complete disregard to how programing languages are designed" thing. Now I'm willing to believe that it's improved a lot since then, but it's got a very bad reputation to overcome, and it's deserved. The languages seems headed in the right direction at least, maybe in a few years we'll forget what PHP used to be.
- drspacemonkey 10y ago
  I'm pretty sure a substantial part of PHP's reputation is the nightmare code produced by PHP developers.
  - 10y ago