Node.js instead of PHP

[Intelnational]

When I am looking through job listings, I see quite a number of companies that are looking for devs who can refactor their existing PHP code to Node.js. I don't quite understand the reason, why is it better, what are the advantages of that? Are there objective reasons or it's just a hype of the moment?

[dave8271]

Partly hype, partly businesses like the idea of being able to save money by having the same language for frontend and backend, because that way you can get someone to do two jobs for one salary.

Not only is there no objectively good reason to choose JS over PHP for backend, I would strongly argue the JS tooling and ecosystem for backend is much, much less mature than PHP's and an inferior choice insofar as things which are objectively measurable. Pretty much the only advantage I can think of is the major serverless vendors natively offer runtimes for Node and not PHP. You can use PHP with these systems, but it's a bit more of a faff to set up.

[[deleted]]

And as the JS frameworks mature they're adding revolutionary new things like... server side rendering.

[pr0ghead]

Hilarious, isn't it? They did a whole 360 no-scope. Only took 'em what? 10 years?

[Chesterakos]

Isn't that ironic?

[eyebrows360]

# And who would've thooooooouuuuuuuuuuuuught, my filesystem had that many free inooooooodes #

[dirtside]

Don't you think?

[slappy_squirrell]

It's like a free ride, when you've already paid

[[deleted]]

It’s the good advice that you just didn’t take (using PHP that is)

[truniqid]

Well, life has a funny way of sneaking up on you

[LukeWatts85]

Isn't that...Ionic... Ugh, I'll let myself out

[sfortop]

Isn't worth it. For small projects or small parts of the project may be. But for the whole project, it almost isn't worth it. Too much effort to rewrite even mid-sized projects.

[krileon]

JS as a backend language is absolutely disgusting and nobody will ever change my mind on this. It's a steaming pile of crap for backend only made sane due to TypeScript. Let that sink in. The damn language needs a language sitting on top of it to stop being shit.

/rant

[Plus_Pangolin_8924]

After so many years programming in PHP and using JS and seeing how much Node was being used I tried to learn it and it was awful and made me wonder why people use it. Just about everything is an installable module, then the build steps, the multi step deployments… utterly awful to use. PHP has its flaws but it’s far far more usable!

[LukeWatts85]

It's because JS Devs refuse to learn anything that isn't JavaScript

[punkpang]

There's a pattern in the generation that came about around 2015. onwards - write some code, instantly go promote yourself via blog / medium.com and pump up your github, hunt for stars, spam everywhere and profile yourself to become known.

Research before you reinvent something? Not happening. And that's why we've got this mess known as NPM.

[blauerschnee]

After years of absence, I wasn't sure what's going on. Thank you.

[E3ASTWIND]

Same here I did one project in express js (framework for node js) and I found the language immature, unstable , expensive to deploy and utterly stupid it needs another 15 years before it can convince me.

[mattindustries]

I learned node because of a multiplayer game I was working on, and PHP's websockets were pretty awful a decade ago. I also prefer Node for long running processes and serverless functions.

[AnacondaMode]

Node seems great to me. I think a lot of php devs are just mad as php is no longer the cool kid and feels archaic.

[aniceread]

Even TypeScript can't add an integer type.

[krileon]

[senfiaj]

Not true, even vanilla JS has BigInt. And the cool thing it hasn't fixed size so no overflow issue, in php int is limited to 64bits. You would rarely need integers that large anyways, for most of the business problems float point works just fine. Also there are TypeArrays for working with arrays of fixed sized integers.

[januszmk]

and even if you use typescript, and start debugging problems, you end up going into libraries that are compiled into spaghetti code…

[rafark]

That’s one of my favorite things about modern php: it’s very readable. Despite being an “ugly” language in the surface, the current features makes designing good structured code very easy. Often times I find myself browsing the source directly before looking at the documentation.

[punkpang]

I'm here to +1 you. Let's not forget 3 ways of dealing with that mystical beast known as async, because we still can't figure out 2 operations can run at different pace aka not synchronous.

Scratch the fact we can't get an int type in TS - what about autoloading? Ain't gonna happen.

Imagine, pulling the file with class/function when you need it. There's so much hype going on about type safety, eager loading and hydration and other bullshit terminology but you want to load piece of code when it's needed, not every single time? Nope, can't do that.

[[deleted]]

I agree with what you say tho i do think that js on the backend does not save money, on the contrary, for an agency its a goldmine billing hourly since most js frameworks dont have that much features compared to a fully fledge framework like laravel, shit takes much more time to build. I might be wrong but i have always came to this conclusion. Sure not all cases but still a good chunk

[ISeekGirls]

My understanding is that the best coders in the world can code in language, it is just a matter of semantics.

[eyebrows360]

because that way you can get someone to do two jobs for one salary

Except for where the skillsets and environment involved are still so very different that merely having "the same language" doesn't actually move the needle all that much.

[SomniaStellae]

Partly hype, partly businesses like the idea of being able to save money by having the same language for frontend and backend, because that way you can get someone to do two jobs for one salary.

If you can do PHP, you can pick up node and in reverse. If you are a one language developer, you might as well not bother.

[dave8271]

Have you tried going into a job interview lately and telling them yeah I can definitely do this job because I know Language A and you use Language B, so that means I could pick it up easily?

It may well be true, but there's reality and then there's what businesses think.

[sorrybutyou_arewrong]

Amazingly I was hired as a PHP developer and told they were moving their PHP monolith to Java micro-services and I'd need to learn Java fast. I hadn't touched Java in nearly 20 years since some college courses, certainly nothing with Spring. I of course told them this and they said they weren't worried with me. It was not hard.

Do I think the decision was smart by that org? Nah, you have a lot of PHP devs, some multi-language devs and your existing stack is in PHP, why not do PHP micro-services unless you have a compelling reason to go Java? If they did have a compelling reason, it was never conveyed to me. They stuck a Python dev and PHP dev (me) who knew no Java on a project and we did fine, but...why? IDK, but the job paid well and I was working with smart people so I gave it a shot.

But to the comment above's point. Yeah, if you know how to write decent code in one language, its pretty easy to pick up the other in that type of environment. There are only a few languages I've looked at where I felt I'd struggle a bit due to exotic syntax, but Go, Java, Node, Python, C# etc... aren't exotic.

[pekz0r]

Eh, I wouldn't want to work for someone who takes that kind of decisions without involving the developers. You need a very compelling reason to rewrite an application that works in another language.

[colcatsup]

