8 ms·

PHP vs Node js... Let's be honest: Node.js couldn't kill PHP. Why?

25 points by clubminsk 9y ago

combatentropy 9y ago
I maintain a mountain of PHP. What attracts me to JavaScript is its syntax: PHP: $fruit = array('apple', 'banana', 'orange'); $fruit_colors = array( 'apple' => 'red', 'banana' => 'yellow', 'orange' => 'orange' ); JavaScript: var fruits = [ 'apple', 'banana', 'orange' ], fruit_colors = { apple: 'red', banana: 'yellow', oranage: 'orange' }; That's like 20,000 fewer keystrokes and much easier to read. My favorite new feature in PHP is the short array syntax. Even those less minimalistic than me, I think the draw to Node is the language, the consistency of having the same language front and back. Much ado is made about which one is faster. But I would say roughly 99% of web apps are CRUD apps, with a few users per hour, and the bottleneck would be the database anyway. For me what PHP has going for it is my familiarity with it. Plus, despite all the nitpicking articles, it is rock solid, especially compared to Node. And compared to Node, PHP is a hyper-organized library of everything you need, just an arm-length away.
- jbrooksuk 9y ago
  PHP has had square brackets for arrays since 5.4.0 $array = []
- dagn 9y ago
  A few months ago I was tasked with porting an internally used Node.js script to PHP 5.6. The code made heavy use of nested async callbacks and other patterns frequently only seen in Javascript codebases. I thought I'd have to rewrite most of it from scratch, but the PHP code ended up nearly identical to the original Javascript. Line-for-line, ignoring minor syntactical differences (like the $ in vars), these two ~400 line scripts ended up being 98% identical. Anonymous functions, closures, async calls, syntax short-hands... PHP has it all.
lioeters 9y ago
Due to the ubiquity and ease of hosting PHP, and the current shift to full-stack JavaScript frameworks, I predict a long transition period where various "bridges" will be made to interface between the two. Mainly I'm thinking of PHP-side exposing content via REST APIs, with a more modern frontend written all in JS.
- jbrooksuk 9y ago
  Where I work we use PHP 7.0/7.1 with the Laravel framework and Vue.js as the front end. Works well for us!
  - lioeters 9y ago
    I'm curious, how do you reconcile server- and client-side rendering to be the same? Specifically, I'm thinking about initial page load/reload and route transitions. Do you share templates/partials between PHP and JavaScript?
claudiulodro 9y ago
#1 reason the article doesn't mention: It's incredibly cheap to host PHP. Hosting companies push WordPress and other PHP-based hosting heavily and make it super easy for anyone to get a live site going with PHP. Last time I launched a node app, it took me a full day of messing about in AWS. Last time I launched a PHP app, it took me less than a half hour at Siteground.
- clubminsk 9y ago
  exactly!
- moomin 9y ago
  TBH, PHP is viable for pretty much exactly as long as Wordpress survives and uses it. If that changed, I wouldn't fancy PHPs chances.
  - Daishiman 9y ago
    The vast majority of web sites run PHP for better or worse and that code ain't going nowhere. The performance characteristics of Node are completely irrelevant for most sites. The developments model's inherent complexity and the moving target, however, matters very much.
    - camus2 9y ago
      > The vast majority of web sites run PHP for better or worse and that code ain't going nowhere. The vast majority of blogs that are build in Wordpress. Remove all the blogs and corporate websites and I bet that's not the case anymore.
      - Daishiman 9y ago
        You're saying that as if blogs and corporate websites weren't a humongous proportion of the internet. And no, there's some pretty big, modern sites like Mailchimp which run on PHP. There's literally no reason to use Node if you already have an effective backend with PHP because Node doesn't really bring anything new on the table, but it does bring along its own class of issues.
