SignalR is a "client and server library for .NET that provides messaging and abstraction over a persistent connection." This is not magic, your asynchronous code does - it just allows your server to invoke clients asynchronously (including JavaScript executed in user browsers).
However, C # 5.0, which comes in .NET 4.5 and Visual Studio 2012 (as well as in Mono 2.11+) allows you to write / modify code to be asynchronous using the new async and await keywords.
If you are already a .NET developer, C # async is waiting, and SignalR is very easy to pick up, learn and run, which allows you to create highly scalable and very high-performance systems.
Node.js allows you to write your own JavaScript code and host it on the application server.
Node is getting a lot of attention at the moment, but if you come from the background of .NET development, it is worth noting some of the things that may surprise / annoy you when switching to JavaScript on the server:
JavaScript is a very powerful and extremely flexible dynamically typed language. However, this flexibility can be very dangerous and problematic until you recognize its many shortcomings and how to overcome them. If you SHOULD execute JavaScript code, consider writing a source in languages such as TypeScript and CoffeeScript that come down to JavaScript but isolate you from the many dangers of JavaScript.
Although node offers great features for sending asynchronous messages, its code execution performance may be FAR slower than C # execution. If your code has little or no data processing, you may not notice this problem. If, however, your code does enough data / computation / analysis / etc, you may find that node performance with a JavaScript error is not acceptable.
Node is single threaded! If your code needs to do some heavy processing, for example, performing complex calculations on a lot of data, this will prevent one node instance from showing other incoming requests until each processing operation completes. Thus, you will need to plan to enable Node clustering (currently an experimental feature) or , if you host node on Windows , use IIS and IISNode] 4 , which handles node instance management using the (amazing) IIS infrastructure and Windows Process Activation .
Compared to the typical debugging experience of .NET developers, debugging code running under a node is a slow and cumbersome process right now. To do this, you need to use the node inspector and the Chrome web browser to debug the code, but a bad experience: breakpoints are not saved in all runs; conditional breakpoints are not supported; the displayed call stack is shallow; etc.