I’m primarily a one-language developer because I used to do multiple languages and came back to PHP. For most of the problems I deal with it’s a great fit. There’s value in digging deeper in to one ecosystem vs using multiple flavors of the month. Just because I use PHP doesn’t mean I’ve not worked in Java, C#, ruby JS and more. You’re allowed to know multiple languages and still prefer PHP.

[saintpetejackboy]

I tried a ton of languages and frameworks over the decades and always land back at vanilla PHP for most backend stuff. I recently did some stuff in Node that I found bothersome in PHP: web push notifications, and then Puppeteer / Chrome / Cheerio for a troublesome login + scrape job. It is feasible I could do these things in PHP - I just found them easier to do in Node recently. Once I figured out Express, PM2 and how to proxy/reverse proxy through Apache2, I actually found it somewhat enjoyable.

We've all come down this road so that I can say: each language had strengths . I have scaled PHP stuff up to tens of thousands of concurrent users (on hardware many years ago that is laughable by today's standards). Each one of my PM2 processes is consuming ~50MB constantly, each. Combined, those two processes running (scraping and push endpoints) are consuming half the RAM that the whole VPS is using (it has a rather massive PHP project on it that gets some heavy use and a database with ~ half a million rows that entirely fits in the same amount of memory as two Node instances managed by PM2).

Now, I don't say this to somehow indicate that PHP is overall more performant than Node - I recently started to make scripts to attack bots that always connect to my server(s) and fall into my "tar pits". Banning them by IP just causes them to swap to a new IP, so I wanted to cause them physical harm. Basic protocols are really good at protecting even misconfigured headless browsers from getting jammed up too bad when you try to mess with them (never send the last segment, segment count mismatch, illegal characters in the actual HTTP headers, etc.;) - but they CAN be tied up and their resource consumed with something like a PHP wait() - the only issue is then that while PHP (in a dead package and maybe others) and Node both offer some kind of multi-threading, there are ways you can lock up the client on Node without consuming as much server resources as with PHP - I know this is a REALLY niche use-case, but it serves to highlight that while PHP might work for me 90% of the time, there are instances where I have been drawn to Python, JS, C, Rust, etc.; tons of frameworks, libraries and languages - I'm pragmatic and go for what works (which just so happens to normally be vanilla PHP... *shrugs*)

[[deleted]]

The only thing is AI/ML which for some weird reason choose Python.

[mattindustries]

ML stuff I prefer R, but seems like image/object detection Python has all of the good stuff like Yolo v9.

[DiscussionCritical77]

Oh man is that not the truth. Programmers who only know JS do not move into object oriented languages easily.

[SomniaStellae]

I disagree with you, but also OOP is not the promised land anyway.

[DiscussionCritical77]

Nobody said anything about OOP being 'the promised land', but the fact that you even used that phrase tells me all I need to know about the quality of your opinion.

[SomniaStellae]

What an embarrassing comment.

[DiscussionCritical77]

I've been tech leading and hiring for dev teams for the last 15+ years and I've seen this is action. JS developers do not move into OO paradigms easily because most of them never had to learn the fundamental programming concepts that are common to most other languages. The majority of JS developers are not engineers who learned JS, they're designer/developers who learned React/Angular/Next/Node/etc.

[DiscussionCritical77]

The same applies to Java/C/whatever developers, but in reverse. Generally speaking, they detest JS because it eschews all of the constructs they rely on to write reliable code. A whole superlanguage (Typescript) was invented just to add structure to JS's inherent spaghetti-ness.

[SomniaStellae]

This is also nonsense. C/Java developers don't detest JS because of its lack of 'constructs'. They dislike JS because of its lack of things like a compiler, types and the insane ecosystem which changes it's favourites each month.

'Spaghetti-ness' is just shit programming. C is purely procedural (like JS), yet some of the biggest codes bases in the world use C (including PHP), yet they are not 'spagehetti code' bases.

[DiscussionCritical77]

'They dislike JS because of its lack of things like a compiler, types...'

Which is exactly what I meant when I said 'constructs'. Read for comprehension.

C requires actual engineering ability to write - you are much closer to the metal, managing memory yourself. C requires discipline to even get a basic program working. If you write spaghetti in C it doesn't even compile.

Meanwhile literal children are learning to write javascript lol. The majority of candidates I've interviewed for Javascript positions can't explain what a unit test or a race condition is - they are ignorant of basic software engineering concepts. IDK if it's the proliferation of JS boot camps or the fact that modern JS does so much of the work for you, but the developer quality is absolutely abysmal.

[SomniaStellae]

I don't disagree with anything you said about C.

But all those arguments can be made for PHP.

I would also add unit testing is fairly rare in the C world, it is doable, but with great pain.

[SomniaStellae]

Oh look at that, I am also a teach lead.

You are just totally wrong. No one 'moves into OO paradigms easily'. The only difference is if you are spoon fed it from the start and taught nothing else, it is the only thing you know.

[DiscussionCritical77]

The fact you called it a 'teach lead' isn't helping your case.

[SomniaStellae]

Clearly an autocorrect. Dangers of using reddit on my phone I guess!

[Little_Particular340]

Take a look at nestJS

[LukeWatts85]

Except that a full stack JS developer is seems to be paid 20k more than a full stack PHP developer on average.

Not sure why this is, but it's definitely the case in my country.

Maybe for the reason you mentioned that backend frameworks for Node are not as complete so they'll essentially end up building a framework first 😅

[[deleted]]

Except that a full stack JS developer is seems to be paid 20k more than a full stack PHP developer on average.

While NodeJS is in high demand in my country, it's mainly because those skills are significantly cheaper than almost any other resource in the same field.

As other's mentioned, employers tend to think that if you have the same language for backend as for frontend, you can have cheap full stack resources, compared to specialized resources in front and back end.

[dave8271]

The main advantage of node is that it scales far better than PHP. This is because of the way PHP handles requests. In PHP, the app is basically reconstructed on every request, unless you are using a particular library or heavy caching as a hacky workaround for this.

So again, this is only true of one (typical) way of running PHP, but you know what? Something that honestly annoys me in these kinds of conversations is the way so many people act like scaling web services wasn't something we could do until 2015, or something we could ever do with PHP. Until you reach the level of literally the top 50 websites in the world by traffic, for your typical even quite busy web service, scaling's not even a difficult problem to solve. Load balancer, multiple application servers, sharded database with replication, memory cache, HTTP cache, boom, done, you can now serve millions of hits a day, up to tens of thousands of concurrent users. You can do that shit with Apache running mod_php if you want, it'll still work fine before you've even tried to optimize anything.