tmzt 9y ago
I have successfully run node.js applications on a hosting account which supported fast cgi for Rails applications. Unlike normal node.js applications, the process is started and managed by the provider's web server and applications can be uploaded using a standard FTP application. Here's a similar library: https://www.npmjs.com/package/node-fastcgi https://www.npmjs.com/package/node-fastcgi
- clubminsk 9y ago
  Lucky with the provider?
  - tmzt 9y ago
    This was a couple of years ago, but the provider was Bluehost. While I had shell access and a compiler, I only used it to compile the node binary and make the main js file executable with a hashbang.
erikpukinskis 9y ago
PHP uses an imperative programming model and has a very clear URL->source file mapping. This means you can look at the URL, find the source file, start at the top and trace your way to the problem. Node (and Rails, and Java and lots of others) use a declarative router. The app boots. Shit happens. Routes exist. Middleware is involved. There's no way to know what code is implicated in a given URL. If you're a pro and you can afford to spend a year or so learning framework internals while not getting much done, you develop a sixth sense for where in the codebase an error is likely to be, but you need to spend many weeks and months scratching your head to get there. PHP is much more beginner friendly in this way.
- dcd0101 9y ago
  Yep. It's just easier to start a basic site in PHP when you're new. The typical tutorial is "write these four lines in a file and upload it to any host." You're good to go. Now they shouldn't, but people jumping on JS often spin their wheels until they get pointed to a boilerplate project. It doesn't make for a fair comparison, but it doesn't matter. Now they're trying to wrap their heads around six major libs with loosely overlapping concepts, four build and orchestration tools, and ten-plus scattered files... for "hello world." Then comes the generally miserable process of figuring out how to put it online. Throughout this process the reference material is all at least three weeks old, making it hopelessly out-of-date. I mean, this stuff is often referred to (even here) as a kind of dumpster fire. I can't imagine what a truly new person would think. So while I'm not starting any new PHP projects these days, it isn't hard to see the general appeal.
- clubminsk 9y ago
  A very interesting... observation! I've never heard about it before... Thank you for sharing your professional expertise with us
- jayflux 9y ago
  When's the last time PHP has been used in this way? Don't people use frameworks these days such as symfony, silex and laravel etc? And then point the web server to the entry point like with any other language?
chairmanmow 9y ago
I can't take this article seriously when it shows a survey at the top claiming to show a stack overflow developer survey for back-end technologies that lists Javascript at 54% happiness, and then further down it lists nodeJS at 14% happiness. I guess the other 41% were using io.js. Apparently people are also happier using angular on the back-end. Which makes no sense. Also, pretty sure WP still runs PHP on the back-end. So much inaccuracy here.
- deleted 9y ago
  [deleted]
lemonsqueeze 9y ago
I didnt realize there was cpanel and phpmyadmin for Node. That changes everything
segmondy 9y ago
Node was not built to kill or replace PHP, so why should it? I mean even C++ didn't kill or replace C. Both languages can coexist, I like em both.
raarts 9y ago
'complement' not 'compliment'
- clubminsk 9y ago
  thank you
