Feed
It would be interesting to have some specific examples of things Node is bad at. Node is not good for CPU intensive tasks? What tasks exactly? And is this really true? What is better for the same task? How much better? I agree that there are some strange edge cases where node is bad compared to native pure C. But would you ever encounter those cases in real life? I think Node is underrated. It can do a lot more than people think it can. Its bindings with native C++ make it very efficient. The things it can not do well are very few. And if there are such things, someone will write another C++ module that will solve those problems in one of the next versions and it will become fast. Or at least as fast as other options a dev team may have.
Node.js became quick famous not just alone; this hype came with changing trend in the web application development industry. As rightly stated by “Justin Njoh”, node.js got its glory with upcoming technologies like BigData, NoSQL etc.
On other-side coding in JavaScript on server was another reason for node.js to get so fast. Node.js with package of MongoDB / AngularJS is being a more famous for web applications. One has to know where it is to be used and where not. it’s not overrated…
Thanku for sharing this useful information.. I would like to share something too...
Thinkwik is an expertise driven web and mobile apps Development Company helping businesses achieve their goal through robust and engaging web and mobile presence. To Build real time application, mobile app and website
<a href=“thinkwik.com/node-js-framework-development/%E2%80… Js Development Company</a> <a href=“thinkwik.com/android-application-development/%E2%… App Development</a> <a href=“thinkwik.com/iphone-application-development/%E2%8… App Development</a>
"Right tool for the job" gets bandied about way too much, when the reality I see too often is that most developers making these decisions don't know how to choose a 'right tool'. They usually don't have enough experience with different technologies not enough understanding about the requirements to make a good choice. Another aspect is team - the "right tool" for a .NET shop that needs to get out a stable and long-lived tool is probably .NET, not the latest/greatest tech that one intern raves about after hitting a local tech meetup.
I've also known way too many devs practice resume-driven-development, choosing new/flashy tech primarily so they can learn it, but justifying the decision with benchmarks and other fluff. To some degree I've been guilty of this myself in years gone by, but have been involved in too many maintenance projects to see the downsides of this.