15 ms·

out of pure ignorance -- what are the correct domains that either fit into?

• mschuster91 9y 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 9y 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 9y ago
      what would be a good hardware spec and server configuration to have 5000 users do long polling with a php backend?
      • geon 9y ago
        If you care about performance and traffic, perhaps php isn't where you should start anyway.
        • mschuster91 9y 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 9y ago
            PHP performs better than Java? Care to offer evidence?
            • mschuster91 9y 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.
              • cutler 9y ago
                (cheaper hosting || faster deployment) != better performance
          • geon 9y ago
            Facebook built their own PHP-to-C++ compiler (https://en.wikipedia.org/wiki/HipHop_for_PHP https://en.wikipedia.org/wiki/HipHop_for_PHP) and later a JIT compiler/VM (https://en.wikipedia.org/wiki/HipHop_Virtual_Machine https://en.wikipedia.org/wiki/HipHop_Virtual_Machine), with a custom, typed version of PHP (https://en.wikipedia.org/wiki/Hack_(programming_language) https://en.wikipedia.org/wiki/Hack_(programming_language) ). All just to make PHP a little faster. I think you are making my case.
  • jwdunne 9y ago
    With regards to 2, I have experienced this. As a solution, I built a websocket server using NodeJS. I then built an API in express that PHP / Gulp used to push messages to be sent via websocket. There might be a better way but I'd effectively added support for server push from our PHP app in a morning, with great results. The other thing it provided me was clear evidence of the "best tool for the job" in a shop that demanded PHP. The problem I have with PHP is what is usually touted as it's benefit. It's easy to find PHP developers. The problem: most of them are not very good. To close, there are many more PHP RFCs that internals should approve, e.g arrow lambdas with automatic variable closure, design by contract, etc. These could really bring the language into it's own.
  • stabbles 9y ago
    There is a project called ReactPHP [1] which provides a nodejs-like event loop and async execution. However, I think the power of PHP is that it is not designed to be its own server, to run forever in the background and handle all kinds of complex async flow. Execution stops when a request is done: no memory and data leaks between requests and easy to reason about. In practice you don't really need async, except for stuff like sending emails and heavy IO. Laravel simply handles this by pushing jobs on a message queue and handling it via a worker process, but you can use any microservice of course (in particular a simple node app). [1] http://reactphp.org/ http://reactphp.org/
    • robryan 9y ago
      I am by no means an expert on the subject but use Ratchet (http://socketo.me/ http://socketo.me/) with proxying through nginx for my limited websocket needs. Works well.
      • em1t 9y ago
        I've only tried Ratchet in a sandbox and not in any production project. And as far as that, it worked well. I've done some minor stuff involving ReactPHP (which Ratchet uses for some parts) in the early days of the project, but same here - nothing that was deployed to production. I'm no expert either, but I just leave a note regarding Pushpin (http://pushpin.org/ http://pushpin.org/) here as an option to have a websocket server together with PHP. It's not a PHP project, but a good tool to have in the toolbox :)
  • vgy7ujm 9y ago
    Perl is WAY better for shell-scripty stuff. It also has yearly releases and backwards compatibility is much better than for PHP. I think YOUR perception of Perl is what is outdated here. And come on, for "job control" type scripts you should be fired for using PHP over Bash. Most things can be done in 1/10th of the LOC and OOP etc won't matter when your Bash script is one file and 150LOC instead of 5-10 files, objects an methods that are called just one time etc, 1000+LOC PHP.
    • mschuster91 9y ago
      > I think YOUR perception of Perl is what is outdated here. Next to no one uses Perl any more. You won't find people to maintain your homegrown stuff - and aside from maintaining an OTRS instance I have not seen Perl code in a decade. > Most things can be done in 1/10th of the LOC and OOP etc won't matter when your Bash script is one file and 150LOC instead of 5-10 files, objects an methods that are called just one time etc, 1000+LOC PHP. Well good luck with Bash if your batch script involves stuff like parsing JSON/XML or interacting with databases. I prefer to write quick one-offs in PHP than wasting hours with Bash scripting; and even if it's no one-off but a script that needs to be run regularly (e.g. via cron), you'll find a competent PHP programmer for maintenance way easier than a competent Bash programmer. > And come on, for "job control" type scripts you should be fired for using PHP over Bash. For plain job control, like an initscript, I fully agree with you. But not for anything more complex, for the reasons outlined above.
• tannhaeuser 9y 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 9y 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 9y 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 9y ago
    Every web framework out there (express + nodejs included) will handle exceptions properly and not blow up the server on exception.
    • matsemann 9y 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 9y 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 9y 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.