igtztorrero 9y ago
Asyncronous thats the difference. Nodejs its asyncronous, thats powerfull but its a nigthmare to control it in a crud database api. We try to change from php to nodejs in 2016 but async was the difference.
pteredactyl 9y ago
Why the clickbait? Use the right tool for the job.
partycoder 9y ago
There's still people working on Visual Basic 6 as well. That doesn't mean there are no viable alternatives.
- cordite 9y ago
  Faced VB6 professionally, there are viable alternatives, but end users don't buy your software because of what technology you made it with, or originally made it with. They buy it if it works and does what they need. It comes down to viable transitions and the resources needed to make it happen. Indeed from the last 6 years, companies are more willing to try out new technologies, like node, or even docker! But only places that can truly develop decoupled from the technology already used can jump on board for these things. The transition cost for adding other technology when decoupled is magnitudes lower than migrating an existing functioning production proven product. I have my own opinion on NodeJS, but I give it credit for the tooling it has outside of production server uses.
  - partycoder 9y ago
    You can imply node.js is not a viable production server solution. But you should rather be more explicit why. I am curious about your perspective. PHP as a project includes a templating engine, a scripting language, and a lot of native code built without a modern approach. node is a more scoped project. Doesn't implement its own scripting language, and doesn't include a templating engine and a lot of the stuff PHP does. It focus on doing a single thing well. The native part of it is libuv, which uses a consistent approach: non-blocking asynchronous I/O. Many other projects also build on top of libuv and v8, and any improvements coming from those integrations ultimately benefit node. In comparison, PHP is one large project encompassing everything. As a result, I won't expect PHP to move as fast. It's a larger project with lots of backward compatibility concerns to take care of. I know that PHP has known large deployments but none of those run on the reference implementation. node.js does have large deployments running on its default implementation.
    - cordite 9y ago
      This perspective is only from my limited experiences with Node in writing and interacting with existing node software. Node is great if you want shared state, there is no overhead to access state introduced by many users of your system. Making a game server of sorts seems like a good fit. It is also running on a proven technology which is battle tested by millions of users independently each day. But, with the cost of trivial access to shared state, there is no isolation. A metaphor from the Erlang community is that it's tolerable to crash a one on one phone call, but not the entire switch and everyone connected through it. I have experienced existing software with space leaks which need to be restarted every week to remain operational in production with tolerable latency and resource footprint. It doesn't seem sane to me. (The example here is a channel pub sub server) Indeed PHP for large deployments requires tuning or alternative implementations (e.g. HipHop) to be reliable and fast at scale. But one aspect PHP does that node does not is assume isolation. Isolation is not a guarantee, but if one page crashes, most of the time others are not directly impacted. If on PHP processes runs out of memory, same story. If one tries to starve the scheduler, it will eventually time out and be killed. Your point on it having a legacy of many integrated parts is very true, and I share your conclusion on not expecting it to move fast. Many developers are coming to the shared perspective that simple software should have simple extensible cores and it is okay to have multiple implementations for a class of features (e.g. templating). This model of independent reusable parts is where we will see fast moving technology grow.

25 points by clubminsk 9y ago

I maintain a mountain of PHP. What attracts me to JavaScript is its syntax: PHP: $fruit = array('apple', 'banana', 'orange'); $fruit_colors = array( 'apple' => 'red', 'banana' => 'yellow', 'orange' => 'orange' ); JavaScript: var fruits = [ 'apple', 'banana', 'orange' ], fruit_colors = { apple: 'red', banana: 'yellow', oranage: 'orange' }; That's like 20,000 fewer keystrokes and much easier to read. My favorite new feature in PHP is the short array syntax. Even those less minimalistic than me, I think the draw to Node is the language, the consistency of having the same language front and back. Much ado is made about which one is faster. But I would say roughly 99% of web apps are CRUD apps, with a few users per hour, and the bottleneck would be the database anyway. For me what PHP has going for it is my familiarity with it. Plus, despite all the nitpicking articles, it is rock solid, especially compared to Node. And compared to Node, PHP is a hyper-organized library of everything you need, just an arm-length away.

jbrooksuk 9y ago
PHP has had square brackets for arrays since 5.4.0 $array = []
dagn 9y ago
A few months ago I was tasked with porting an internally used Node.js script to PHP 5.6. The code made heavy use of nested async callbacks and other patterns frequently only seen in Javascript codebases. I thought I'd have to rewrite most of it from scratch, but the PHP code ended up nearly identical to the original Javascript. Line-for-line, ignoring minor syntactical differences (like the $ in vars), these two ~400 line scripts ended up being 98% identical. Anonymous functions, closures, async calls, syntax short-hands... PHP has it all.

lioeters 9y ago

Due to the ubiquity and ease of hosting PHP, and the current shift to full-stack JavaScript frameworks, I predict a long transition period where various "bridges" will be made to interface between the two. Mainly I'm thinking of PHP-side exposing content via REST APIs, with a more modern frontend written all in JS.

