I’ve been working with Javascript a great deal in the last year. I’ve recently worked on two web applications that were both written purely in Javascript (which were exposed using NodeJS) and two other web applications whose UI were purely javascript, with alternative back-ends (such as C# Web API services). I think NodeJS is great, but definitely have some reservations in using them for projects requiring complicated server-side logic.
The (debatably forced) extensive use of asynchronous threading can make complicated logic very difficult to write. Anything requiring interaction between more than three controllers or external APIs ends up causing your code to nest many levels deep; also making the code very difficult to read and document. And if you are attempting to join MongoDB collections, good luck; it gets ugly.
However, I was recently introduced to a pretty cool pattern called the “Promise Pattern”. Essentially, a function can immediately return a promise and asynchronous methods executed within the method can resolve (success) or reject (fail) the promise at any time. When you call a function that returns a promise, you know that it will either return a success or failure and can even chain the promise calls so that they occur in a specific order of operations. This helps quite a bit, and may prove to be a great solution the problem I mention previously. However, I’ve only been recently introduced to this pattern and can’t say I have a great deal of experience with it yet.
The other major issue I see is more of a general issue; javascript has not been developed for use on servers for very long. It’s still very young in the world of server functionality. Many things that would be otherwise easy to do in Java or .NET are far more difficult or even impossible in NodeJS (or Javascript in general). One specific example is with XML schema validation and XML transformations. I never ended up finding any modules with more than a basic level of support for XML schema validation; missing functionality for namespaces and modularized schemas (the use of xs:import). Similarly, I never found a suitable module for transforming XML.
For the project which I needed to validate and transform XML, we were unfortunately too far into development and needed any solution. The solution I found ended up leading me back to other technologies (in this case, C#). As it turns out, there is a really cool little NodeJS module called Edge.JS which allows you to run C# code within NodeJS. Having had a great deal of experience validating and transforming XML with C# (and even having already developed code that did what I needed), I used Edge.JS to run my C# assemblies in our NodeJS application. It was a bit ugly, but it worked – and it was a prototype, so we were OK with the inconsistent use of technologies.
In summary, I believe NodeJS is the future (or rather, technologies like NodeJS), but I think it has a ways to go before being ready for production use in anything more than a basic web application. The best combination I have seen so far is a C# Web API service for the back-end (maybe coupled with SQL Server and Entity Framework) and a Javascript-based (bootstrap, knockout, etc.) front-end.