It is hard to argue against these numbers. It's actually quite easy to argue with those numbers. They're not measuring what you think they're measuring. See g

It is hard to argue against these numbers. It's actually quite easy to argue with those numbers. They're not measuring what you think they're measuring. See github's bad language detection if I put jquery in git. Also, number of modules available does not imply utility, quality or size, nor take into consideration the utility quality and size of standard libraries. There is no acknowledgement that there is a domain where javascript is the only option, and that adoption is not by choice but out of necessity (in which case, there is no reason to argue for a language, you're either building for that domain or not). There is no distinguishing between frontend and backend javascript. Growth on the frontend is not a case for node.js. Unless I'm assuming I'll use the exact same employees for both, that they only know JS and that they're so worthless they can't pick up a second language that is probably very close to javascript evolutionarily. The above points were specific, but the overall argument presented is that javascript is undergoing rapid growth. Not a great reason to jump on a technology, but even if you're willing to jump on something just because it's growing, it doesn't look at the context of _WHY_ it just started growing. It is crucial to understand the pros and cons of using JavaScript. Well yes, but that's a gimmie, it's crucial to understand the pros and cons of just about everything in your field. It would have been nice had this article gone into those pros and cons, but this was not a business case for JavaScript. It was a persuasive essay that the reader should evaluate JS on their own and possibly create a business case for it.