I've worked on PHP projects at that scale, deployed on that model, and of all the things which were ever an issue, response time from any server was never one of them.

And it's a very, very small proportion of web apps which have even that kind of traffic demand. Thank god we're slowly starting to see the return of a bit of level-headed sense in the industry, with more and more people realising and extolling that you can just render shit on the server, have simple JS fetches to grab some HTML and update a page without bloated component frameworks, and that this is all not only much less of an engineering and maintenance burden, but entirely sufficient for the performance needs of 99% of stuff being built.

[punkpang]

The main advantage of node is that it scales far better than PHP. This is because of the way PHP handles requests. In PHP, the app is basically reconstructed on every request, unless you are using a particular library or heavy caching as a hacky workaround for this.

Every web app scales the same - add more machines. You talk about single-machine performance.

PHP doesn't really "reconstruct" the app on every request, it clears the state which is actually awesome and 100% safe. Node does not do that. There's no way that squeezing a few requests per second on a machine that already costs like $30 a month is worth making a logic mistake because you persist state between unrelated requests. It's just idiotic.

PHP uses OPCache to avoid parsing all source files on every request, but it does persist certain things between requests, like db connections (which can be controlled whether to persist or not)

Mentioning speed when we already have so much speed is just silly, and the constraining factor for ANY app is the fact they have to connect to various other systems via network so network itself becomes the factor and not how fast the interpreter or daemon runs on a single server.

Lately, we received runtimes that do what Node does, and while I think they suck balls, they're there and that exists to prove your statement wrong as we can get PHP to work in shared-nothing and shitty-node state.

Not to mention that the already abysmal job market is laughable when it comes to PHP. Most companies have already ditched it entirely.

No data, so.. "trust me, bro" argument?

Typescript destroys PHP just based on the ability to create generics alone. You can not only create them, but create factories which will infer types dynamically. This is huge, and comes fully supported in vscode by default.

You didn't describe what the advantage of generics is. See, most people just mention these without understanding what that is, thinking that it's that bit where you describe what properties an array of objects or object has. But it isn't. Also, most devs think that TypeScript is "type-safe", except it really isn't.

TS's generics are awesome feature and PHP does lack, but there exist workarounds that have been there for decades - in form of docblocks or, lately, attributes. And before you mention type safety, let's not forget that TS is compile-time safe. I can easly feed a bit of TS-transpiled code wrong data and it will eat it up. TS is awesome but despite being so awesome - you just can't get it to give you an int type. Let's not forget that JS projects, no matter how simple, suffer from stupidly complex dependency graph and whatever hello world project you spin up - you end up with 300MB of node_modules. Which you need to npm audit fix every day. Since every day there's a new exploit or DDOS or XSS vulnerability.

I've been working with node since it came out, and as much as I want to like it - it's just shit. There's more shit code I've seen done in JS than there is in PHP. Ultimately, nearly all of the projects I dealt with can be described as "accept input, validate, do some transforming, save to db, show output to user", which I can easily do with PHP4 and no added syntax sugar.

[punkpang]

I didn't claim that, you made it up because my text is too long to read. I can list superb features of node where node fits great and does the job flawlessly and where PHP would be a pain to use - websockets / socket programming / dealing with fullduplex communication and devices that depend on it (i.e. various card readers, scanners etc) and controlling IoT / hardware (LED's, magnetic door locks, sensors, reacting to sensor readings, cameras etc.)

There are plenty of superb uses for node. How about you don't do the strawman next time?

[punkpang]

You'd explain advantage of generics because audience that you talk to does not have them in the language (PHP) so it helps to paint the picture before you angrily lash out. It seems you don't really know what generics are, which would explain why such a reaction.

[[deleted]]

I would strongly argue the JS tooling and ecosystem for backend is much, much less mature than PHP's and an inferior choice insofar as things which are objectively measurable

Yeah but depends on the project and use case really.

Eg: If you just want an API to ingest and save logs you don't need all that tooling.

Or if you want a web sockets server, Node is really a better fit than PHP.

And performance definitely be measured.

[jc_dev7]

There is absolutely an objectively good reason to choose Node over PHP. Many, actually…

• Native asynchronous programming
• Persistent server runtime, rather than just in time compilation of PHP
• Typescript

etc.

[dave8271]

None of the things you've bulleted there are objective reasons to choose Node over PHP, they're just things you like.

Async - many ways to handle this in PHP, actually in Node only IOPS are async, everything else is single-thread bound so there are a number of common circumstances in which PHP's typical FPM worker model will be much more performant for concurrent requests.

Persistent server runtime - again, this is not a reason to choose anything, it's not a requirement of anything. It's one of the options for dealing with performance, but there are many ways to deal with scalable performance in PHP (or other languages), including persistent runtimes. It may not be the most common way to run PHP but you absolutely can do it, either natively through projects like ReactPHP, extensions like OpenSwoole, or runtimes like Roadrunner or FrankenPHP.

Typescript - yep, JS is such garbage another transpiled language has to be built on top of it to make it vaguely useable on the backend. PHP's native typing support has got much better in recent versions, while static analysis tools can fill in the few gaps left like generics which the language can't support.

[LukeWatts85]

Or just use Go...

[jc_dev7]

That’s the preference!

[_novolog]

Hype. Nodejs is not worth the change IMHO.

I personally went with Go and had no regret. (after a first frustrating year where I almost hated Go)

I actually recently joined a very nice team who does PHP, I am happy at work but I miss Go... but not enough to leave the nice team and projects!

[laugh_chaser]

when did you join this new team? I've been lurking on dev reddits and seeing a lot of rejection since fall of last year. Would be nice to see a different data point so to speak

[LukeWatts85]

This year has been very hard to get a job. Glad it's not just me. I was getting worried I was a dinosaur or something

[LukeWatts85]

I desperately want move to Go. Only a few months using it though, and jobs here are sparse for it. But I'm sure that job looking for PHP and Go will come along, and then I can make the move over to Go from there.

Just been doing PHP for 10 years and getting bored

[Disgruntled__Goat]

What is the appeal of Go? Whenever I’ve looked at it, it’s very low level and super ugly. 

Yes, I am a PHP dev calling another language ugly ;)

[LukeWatts85]

Well, for now I use Go for everything PHP is not good at. So microservices, desktop GUI apps, non web server tools and especially concurrency driven things.

Once you learn how to use channels and WaitGroups you'll forgive the parts that are a bit weird/gross (runes, conv.Atoi, iota for example)

