You can get a lot of scale out of an application by simply increasing your hosting options and hiring an effective operations person to manage your servers. If you're really lucky, something terrible will happen, which is success. You don't have to worry about scale because probably this thing you build isn't going to be the thing you want and all that effort worrying about scale is wasted work. What you don't have at the beginning is scaling problems. At about 3:45 he talks about how a new application doesn't need to worry about scale. There's a spectacular talk given by Laurie Voss at this year's FluentConf about how npm split their monolithic application into microservices. Only a tiny tiny percentage of applications ever get enough traffic that they even have to worry about having more than one server, much less whether their technology choices are wrong. If you are building a brand new site that has no traction what-so-ever, worrying about performance scaling of your initial language choice is premature optimization. However, you are asking the wrong question. I suspect that if all other factors were equal (such as database performance and code structure), a NodeJS application would outperform this setup with less hardware, but I don't know this for a fact. MyFitnessPal is built with Ruby on Rails, running on Phusion Passenger to improve Ruby's concurrency. Every major backend language can deliver a site efficiently given the right tech stack, good engineering, and enough hardware. In terms of response time, the language and runtime used for the backend have significantly less impact on a site than the way the site is architectured.

Sites like myfitnesspal