>Node uses single application thread and uses ansynchronous scheduling to IO bound operations to distributed load. It basically offloads I/O operations to async callbacks that process off the single thread and only return when those callbacks complete. Since I/O operations tend to take up the vast percentage of typical Web request processing the idea is that by only running that small percentage on a single thread and letting async I/O handle the rest, is very resource effficent. However, if any of those callbacks or main line code are CPU bound and run synchronous code that is slow (like tight calculation loops), the main thread that handles the scheduling and offloading locks up and everything comes to a standstill.
>
>IOW, Node DEPENDS on async callback operations to execute very, very quickly. If you have to run code in tight loops or manipulate data after it comes back for a data request that can put a serious strain on the abillty for Node to handle many requests simultaneously. Most Node libraries are designed for this, but user code can still very easily cause terrible performance.
>
>Further because everything in Node is async, it requires a whole new way of thinking and designing applications that is VERY different than just about anything else. You basically end up doing nested callbacks (closures in JavaScript) and without using some special language tools that can help scheduling these callbacks Node code gets very complex to manage very quickly. Imaging running multiple database calls and nesting the the async results for example - it can get out of hand very quickly.
>
>Node has some very good uses cases - especially with feeding and retrieving small transnational data operations, but it's not a solution for long running operations or complex server side user processing tasks.
>
>It's a very different way to think and design apps.
>
>Like you I'm not convinced that 'old school backends' like .NET, Ruby or Java are really in need of replacement with something like Node. I don't think Node is a solution for the types of problems these backends solve. I honestly don't think you'd want to use Node for building HTML backends (although people are doing that with Express). Node is just not optimal for that. Node is really good at small data feeds - connecting to a NoSql backend and returning the resulting JSON data to an HTML front end, or handling persistent connections to 1000s of user - that's the sort of thing Node excels at because it can basically offload all those operations to the async services that it interfaces with.
>
>All of this is about performance and load which supposedly is better with Node. I think the jury is still out on that long term. While I think for most applications this sort of performance advantage doesn't really matter, it does matter for cloud computing on platforms like Azure, or Amazon etc. as you pay for the resource usage. If you host your own servers, old school solutions are almost always good enough and provide easier development paths. I can't remember the last time I really ran into resource constraints even with really, really busy back end applications. But if you host with cloud providers, lower CPU cycles means you're paying less money and those same providers use less resources and electricity etc.
>
>As is the case with most of bleeding edge tech though, I think a lot of concepts of Node are going to migrate back into other tools and solutions. For example, .NET is already heading into a much more async server stack for new technology like Web API and SignalR, that uses similar constructs to Node and provides the benefits of async while not requiring it and still offering good performance if you don't do async...
>
>
>+++ Rick ---
>

Thank you, Rick for that lucid explanation of a complex topic.
Very helpful.


>>>One thing to consider is that Node.js is not just a language you're learning but a whole different way of doing things. Node.js is also not a general purpose backend - it works well for certain high throughput scenarios but it's terrible for CPU bound processing (ie. anything sequential that's not truly asynchronous). It's great to learn Node and use it for things where it makes sense, but as a one stop solution that's a very bad choice.
>>
>>Hi Rick,
>>
>>Thanks a lot for dropping in.
>>
>>"it's terrible for CPU bound processing... Node and use it for things where it makes sense, but as a one stop solution that's a very bad choice."
>>
>>I understand that js engines have made impressive steps forward. However I still fail to understand what javascript can provide on the backend that, say, java, python, ruby or C# and al... Since as most of us I do appreciate your communication skills when it comes to complex IT matters, I'd be glad you could be a little more specific on the subject.
>>
>>What is nodes.js, and server js by the way, bringing than the current toolset I am aware of (java, python, ruby....) and others are not? Id' be glad to get your javascript, where it currently stand in the arena and where are we possibly heading to?
>>
>>Regards from Paris:)
>>
>>François
>>
>>PS: My background on those issues: server side vfp à la foxisapi and west-wind and python servlets à modpython. All this was years ago... Not currently working on server code..