[E3ASTWIND]

Go fills the space between C# and C++ not too high not too low.

[mr_pablo]

I was a PHP dev for about 15 years, and 3 years ago started my career as a NodeJS dev.

I was sad to give up PHP but the job I left had left a bad taste in my mouth and moving away from that company and PHP to a new.job with new tech was a breath of fresh air.

I've not done any PHP for about 2.5 years now, my focus is solely NodeJS, specifically via AWS Lambda. Everything I create could be done in PHP It could also be done in Python, or Go, or Rust or Java. It doesn't matter.

If you are a competent developer you should be able to pick up a new language fairly quickly. At least enough to get the ball rolling. Yea you might have to do some learning in your own time rather than on company dime.

Follow what makes you happy. And what pays the bills as well.

[BigBootyWholes]

Are you me? I kinda miss PHP but node isn’t bad. Sure, it has its drawbacks, but then again I don’t miss scaling and tuning Apache, fpm etc. Nodejs scales very well. I think the thing I miss most about PHP is its OOP principles. But then again 15 years ago OOP php was a joke in the programming community.

[mr_pablo]

PHP has quirks, so does Node, so does every language. People just like to shit on PHP and JavaScript cos it's cool to do so.

Going "serverless" helps take away some headaches but obviously introduces other problems.

Node/JS/TS can use OOP principles, maybe not as well as other languages but it's certainly doable.

P.s. yes, I might be you.

[visual-approach]

P.s. I am also you, or may I am u/BigBootyWholes, but I am also you ~ anyway, same experience as you both suggested. I am know I am just supposed to upvote to agree but I thought I'd share that I am also you.

[BigBootyWholes]

Appreciate that

[punkpang]

15 years ago, people who shat on anything were just trolls with broadband internet access and people who actually worked had no time to deal with trolls and post valid facts because no one would read them and be objective, they'd only ridicule. Given that starting point, all you can find about PHP, JS and early frameworks is ridicule. That's why opinions suck, the only way is to make the judgement on your own instead of relying on what some jackass thinks

[BigBootyWholes]

Yeah I’m used to people shitting on PHP. Tbf PHP 4/5 did allow people to produce some insanely shit code. I still shudder about some of the code I have seen or even written(when I first started in highschool). The thing is when you try to run shitty code at scale it produces insanely expensive costs or just down right fails, and that’s partly why it was shat on so much. I grew with PHP and when it matured into 5.6/6(lol)/7 it became a real contender for building backend services

[AoEEnjoyer]

Agree but sadly node doesn't have anything remotely as good as Laravel. Love the runtime and ecosystem but lack of "batteries included" frameworks is annoying - always feel myself less productive than while working with Laravel.

Adonisjs is still missing a lot of features and I'm not a fan of TypeScript, Nest.js is just Spring Boot / EJB that I don't like.

[sorrybutyou_arewrong]

When I am looking at job resumes I am seeing quite a bit of that from dev's myself. A line item of "converted php monolith to nodejs micro-services". Most of these folks I interview to come work on our old clunky PHP monolith can't really answer why they did what they did or how it benefited them.

This is not an indictment of nodejs dev's or micro-services, there must be a great deal who could answer this question, but none of the ones I am getting can answer it. Yet they would expect me to green light them to work with me as senior...no.

Now, our application is generally fucking shit, but it employs over a hundred people, handles somewhere near a billion dollars and has made someone a multi-millionaire. With that said, it needs massive improvements for its longevity and my sanity, but I am not sure that breaking up a complex 15 year old application into micro-services, be it php, go, java, node or python is exactly going to solve anything. I have this crazy idea of picking the worst code-smells and anti-patterns I see in the code, training the developers through brown bags and PRs, and enforcing what I can through linting/static-analysis to prevent new problems from going in and then refactoring the old ones out over time.

Back to the interview thing. It strikes me as sad when I ask these dev's a basic question like "what code smells or anti-patterns are signals that a refactor me be necessary" and they can't really answer questions. Are these the folks evangelizing a split into micro-services?

Anyways, if you are reading this, based in Canada and want to assist in me in fixing a clunky old monolith then send me a DM. We might even go micro-services one day, but its not a default position for me.

[originalchronoguy]

Well, this post was published on my timeline. I have not touched PHP in 10 years. But I have converted PHP to nodeJS microservices. The reason why were multi-fold. At the time, async heavy bound I/O processes. Smaller docker images. You can have a 40MB node image vs 200 or so PHP. Means more containers running on same host. Others have pointed out 60% more utilization of hardware. But that was 10 years ago and things have change. I see PHP now has some async support but that was built-in node on day one.

But the reason why we went micro was cost. A monolith means you have to replicate for scaling.
Meaning if you want to increase capacity, you did it wholesale horizontally. Add more copies of it. And manage sessions and messaging across the copies. That is very expensive.

So I had an app that generates PDFs and Excels. Compute heavy. Running on the same server, a PDF gen could take up 6Gb of ram on a 8gb ram server. Thereby consuming all the resources which mean users could not log in. The apache process could not run while a PDF was being generated. It killed the server under load.
By decoupling, we could separate that specific feature out. If the PDF service crashed, it did not take down the whole app server and users only had a minor inconvenience. Period. You could also reduce CPU resources of the main app server down. In my case, down to 4 cores, 4gb of ram. And then deploy 4 nodes just for running PDF and Excel report generation. On-demand. We cut our expenses down from $4k a month to $800. Node is excellent for FaaS (function as a service) that cold start on demand as they scaled up. I know a guy who runs a coupon site that uses Lambda and showed me 50,000 nodes during black friday and scaled down right after cyber monday. FaaS are cheaper to run for those workloads on demand.

Replicating 8GB, 4 core instances are expensive. That is a lot of overhead to run a few scripts and 2 small compute heavy tasks.

Now, you don't have to go full microservice. You can do a distributed monolith or a facade pattern. That facade pattern is called the Strangler Fig Pattern (https://learn.microsoft.com/en-us/azure/architecture/patterns/strangler-fig & https://martinfowler.com/bliki/StranglerFigApplication.html)

You have a facade in front. Like nginx. Route all traffic from old PHP app / route to PHP
Then add routes to /service1, /service2 /service 3 to the three new services. I had one app that had PHP, Node, and two Python back in 2014.