jbrooksuk 9y ago
Where I work we use PHP 7.0/7.1 with the Laravel framework and Vue.js as the front end. Works well for us!
- lioeters 9y ago
  I'm curious, how do you reconcile server- and client-side rendering to be the same? Specifically, I'm thinking about initial page load/reload and route transitions. Do you share templates/partials between PHP and JavaScript?

claudiulodro 9y ago

#1 reason the article doesn't mention: It's incredibly cheap to host PHP. Hosting companies push WordPress and other PHP-based hosting heavily and make it super easy for anyone to get a live site going with PHP. Last time I launched a node app, it took me a full day of messing about in AWS. Last time I launched a PHP app, it took me less than a half hour at Siteground.

clubminsk 9y ago
exactly!
moomin 9y ago
TBH, PHP is viable for pretty much exactly as long as Wordpress survives and uses it. If that changed, I wouldn't fancy PHPs chances.
- Daishiman 9y ago
  The vast majority of web sites run PHP for better or worse and that code ain't going nowhere. The performance characteristics of Node are completely irrelevant for most sites. The developments model's inherent complexity and the moving target, however, matters very much.
  - camus2 9y ago
    > The vast majority of web sites run PHP for better or worse and that code ain't going nowhere. The vast majority of blogs that are build in Wordpress. Remove all the blogs and corporate websites and I bet that's not the case anymore.
    - Daishiman 9y ago
      You're saying that as if blogs and corporate websites weren't a humongous proportion of the internet. And no, there's some pretty big, modern sites like Mailchimp which run on PHP. There's literally no reason to use Node if you already have an effective backend with PHP because Node doesn't really bring anything new on the table, but it does bring along its own class of issues.

tmzt 9y ago

I have successfully run node.js applications on a hosting account which supported fast cgi for Rails applications. Unlike normal node.js applications, the process is started and managed by the provider's web server and applications can be uploaded using a standard FTP application. Here's a similar library: https://www.npmjs.com/package/node-fastcgi https://www.npmjs.com/package/node-fastcgi

clubminsk 9y ago
Lucky with the provider?
- tmzt 9y ago
  This was a couple of years ago, but the provider was Bluehost. While I had shell access and a compiler, I only used it to compile the node binary and make the main js file executable with a hashbang.

erikpukinskis 9y ago

PHP uses an imperative programming model and has a very clear URL->source file mapping. This means you can look at the URL, find the source file, start at the top and trace your way to the problem. Node (and Rails, and Java and lots of others) use a declarative router. The app boots. Shit happens. Routes exist. Middleware is involved. There's no way to know what code is implicated in a given URL. If you're a pro and you can afford to spend a year or so learning framework internals while not getting much done, you develop a sixth sense for where in the codebase an error is likely to be, but you need to spend many weeks and months scratching your head to get there. PHP is much more beginner friendly in this way.

dcd0101 9y ago
Yep. It's just easier to start a basic site in PHP when you're new. The typical tutorial is "write these four lines in a file and upload it to any host." You're good to go. Now they shouldn't, but people jumping on JS often spin their wheels until they get pointed to a boilerplate project. It doesn't make for a fair comparison, but it doesn't matter. Now they're trying to wrap their heads around six major libs with loosely overlapping concepts, four build and orchestration tools, and ten-plus scattered files... for "hello world." Then comes the generally miserable process of figuring out how to put it online. Throughout this process the reference material is all at least three weeks old, making it hopelessly out-of-date. I mean, this stuff is often referred to (even here) as a kind of dumpster fire. I can't imagine what a truly new person would think. So while I'm not starting any new PHP projects these days, it isn't hard to see the general appeal.
clubminsk 9y ago
A very interesting... observation! I've never heard about it before... Thank you for sharing your professional expertise with us
jayflux 9y ago
When's the last time PHP has been used in this way? Don't people use frameworks these days such as symfony, silex and laravel etc? And then point the web server to the entry point like with any other language?

