I'm going to let you in on an industry secret. Scalability has little if anything to do with the choice of language. It is more about your "architectural" choices. Damn I hate using that word.
It's all about planning how you're going to divvy up the workload once you need to go multi-server.
The real differences between node.js and PHP is what they suck at, and what they excel at.
node.js is great for low latency responses where you don't want to bang out custom code in C just to talk to the networking. It can talk to the web directly without a middle-man server such as Apache, reducing handshaking and networking overhead. If you just need relatively performant dumps of raw data in formats like JSON, CSV, or ASCII delimited, node.js is da man.
Unfortunately node.js inhales upon the proverbial equine of short stature at outputting HTML which is why all these goofball half-assed halfwit "front end frameworks" like React, Angular, and Vue take a giant steaming dump. It also requires a lot more micromanagement to install and configure properly, and many web hosts not only don't offer it "out of box", they refuse to even let you set it up. Though thankfully that number is dropping.
PHP is glue. It's amazing glue. It's Gorilla glue. If you're letting database do your heavy lifting and just need to "glue" your results to the database with minimal logic, PHP is da bomb. It has a clearer, cleaner language syntax that makes its (former, see newest version) lack of strict typecasting has none of the negative problems JavaScript does. Just the fact that it uses a period to force string addition and will toss an error if you try to + add two non-numeric strings puts it head and shoulders over JavaScript's way of doing things.
More importantly though is that PHP has a lot of "yeah, there's a function for that" where things you have to brute force or dive for a library for in node.js? It's just built into PHP. This is more true if you're willing to enable PEAR.
Where PHP used to fall flat on its face is performance, and that gap is being closed. JiT compilation, optimizations to the parser, and even the ability to self-host are being worked in so that "this ain't your grandpa's PHP". Indeed a lot of the "complaints" you'll hear about PHP haven't been true in over 15 years.
Even so the biggest problem with PHP is when people try to use it for things outside its useful province. Kind of like what happens when people try to use Gorilla glue as hair gel.
One big thing to keep in mind is that no langage has to be used "exclusively" and you can mix and match so that you use the "right tool for the right job". This is where a lot of developers go full Gungan, screaming "wah wah eye dunz wunna lurn anutter rangwaj". There's this myth that it makes systems harder to maintain and so forth when in fact trying to use just one language for everything results in tech debt and task complexity mismatch.
A recent client of mine was using both node.js and PHP side-by-side, and treated node.js as an entirely separate beast from client side JS. Node.js handled most data requests on a separate domain dumping them out as JSON. This gave a single point of maintaining data operations that both the PHP driven page generation could access, as well as their client-side scripting via AJAX.
Basically they had:
Server #1 -- node.js driven database outputting JSON
Server #2 -- apache + php handling all public domain requests gluing the JSON to markup and little else. This is not only for first-loads, but also for scripted off users.l
Server #3 -- lightppd for all static files like CSS, images, client-side JS
Client Side -- if scripting is available, requests are done through server #1 as JSON and built in the browser, instead of via server #2.
Fun part was they had one database table that was high traffic that wasn't queried alongside the other tables, so they were able to break that out into another separate server.
The only part that took real effort was maintaining cross domain "sessions" via a token system. I wasn't involved in that so I'm not 100% sure what doing that entails. I mean you can make cross subdomain cookies, but given how easy it is to fake a subdomain I'm not sure how smart that is.
Anyone with insight into that, please share. I'm not 100% full stack, but I can fake one on the Internet.