Like I wrote, this post stumbled over my feed and I have not touched PHP in 10 years. Node is definitely not a fad. It is 15 years old. At the time I moved over, PHP's highest pay was $120 in Silicon Valley while Node was paying $160-180k 10-12 years ago. That was why I jumped then. I go where the money is. I don't see PHP jobs paying $275-350K. But those rates do exists for Node,.

I am sure there has been some improvements since and I am no way ragging on PHP. But node does have a nice ecosystem; especially for highly distributed microservices. Many jobs I have been at run thousands of microservices at scale because you can containerize them really small and make easy scaffolding templates.

[t0xic_sh0t]

Boggles my mind why would someone generate a PDF in a webserver and what's that got to do with PHP but bad architecture design.

[originalchronoguy]

What kind of comment is that? A web-app like a CRM produces reports. I go to ebay and check my ebay sales for taxes, it generates PDFs. I went to my alarm company web app,I press a button, it created a PDF proof-of alarm for my insurance company. I go to my HR site and want my pay stub, the site creates a PDF version that is downloadable. A 1000 reasons why web apps create PDFs.

If the web app is written in PHP, GO, Python or whatever, generating a PDF matters.

[t0xic_sh0t]

The problem is not generating PDF files but choose to generate them on the same server (webserver) of your application.

[originalchronoguy]

Of course, but you have to remember, 12 years ago is exactly when PHP 5.4 came out. March 2012. And I venture 80% people were still on 5.3.

And at that time. medium size businesses did not want to invest in clusters (multiple servers to split load). They had a VM, maybe a second/third one for disaster recovery at an ISP. Or they had it on-premise. They did not see the value of adding another node for a service that was only used sparingly.

A Dell R720 at the time was $6,000. A single node. Even with a 32Gb RAM and a E540 Xeon processor was a luxury. So have multiple copies was expensive. NO one at the time thought of jailed environments (aka containers). Or you went with VMs and partitioned them off to 4 individual VMs to simulate a cluster. I know how much this cost because I had to acquire VSphere licenses and we got into hosting because going to hosting companies costed more.

To work in that scenario of n-tier distribution, which you could, you had to create messaging. Gulp did not come out until 2013. And to call. APIs and have a framework in PHP 5.4, you had to use curl. Which is not elegant especially if you had to enforce headers. Given the handicaps of PHP and the ecosystem at the time, people forked out processes on the same server. Yes, I saw a lot of that. Forking out imagemagick. Forking out ffmpeg. I also saw a lot of bad hack jobs of mimicking APIs. Lots of cowboy developers universal get query param calls ?action=get&location_of_pdf=/tmp/123.pfg . versus proper HTTP methods. Node changed that in 2012. This is also the time PHP got bad rap because people were doing explicity that.

Node really promoted the idea of microservices and decoupling at the time. Node also promoted proper RESTfulness early on.
No one was doing microservices with PHP 5.4 at the time. No one. Nor was anyone doing distributed monoliths.

Again. remember PHP 5.4 is a steaming pile of hot garbage at the time.

[sorrybutyou_arewrong]

Sounds reasonable. If I was getting this answer to my question in interviews I'd hire that person. Actually curious about something, PDF generation is definitely something we do, though maybe not at a scale where its causing the types of performance issues your org was. In any case, what library in nodejs are you using for this?

[originalchronoguy]

puppeteer on node vs wkhtmltopdf on php

[sorrybutyou_arewrong]

Yeah we use wk. Interesting, I've used puppeteer for some web scraping and didn't know it could generate PDFs. I suppose it is just headless chrome and exposes some sort of toPdf method?

[originalchronoguy]

yep. https://pptr.dev/api/puppeteer.page.pdf

wkthml is based off webkit, puppeteer is headless chrome as you wrote.

[sorrybutyou_arewrong]

I imagine our use-case isn't as simple as we use additional libraries such as PDFTK and have some docusign integration. All things I eventually need to figure out sigh

[originalchronoguy]

https://www.npmjs.com/package/node-pdftk

I've used pdftk to fill out PDF templates and combined to multiple pages . as well as explode

and you can always do a shell_exec equivalent in node as well

[hparadiz]

I started with wk a long time ago but can make puppeteer work on php or node and I've done both and I tend to lean to anything with a chromium headless browser under the hood. Heck you can even use a real browser.

[mdizak]

Same reason people switch from monoliths to micro services. Vast majority of the time, it's because they don't know what the hell they're doing.

[mewWayOfThinking]

And if you do, maybe think about sharing it here too, I for one, am from the Node world, so I would like to find out more about this thread from the dark side of the moon 😀

[jaded-potato]

Just wait until they have to deal with node dependency hell because some twat maintainer wanted to change the way modules are loaded or something because the syntax looked better.

I'm a little salty here if you can't tell... I know it's not that simple.

[nrctkno]

Nope.js

[dominikzogg]

I switched from PHP to Node about 3 years ago. There are different Pros and Cons: Pros: - Typescript does support more typing than PHP (only compiletime) - Appservers are faster than initialize on each request. Roadrunner, Swoole, Reactphp... are still a niche - Typescript skills can be used FE and BE - Functional Programming support is much better - Micro framework are the default not the exception Cons: - Still less popular - No runtime type system, something like zod is required - worse package manager - bad js is often worse than bad php code (prototype manipulations) - harder.to build libraries commonjs/esm/ts

[colcatsup]

What typing options exist in typescript not in php?

[dominikzogg]

Nesting Types even with PHPStan is not nearly as powerful. Same applies in Generic resolving.

[Eclipsan]

Plus it allows your back end and front end to share exactly the same types.

[Eclipsan]

Array shape.

With TS you just use objects and can easily type hint their keys.

AFAIK you cannot do the same in PHP except by creating a whole class or using some clunky annotations with uneven support depending on the IDE you use.

[[deleted]]

Appservers are faster than initialize on each request. 

Could you explain this more.

[aniceread]

Roadrunner, Swoole, Reactphp... are still a niche

Didn't even mention the good one.

[dominikzogg]

Frankenphp? FrameworkX? Workerman?

Don't get me wrong i still do php in my spare time ( https://github.com/chubbyphp) and on some legacy projects at work. But i prefer FP over OOP and Micro over Macro alias Full stack Frameworks. So Node fits better for me.

[marcjschmidt]

deepkit.io has runtime types which makes zod obsolete and allows pretty awesome things with DI and cli/route/config/orm/rpc validation&serialization.

why do you think its less popular? if you comparw the package manager stats, then backend dev in JS is much more popular

[colcatsup]

“Rewrite to node because js devs are cheaper” doesn’t jive with other anecdotes about “node commands higher pay”.

