PHP in a JavaScript world (blonde.net)

Wordpress, drupal, magento, phabricator, mediawiki, sugarcrm...

These are vastly popular, feature rich out of the box tools in PHP, aka the "killer apps".

As I don't follow the node community, what are the killer apps on the node side? Im talking about a complete piece of software, where I would want to set up an environment not for development but for running an application.

   result := Object.DoNonBlocking()

Python was supposed to kill PHP. Ruby on Rails was supposed to kill PHP. Now Javascript is supposed to kill PHP? Not a chance, at least in the near future.

I wrote this article so please don't too harsh ;) Crazy to see something I wrote for our company blog on the frontpage of HN this afternoon!

I've been a PHP developer since 1997. December of 2014 I left PHP completely for NodeJS. Best decision of my life.

    upstream apache {
        server 127.0.0.1:8080;
    }   
    
    upstream nodeapp {
        server 127.0.0.1:8081;
    }   
    
    server {
        listen 80; 
        
        server_name myphpapp.example.com;
        
        location / { 
            proxy_pass http://apache;
            proxy_set_header Host $host;
        }   
    }   
    
    server {
        listen 80; 
        
        server_name mynodeapp.example.com;
        
        location / { 
            proxy_pass http://nodeapp;
            proxy_set_header Host $host;
        }   
    }   

JavaScript or not, something has got to replace that abomination.

> The event loop is one of Node.js strengths as it makes it blisteringly fast when dealing with many connections. However the event loop does pose some challenges. One of the most important things to consider is that you should never block the event loop. [...] Now some great tools do exist for monitoring the event loop and if you understand the event loop and take care not to block it, then everything will most likely be fine. However you should be mindful of its strengths and limitations while developing.

I think the concurrency model provided by green threads in Go and Erlang is orders of magnitude easier to reason about, where you can write blocking I/O and the scheduler itself will take care of making sure that your code runs fine. The last thing I need when writing concurrent code is yet another thing to think about at every step of the way. This is a hugely underrated flaw in my opinion of node.js servers. With languages like Haskell, Rust, and Go we are seeing a trend of having smarter compilers and language runtimes making programs much easier to write, where I am offloading lots of things from my mind onto the compiler. The whole point of pre-emptive multi-tasking is to relieve the burden of "taking care not to block [the event loop]," and I think in that respect node.js is a step back.

From a more academic approach [1], if you care about efficient concurrency and no context switching between frontend-backend, the node.js platform is an excellent choice.

Figure: http://imgur.com/NnQ9M5v

[1] http://link.springer.com/article/10.1007/s00607-014-0394-9 "Is Node.js a viable option for building modern web applications? A performance evaluation study"

One thing that I don't see in these kinds of articles, and what I think is most important: MySQL speed. When I was researching technology, I compared simple pages that read some data from a MySQL database and display it on an html5 page. I did this in Go, Node, Silk, and PHP. PHP blew everyone else away. Now, this was two years ago, and perhaps their MySQL client implementations have gotten better, but this test was the reason my startup is built using PHP. It's the fastest thing available that isn't Java or C++ based. Supported here: https://www.techempower.com/benchmarks/#section=data-r10&hw=...

My biggest problems with the article

a) He's talking about "PHP" and referring to old versions of plain vanilla PHP. He also talks about The Event Loop like it's a Node only thing: There exist such things as ReactPHP and Icicle which implement the concept. Modern PHP also comes with constructs to help with an async design

b) Node doesn't include websockets support by default either, and the comparison is made against Ratchet when it could have been made agains hoa/websocket which is both more idiomatic and nicer. As a sidenote, check them out, they make nice things.

And finally, the author marks an advantage in sharing environments when talking about languages, not runtimes. Which in and by itself is more of a curiosity.

While it could be possible to inject a PHP runtime in the frontend (and some projects like the RippleSDK somehow did), it wouldn't make sense; they don't really have the same purpose or origin, one was born in the frontend and shoehorned into the backend, and the other was born in the backend and stood there.

The way I see it, it's ultimately a matter of added value.

Why doesn't anyone actually make an Icicle vs Koa comparison? Or maybe Symfony vs ROR?

There is very little to learn from putting a toolkit (or even just the amount of tooling) against a bare language, and when people do it over and over and over it becomes clear it's just a disingenuous attempt to make the X in "PHP vs X" look good.