
PHP in a JavaScript world - chrisshennan
http://www.blonde.net/blog/2015/05/05/php-javascript-world
======
tnash
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=...](https://www.techempower.com/benchmarks/#section=data-r10&hw=peak&test=db)

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

~~~
joshuacc
Personally, I'd say that the front-end tooling ecosystem constitutes the
"killer app":

\- Minification: Uglify

\- Transpilation: Babel/TypeScript/CoffeeScript

\- JS Module Systems: Require/Browserify/Webpack/JSPM

\- CSS preprocessors: Less/Sass/Stylus

\- Linting: JSHint/ESLint/CSSLint

If you're using a lot of front-end tools, you're using Node. And if you're
using Node, you might as well use it to write your APIs.

~~~
BrianDGLS
I agree.

At this time Javascript's biggest strength is build tools. It may not be as
mature as PHP on the server, but there is so much community growth that I
don't think it will be long catching up.

~~~
delta9
It's like saying PHP as a great community, we will catching up JAVA soon.. non
sense, as the topic said, I want to use node if there are some killer app that
I want to use, like the one I know in other languages. Do you know any like
drupal for example (multilingual, workflow, content management system, and
more) ?

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

~~~
ergothus
I can see your point, and while I'm not versed in Go or Erlang _, moving to JS
let me stop worrying about if a value ever changed - as long as I 'm in my
portion of code, I alone can change the values. That, in turn, means that I
spend very little time worrying - much less than I did in, say, Java.

Sure, I need to not BLOCK stuff for long, but that comes about somewhat
naturally as good code: Write small, discrete units.

_ Not knowing modern multithreaded languages may render my entire point moot.
I'll have to fix that.

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

~~~
wvenable
I'd love to play more with Node but I have free PHP hosting. I control the
server completely but I have to keep PHP running. I don't how to get NodeJS to
play nicely alongside bog standard LAMP stack (and all the rest of the tech)
so I haven't done anything with it.

~~~
Killswitch
It's easy, just install Node. I mean, what complications are you having that
you can't get it to work correctly?

Edit:// Also Digita Ocean $5 VPS is cheap to play with Node on, or even use a
Vagrant machine.

~~~
wvenable
I'd like to have node respond to port 80 http requests for one virtual site
and have Apache/PHP respond for other virtual sites so I can use the hardware
I already have available. I can think of a few hacky was to make it work but
it seems less than ideal.

Obviously I could pay for other hardware but I don't want to do that.

"It's easy, just install Node." funny.

~~~
RossM
It's a fairly common scenario. We're doing this with nginxbut docker'll be a
good solution soon enough. The terms to search for are "reverse proxy".

Essentially you setup nginx to listen on port 80, Apache to listen on another
port (say, 8080) and node to listen on a different port (say, 8081). Then have
your nginx config differentiate between the two:

    
    
        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;
            }   
        }   
    

IMO this gets a little easier to think about if you substitute your Apache
-(mod_php)-> PHP setup for Nginx -(fastcgi)-> php-fpm - handing off to an
appserver rather than a webserver.

~~~
wvenable
I'm concerned about adding ngnix to the system as that's a fairly significant
change to a working system. There are a lot of variables and sites involved.

I've considered reverse-proxying entirely within Apache to avoid adding ngnix
another layer. But this really hinders some of the advantages of node which
makes me wonder if it's worth even doing. It seems like node is best when it
can handle the requests directly.

Your advice here is pretty much the most common answer.

~~~
Killswitch
> It seems like node is best when it can handle the requests directly

What makes you believe that?

~~~
wvenable
Node's single process event-loop model of handling requests seems in direct
contrast to apache's one heavy-weight process/thread per request model.

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

~~~
meritt
And PHP was supposed to kill Perl.

At the end of the day, all of the languages being discussed here are all
capable of achieving the same goals for 99% of the problems presented. Every
language has its pros/cons and brings something new to the table that we
usually see the others adopt.

~~~
krapp
As a server-side language, PHP has pretty much killed Perl, hasn't it?

~~~
chucky_z
server-side as in... shell scripts/daemons?

or server-side as in... cgi/fastcgi serving to a client?

because I would say 'yes' to cgi/fastcgi, but 'no' to shell scripts/daemons.

There are a handful of really cool newish Perl frameworks, but unfortunately I
think Perl 5's stigma is so far out there it will never gain any real
traction. It seems that Perl 6 has a lot of the same stigma attached to it. I
almost wish they would name it something other than Perl so that a fresh
perspective could be used, it seems like it's going to be quite nice!

~~~
krapp
I meant the cgi part.

------
kenOfYugen
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](http://imgur.com/NnQ9M5v)

[1]
[http://link.springer.com/article/10.1007/s00607-014-0394-9](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"

------
stephenheron
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!

~~~
Theodores
This is a good article if you are a backend PHP developer working closely with
someone that looks after the front end.

Personally I like these working arrangements and being able to dish up HTML
safe in the knowledge that your frontend developer is getting what he needs
complete with expected class tags and other markup to be styled. In the future
it will probably be better for me as I won't be doing template files with
fiddly PHP tags, instead I will be json encoding the requested data, e.g. an
array of products. There is a whole lot of logic to getting that array of
products, this you need the server for. Presentation of that data? That can be
done with the new stuff. From this article I have a better idea of what might
be the future.

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