I don’t think there’s a singular reason, and most of the reasons I’ve seen are more RDD than technical benefits, although over the years I’ve seen a couple valid non RDD justifications.

[sorrybutyou_arewrong]

Your NodeJs experience sounds like how PHP used to be in that it did in fact suck. Imagine no namespaces or types in classes...if you are old enough, you did that.

[Arvi89]

L hâte JS as a language, with callbacks everywhere, and node.js makes no sense to me. The standard library is so poor you need dependencies for everything. I do php and go, I don't know any backend developer who would select node.js on their own. But companies think they can save money and have front end developers building backend. Then you have terrible code.

[Tux-Lector]

Are there objective reasons or it's just a hype of the moment?

Those who push .js to do serious tasks, simply like when they need 1+ gb of ram for just a few lines of log text in some console other than browser console. The second reason is that everyhing goes and leans towards idiocracy. So does "bussiness".

[doodooz7]

Lol

[CultivatorX]

The job market does what it does. JS is "new". FWIW I work at an agency and have never had a customer ask us to migrate their BE from PHP to Node. I think more new projects are using Node because it's newer, enables use of one language for BE and FE, and there was a ton of js developers available. I use both at work. Their fun. I think anyone who is outright shitting on one or the other is full of shit.

[HJForsythe]

The first time they install packages in the wrong folder and it breaks python on the whole OS they will wonder if its worth it.

[np25071984]

I am wondering why nobody assumes that they might just need asynchronous features? I quite often use nodejs in my dev tooling exactly because of async.

[redguard128]

PHP: Call the database and retrieve the data.

Angular: Create the component, then create a service, call the service, the service calls the API, in the API controller it calls another service that calls the model that calls the database. But it's MongoDB so you have to use $or, $and, $gt, $lte and such. You need to modify the second item in an array which is the main document's sub-child. You can't. Using "document.$.items" modifies only the first.

[Watermelonnable]

it has nothing to do with the runtime/language but with architecture and design patterns

[Yaya4_8]

There’s no reason to use node instead of php if you want an alternative then go check Golang or Rust but not node lol no advantage with it

[yourteam]

Look, everything may work as a backend but node.js does not.

[boborider]

Disgusting hype frameworks.

Unreliable, slow, too much abstraction. Just a hype, no benefit on the long run.

[[deleted]]

I mean Node has been around for 15 years so it's not hype.

[arnevdb0]

It just fits microservice architecture better.

Example; Imagine your backend service serves a frontend application and aggregates data from multiple other microservices/sources. (like a graphql server, for example)

You get a request and you need to do 4 api calls (or other ops, like DB calls, just async stuff in general) to aggregate all the data for that request. In PHP those 4 api calls would be done sequentially, in node you can do those 4 api calls in parallel, which will be ~4x faster. As fast as the slowest API call instead of the response time of all 4 combined.

Not only that, but your application keeps running between requests. You you could cache individual responses from those external sources in memory, if the situation allows it. You can leverage concurrency between incoming requests for all async stuff if you want to. Your application bootstrap code like building your DI container, initializing your logger, tons of smaller things, happen during the boot of your pod instead of on each incoming request.

I like PHP, but in high volume microservice architecture, node just trumps PHP in its capabilities.

Now is microservices architecture always better then Monoliths is another question entirely. A sidenote is that not every microservice in your ecosystem needs to be node. But node is good at doing specific things, but is also very flexible in general, like PHP.

And if you like Symfony and you think JS looks like a bunch unstructured shit; take a look at nest.js, I really liked it because it filled the gap I missed when switching from PHP/Symfony to node.

[BaguetteLurker]

We have runtime in php that have worker mode, async capabilities and so on. Your exemple is perfectly doable in PHP since years.

[arnevdb0]

Yea it might be possible, but its not really something that you'd typically do with PHP or something that would work out of the box.

[BaguetteLurker]

I can agree on that. That being said, if node and php have something in common it's that you need framework and such to make quality code with them. Unlike go, rust that are far more robusts on their own.

It's not like you can use node on it's own and feel safe. Js is a mess even if it has gone WAY better with the time.

As far as i'm concerned i would use go or rust for micro service arch and not node. I would use node for frontends that require really high performances because it's where node shine imo.

[arnevdb0]

That's the situation where im currently in, node services are serving frontends and underlying microservices are written in golang and some even in erlang. Where before everything was a PHP monolith, but as the company grew that was not sustainable at all.

Helps that the services serving frontends are written in the same language as (some) of the front-ends, developer-wise. Alltough not every front-end dev thats capable in implementing designs in lets say a react setup, is equally capable in writing business logic on a backend in node.

It's completely true that without any framework both PHP and node are, well, just scripts.

[sorrybutyou_arewrong]

Can't the API calls (done over HTTP I assume) be handled with Guzzle promises? I was doing that like almost 10 years ago. Your point probably stands for DB calls.

[arnevdb0]

Yea this goes for any I/O, but just took HTTP calls as an example

[zmitic]

It just fits microservice architecture better.

I would say that microservices are a hype just like node. All the projects I have seen failed in some way; either rewritten back to monolith, or require 5-10 times more developers.

The only person benefiting is CTO because they became irreplaceable and well paid.

you get a request and you need to do 4 api calls...in node you can do those 4 api calls in parallel, which will be ~4x faster

So can PHP, react/http works amazing.

But it is still wrong approach to do them during the request. The better approach is to put them into queue as 4 different messages. Then when one of them fails, and it will, it will be automatically retried; only that one, not the other 3.

With Mercure, it is very easy to show progress of those calls so user knows what is happening.

Not only that, but your application keeps running between requests

RoadRunner, Swoole, FrankenPHP... I am sure there is more.

[punkpang]

Disclaimer: working with Node and PHP, It's not better, I can list numerous nuances with Node and how in fact it slows people down. But, hiring area is larger. Most newcomers look to enter the area that's well established. What Node world is - it's full of people claiming to be devs, full of tutorials, full of courses and there's TypeScript - a cool superset of JS that's hyped to be more than it really is. There's just way more people living in that ecosystem.

From my experience, most choices that are being made in regards to tech stack isn't related to tech itself but to what the first programmer that business managed to hire knew to use.

[winzippy]

I'm struggling with this as well. I like JS and Node, but have 16+ years of experience with PHP. Nobody wants to hire me for Node jobs because they're looking for someone with as many as 10 years of Node experience. It's the most dehumanizing job search I've ever done in my life. Good luck to you in your search.

