Comment by mschuster91 | Hacker News Reader

Comment by mschuster91 | Hacker News Reader

Parent Full thread

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".

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/

I am by no means an expert on the subject but use Ratchet (http://socketo.me/) with proxying through nginx for my limited websocket needs. Works well.

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/) 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 :)

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.

> 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.

> 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.

what would be a good hardware spec and server configuration to have 5000 users do long polling with a php backend?

If you care about performance and traffic, perhaps php isn't where you should start anyway.

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.

PHP performs better than Java? Care to offer evidence?

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.

(cheaper hosting || faster deployment) != better performance

Facebook built their own PHP-to-C++ compiler (https://en.wikipedia.org/wiki/HipHop_for_PHP) and later a JIT compiler/VM (https://en.wikipedia.org/wiki/HipHop_Virtual_Machine), with a custom, typed version of PHP (https://en.wikipedia.org/wiki/Hack_(programming_language) ).

All just to make PHP a little faster. I think you are making my case.

HH transpilation was introduced in 2010. Depending on when exactly you look in 2010, FB had between 350-600M active users (https://www.yahoo.com/news/number-active-users-facebook-over...).

Many websites don't ever get to 350M users, so it's safe to say that plain PHP will satisfy your startup for a long time. Also, PHP7 is pretty much on par with HHVM in real-world scenarios: https://kinsta.com/blog/the-definitive-php-7-final-version-h...

And the vast majority of websites never get 5000 concurrent users either. Your planned load obviously dictates the language as much as anything else.

Check out "experimental JIT branch" of PHP. It boost performance 1.5-2 times compared to current PHP 7.1, and they didn't start optimization yet. It blows HHVM out of the water, and I can't wait to compare performance with Java and .NET.

Yes, of course there are easy to use and much better programming languages for that - I just really wanted to read some "real-life" recommendations from that guy that mentioned "php" and "long-polling" in the same sentence.

[Maybe it was just a joke and I did not get it... or I did get it but did not identify it as a joke... however... I would like to see some beef...]

> If you run it as a cli script, you can implement pretty much anything. I saw a ftp server once. Crazy.

Yeah, I implemented a simple ircd once. Funny days... but I don't know of any library/framework that could help you with the websocket protocol level, and I'm too old for writing my own ;)

Websocket is actually not that complicated. A couple of headers to upgrade the request from HTTP to websocket, then framing of each payload.

But you could use something like websocketd, which spawns a process of your chioce for each client and pipes the websocket to stdin and vice versa.

https://github.com/joewalnes/websocketd

Each PHP process looks like it takes about 5 MB of ram on my laptop, so probably not the best method for 5000+ concurrent users if you use PHP, but still.

> I don't know of any library/framework that could help you with the websocket protocol level

FYI - http://socketo.me/

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.

Reply on news.ycombinator.com