chairmanmow 9y ago

I can't take this article seriously when it shows a survey at the top claiming to show a stack overflow developer survey for back-end technologies that lists Javascript at 54% happiness, and then further down it lists nodeJS at 14% happiness. I guess the other 41% were using io.js. Apparently people are also happier using angular on the back-end. Which makes no sense. Also, pretty sure WP still runs PHP on the back-end. So much inaccuracy here.

deleted 9y ago
[deleted]

lemonsqueeze 9y ago

I didnt realize there was cpanel and phpmyadmin for Node. That changes everything

segmondy 9y ago

Node was not built to kill or replace PHP, so why should it? I mean even C++ didn't kill or replace C. Both languages can coexist, I like em both.

raarts 9y ago

'complement' not 'compliment'

clubminsk 9y ago
thank you

igtztorrero 9y ago

Asyncronous thats the difference. Nodejs its asyncronous, thats powerfull but its a nigthmare to control it in a crud database api. We try to change from php to nodejs in 2016 but async was the difference.

pteredactyl 9y ago

Why the clickbait? Use the right tool for the job.

partycoder 9y ago

There's still people working on Visual Basic 6 as well. That doesn't mean there are no viable alternatives.

cordite 9y ago
Faced VB6 professionally, there are viable alternatives, but end users don't buy your software because of what technology you made it with, or originally made it with. They buy it if it works and does what they need. It comes down to viable transitions and the resources needed to make it happen. Indeed from the last 6 years, companies are more willing to try out new technologies, like node, or even docker! But only places that can truly develop decoupled from the technology already used can jump on board for these things. The transition cost for adding other technology when decoupled is magnitudes lower than migrating an existing functioning production proven product. I have my own opinion on NodeJS, but I give it credit for the tooling it has outside of production server uses.
- partycoder 9y ago
  You can imply node.js is not a viable production server solution. But you should rather be more explicit why. I am curious about your perspective. PHP as a project includes a templating engine, a scripting language, and a lot of native code built without a modern approach. node is a more scoped project. Doesn't implement its own scripting language, and doesn't include a templating engine and a lot of the stuff PHP does. It focus on doing a single thing well. The native part of it is libuv, which uses a consistent approach: non-blocking asynchronous I/O. Many other projects also build on top of libuv and v8, and any improvements coming from those integrations ultimately benefit node. In comparison, PHP is one large project encompassing everything. As a result, I won't expect PHP to move as fast. It's a larger project with lots of backward compatibility concerns to take care of. I know that PHP has known large deployments but none of those run on the reference implementation. node.js does have large deployments running on its default implementation.
  - cordite 9y ago
    This perspective is only from my limited experiences with Node in writing and interacting with existing node software. Node is great if you want shared state, there is no overhead to access state introduced by many users of your system. Making a game server of sorts seems like a good fit. It is also running on a proven technology which is battle tested by millions of users independently each day. But, with the cost of trivial access to shared state, there is no isolation. A metaphor from the Erlang community is that it's tolerable to crash a one on one phone call, but not the entire switch and everyone connected through it. I have experienced existing software with space leaks which need to be restarted every week to remain operational in production with tolerable latency and resource footprint. It doesn't seem sane to me. (The example here is a channel pub sub server) Indeed PHP for large deployments requires tuning or alternative implementations (e.g. HipHop) to be reliable and fast at scale. But one aspect PHP does that node does not is assume isolation. Isolation is not a guarantee, but if one page crashes, most of the time others are not directly impacted. If on PHP processes runs out of memory, same story. If one tries to starve the scheduler, it will eventually time out and be killed. Your point on it having a legacy of many integrated parts is very true, and I share your conclusion on not expecting it to move fast. Many developers are coming to the shared perspective that simple software should have simple extensible cores and it is okay to have multiple implementations for a class of features (e.g. templating). This model of independent reusable parts is where we will see fast moving technology grow.