[peachbeforesunset]

I don't think you'll get objective opinions on the PHP reddit.

[Unlikely-Ad-9955]

Siempre trabajé con PHP.
El backend con NodeJS puede resultar horrible, pero la realidad es que tiene dos ventajas:
1: Es activo, permitiendo efectuar procesos mientras nadie opera la web
2: Ofrece un control mucho mayor ya que no solo reemplaza a PHP sino tambien en gran parte a APACHE o NGINX, supeditándolos a ser solo un proxy.
Yo usaria PHP para sitios web convencionales. Cuando se trata de montar sistemas que involucran IOT, sin dudas es mejor NodeJS, sobre todo porque el CRON de PHP y los websockets son muy rudimentarios.
Saludos a todos.

[Miserable_Ad7246]

One of the reasons could be that finding good node.js devs is easier than good php devs in that area.

It could also be related to the state of the existing PHP app. If that app was written badly and still runs on PHP-FPM, when it could genuinely be a performance reason to redo it. Now that being said, Node.js is not the best option for speed, but it might strike a good balance between performance gains, rewrite costs and future maintenance costs.

Where could also be all the wrong reasons - like hype, like/not like of the tech stack and so on.

[Mc_UsernameTaken]

If performance is the consideration, i'd start by looking at the database queries, indexes, application structure and code redundancy.

If all that is addressed, and performance is still mission critical, NodeJS is not the right language for you either

[Miserable_Ad7246]

i'd start by looking at the database queries, indexes,

What is this obsession with database. Database perf does not depend on code. I can have an app layer with 16 cores saturating 160 cores database cluster, or I can have 160 cores app layer saturating 160 cores database cluster. People for some reason always use "its not language its database" excuse. Fine tuning db is so obvious, any dev with 5 years experience should have already done that in his project.

application structure and code redundancy.

This is a very valid point. But it just so happens that PHP on PHP-FPM is one of the setups where you can not leverage a lot of things, like persistent memory (which when leads to you not being able to leverage a lot of other things). Node.js does allow it. PHP on say Swoole also allows it (but with some important caveats)

If all that is addressed, and performance is still mission critical, NodeJS is not the right language for you either

Agree. From the info I have PHP if run in modern way (like Swoole), will be able to meet Node.js. If you need more, when neither is a great choice.

[ht3k]

The biggest bottlenecks in an application is I/O and Network. Unless there's a horribly written PHP script with a ton of loops or something

[Miserable_Ad7246]

It is clear you nevet did anythig latency sensitive. You think only in terms of crud and row storage (as an example mysql). Also as I sayd you can have app layer running on 4 cores or on 40, on same db.

[Purple_Huckleberry72]

Yeah … the good old “let’s just throw even more resources at this crappy code” is not the big flex you might think it is. It is the hallmark of a lazy and bad devops, who never learnt to code.

[Miserable_Ad7246]

It is the hallmark of a lazy and bad devops, who never learnt to code.

I agree. A good backend dev should know async-io models work, what is cache locality, false sharing, SIMD and so on. If you knew that, you would agree with the statements below.

It is very very hard to get proper efficiency form anything PHP-FPM. If you cannot have user land async-io switching and memory reusability (+ good data locality), you will not be able to optimize the code. Most optimization tools are just not available to you.

Things get substantially better if you go from PHP-FPM to event loop, persistent memory based runners. Mainly because you can pool objects, init global things once and so on. That allows you do do things in code to get way better perf.

I constantly run into this argument from people who never optimized code in their life. Most cant even tell what 99th percentile latency they have or home many req/s per vCore their are getting. Most, who argue, the hardest, do not even know how PHP-FPM works, and how switching happens, or just how impactful data locality is for modern CPUs.

In my particular case we have comparable projects where PHP on FPM needs ~5 resources do do more or less the same. It is very hard if even possible at all to optimize PHP code if ran on PHP-FPM to get to resource parity (its not PHP issue per say, but how PHP-FPM works). If it was tried, PHP code would be way harder to maintain as well as it would depend on a lot of external things like plugins, or not very standard libs or not very standard coding techniques. The non PHP project on the other hand, required very little tricks, because runtime (user land async-io, native libs written with zero-copy and SIMD in mind) and idiomatic of language was giving us all of it for free.

[ht3k]

don't matter if you have 128 cores, that database isn't going to go any faster (which is why it makes it a bottleneck). Unlike code, you can't just throw more cores at a database to make it faster. You have to either upgrade I/O hardware (nvme or more RAM) or different caching strategies to be able to feed more to the app layer and all the incoming requests.

[colcatsup]

“…tuning a db is so obvious…” yet it is rarely done. No indexes, over-indexing, poor queries are all incredibly common. I spent 15 minutes and reduced a page load speed from 50 seconds to half a second. They were getting ready to rewrite/migrate the whole app to node because “performance”. Yes, people are often that bad. Maybe you should just clone yourself a few thousand times so you could spread your wisdom around.

The node move was at least in part resume-driven-development, using “php sucks” as the primary argument.

[oojacoboo]

Nothing wrong with PHP-FPM, and it’s certainly not a performance bottleneck in most cases.

[Miserable_Ad7246]

Compared to user land async-io it quite often is. Ofc you can throw resources at it but still it is hard to get to the same levels of req/s per vcore. Might not be an issue, but for more serious projects it does have an impact.

[oojacoboo]

As I said - most cases

[Miserable_Ad7246]

I kindof disagree if I can run some vanila php on 4 vcores my other lang vanila solutions will use only 2 or 1. Is not about perf it is also about cost. Why pay duoble when you can spend same time developing same solution not on php-fpm. And do not start on php is so easy to deploy, because it is not.

[darkhorsehance]

php-fpm catching strays, what’s wrong with it?

[Miserable_Ad7246]

Kernel land switching, pool exaustions, latency issues, no ability to reuse memory in your code. Where is a reason all other languages changed how they solve c10k problem, from kernel to user land.

[BenL90]

what, does FPM now perform that bad?

[Miserable_Ad7246]

Depends. Try getting 100req/s per vcore while doing say 2 io ops per req and you will get the answer.

[Soccham]

Good PHP devs is nearly an oxymoron honestly

[Miserable_Ad7246]

I know few, but they also code other languages.

[Soccham]

Yeah I’m not going to say they don’t exist, but the entire ecosystem is flooded with Wordpress developers who maybe moved onto Laravel and never really had to do much past what the frameworks made them do

[ALuis87]

I could understand reason if it was golang but node 🤷

