> Do you know why it's a resource hog? Is it the nature of Ruby (that appears to be what they use) vs php, or is it because it tries to be an SPA that has no pagination?

Ruby dev for 15 years here. Ruby is definitely slow, but in 2022 it's "tens of milliseconds to answer an HTTP request" slow.

They chose a javascript framework that turned out to be outrageously slow.

I found that my Discourse instance consistently took ~250 milliseconds to display the forum post list (according to the little box at the top left corner). After getting annoyed with Discourse, I went back to Invision Forum and I see about ~95 ms for the same thing, including sending the response to my browser.

Those are both unreasonably slow in a way that has little to do with the language.

Optimizing responses has diminishing returns once you're below 100ms, but 250ms is far too slow.

Ruby is not necessarily more resource hogging than PHP, but the way typical ruby webapps deployed (all workers processes started immediately and left idling to wait for requests) leads to higher memory usage compared to low traffic PHP webapp (worker processes only started when requests is coming and shutdown afterwards, so you can host a lot of small traffics sites in a small server). If PHP webapps are deployed with similar process lifecycle, I imagine it would consume similar resources.

For medium and high traffic webapps, the difference is moot because you're going to end up with a large amount of worker processes to handle all those traffics anyway regardless of how you initially spawn them.