I've seen it being used in quite a number of places now (specially startups) and I don't get why people use it over other stacks which might be easier to maintain and code. Here are couple of things that comes to mind<p>- Most startups have inexperienced people writing async code (which is hard) and make too many mistakes<p>- The reason Javascript is used in frontend let's use it for backend (even using the same programmer) seems flawed. Backend programming would require intimate knowledge of threads, mutexes, async and other things which a frontend programmer may not be familiar with so using the same programmer or language may be moot.<p>- Flaky drivers. Surely it works great with MongoDB but try using MariaDB, Postgres with concurrency and pooling and there are so many issues (async is hard ?).<p>- Is Node.js performance really that good when people start making mistakes and bugs arise that infact hinders performance. Why people move to Node.js when horizontal scaling can provide sufficient performance needed by most.<p>These are only couple of points, may be Hackernews can give more perspective towards why some of the people/companies choose Node.js with these flaws. Is it because it's new or the love of Javascript (designed in less than 1 month) is so much that it has bleed into the backend realm.
It's a fad (which is fading in favor of Go). A few comments:<p><i>Backend programming would require intimate knowledge of threads, mutexes, async...</i><p>Not if they use Node.js. One reason to use it is that it doesn't allow you to use threads or to even decide whether to use threads or not.<p><i>Surely it works great with MongoDB...</i><p>And that's what people use.<p><i>Is Node.js performance really that good...</i><p>People who choose programming languages based on hype are never going to get good performance anyway, so it doesn't matter.
> when people start making mistakes and bugs arise that infact hinders performance<p>That statement is true of any language stack.<p>> The reason Javascript is used in frontend let's use it for backend (even using the same programmer) seems flawed<p>I am a backend dev at my company and we use Node.js, and I can tell you while the frontenders are not great at knowing the APIs of the internal Node.js modules, for example, but can provide great PR reviews of the code in general, for overall logic, flow and readability.<p>As for your statements regarding in general, I think you'll find quite a bit of people in various orgs who do not know a ton about the intimate details of threading but are for example backenders using RoR, and they just install a server like Puma or Unicorn to abstract away a lot of that complexity.