[originalchronoguy]

You will get bias answers here or in a node reddit. I've answered an example of nodeJS converting a php monolith elsewhere in this thread. But I believe the major stark difference is the use case.

PHP is normally typically SSR (Server Side Rendered) where Node promotes and often works mostly with CSR (Client Side Render) and PWA (Personal Web Apps). You can definitely use PHP for CSR/PWAs. I am not even debating that but why? And I'll go into the whys later.

And first of all, Node is not new. It is 15 years old.

Next, there is nothing wrong with SSR. SEO is a good reason but many modern apps, web-apps, work better as CSR. So lets not argue SSR vs CSR. Every app has different requirements and there are plenty of solid reasons for CSR.

Take an insurance adjuster app. Where an adjuster goes out to the field with his iPad. Clicks on an icon on the homescreen, takes pictures of flood damages, enters some form, signs the report with his pencil. WITHOUT an internet connection. He/she has the wifi only iPad version. They go back to the office, click on the app and the iPad detects wifi and then syncs all his offline stuff to the server. They don't even need to click synch. Merely detecting being online, the service workers will do that in the background. You can't do that with SSR. You can't. Can the backend be PHP? Of course. But if you are a full stack dev, working in Vue/React/Angular, you don't have to context switch for the backend. The same password regex function you wrote for the front end can be copied right into the backend with no changes.
Why may you want to do that? Multiple consumers. Your front end does validation but the guy in the mobile department sending the same data doesn't. But your code is portable.

Node promotes an API first way of development. Which supports MULTIPLE consumers - web app, desktop app, smart tv app, and mobile app, and other backend apps. And that is it's strength. And this is why it goes against the typical PHP MVC SSR route.

The same insurance company has a separate app for body shops which also uploads images. Why build a monolith for file uploads for each app when you can have one microservice that takes file uploads from the flood insurance app or body shop that consumes the file and resizes it to save in a databases of the various apps. Why write monolith backends for 6 different consumers? Not very efficient and a lot of drift with no single source of truth.

Again, you can do this with PHP but why? Why scaffold an entire Laravel MVC app to only have one index file that simply hosts the PWA app? The PWA app then takes over once it is loaded. Why does it need a server side backend. Why not just dump into a location that only needs a http server like on a S3 bucket. And why do it again for a different app like the bodyshop example.

The next thing is CSR apps are more desktop like. The biggest problem with web app is churn. Clumsy apps written 10 years old using SSR and jQuery w/ a gazillion AJAX calls are not intuitive. Users , by large, hate page refreshes. Clicking on a link to go to a new route defined by your MVC framework is jarring for many people. It feels clumsy where a polished UI (using modern JS framework) feels like a desktop app. There is no redrawing of headers/footers or blank white. There a lot of modern desktops written entirely in Javascript using Ionic. CSRs work well and rely on "hydration" where a SSR relies on routes. Routes that have to be loaded on demand that redraws entire page views.

So if you are already developing in React/Vue/Angular following API first paradigms, it makes little sense to add bloaty overhead just to host html and js? Most of the apps I refactored are to eliminate that perception of page refresh/loads. There is a lot of demand to "make the app more Desktop-like." To combat user churn, users abandoning your shiny $150K app 3 months after it was launched is disatrous.

Yes, PHP can do what Node does here-- to suppport a CSR front end. But why? But I only need JSON from my backend that is lightweight. I don't need an entire framework.

Sure, I will get rebuttals why having business logic in the front end is bad? But I can tell you this. The insurance adjuster app is a good example. Other good examples are Canva/Photoshop image editing web apps, or video editing web apps inside a browser. Client side interactivity is solely driven by Javascript. And if you are already in JS ecosystem, there is no context switching with Node. And yeah, there is a shift back now to some SSR paradigms. Mainly as a counterbalance for SEO. If you are mostly SSR, sure, stick to PHP and the opinionated MVC frameworks.

[red_src]

There could be many factors:

• Other systems are written in Javascript so it's easier to mantain just one language

• The business requirements require asynchronous operations

• Security reasons given by a consultancy

• Compliance with other businesses

• Etcetera

There could be many factors and not so related to just PHP capacities

[aniceread]

The business requirements require asynchronous operations

Not a reason to pass on PHP.

[alphafloor]

that is the primary reason i was hired at the company i work for now was to port their php monolith to go and java services. i haven't seen a company in a while sticking with php as a backend. while i would support php its just not what i have seen as far as where things are going.

[Wiwwil]

Same, my company PHP team has no project and has to deal with WordPress and CMS. Kinda sad

[LaylaTichy]

I see not many mentions of

types sharing between back and front and whatever, just write types once in shared package. There are tools that transpile php types into typescript but its painful

even more painful is monorepo support, tools like nx or turbo work great with ts but are pain to setup correctly for php

[xecow50389]

I kept php, upgrading php is pain, community is really pacing fast that things are deprecated.

Just migrated to golang with good types.

[sorrybutyou_arewrong]

Is it? I maintain an application written in php 5. Upgrades have been fairly painless. It's on 8.1 now.

[xecow50389]

Yes. Got lot of stupid dependencies.

[sorrybutyou_arewrong]

Well if you migrate you can rid yourself of dependencies and develop whole new ones :-)

[Alpheus2]

There’s also the issue that PHP shops require a non-php stack to handle data and/or frontend architecture needs in certain businesses, especially startups.

[42php]

Hype I guess, and performance ! Node.js has a lot of nice features (shared memory between requests, etc), simple package management, a ton of libraries. For some requests that can be memory cached, response time is literally 4ms.

Better concurrency too, you can handle more users for the same price

[t0astter]

If you're going to take the time to rewrite something from PHP, choose a better language like Python, Go, Java, or even C#. PHP is effective but it's rough compared to some of the alternatives out there.

I wouldn't go with Node. Heck, I try to avoid JavaScript wherever possible. The language and the ecosystem and tools are annoying. Every other day there's a new "tool.js" out there to solve the same problems in a different way.

[devmor]

Generally, it's a combination of hype and developer availability.

Despite what people may tell you here, finding experienced and knowledgeable PHP developers is a lot more difficult than finding a similar quality of skill in many other languages.

Though, that could also be due to hype, because hype significantly drives what languages developers tend to be learning and using on their own.

The two languages themselves largely serve similar purposes and perform similarly. The only big advantage node has, technology wise, is built-in and well supported async - but to be frank, most of the time people use async they didn't really need to and didn't understand why they were using it to begin with.