Why should I use SignalR?

In traditional web programming, the way a web application interacts with its web server is to refresh the page, adding information to the request in the form of the querystring or form data. While this was a good solution for building applications on the World Wide Web (a platform that was initially intended for static pages), it has a few problems- it's slow, it's not very fault tolerant, it makes grossly inefficient use of bandwidth and server resources, and it makes the browser's Refresh and Back buttons do bad things to your app.

A more efficient solution would be to have the browser and server communicate in real time, sending only the data needed- not using a page request to drive the application, not reloading the whole page every time data are needed, and not mucking around with the browser's page navigation system. There are several low-level transports that can provide this functionality, and several high-level technologies that can make using the low-level technologies easier to manage. Two of these high-level technologies are Meteor and Node.JS- they have the advantage that a single language is used on both client and server, but the disadvantage that the language in question is JavaScript.

SignalR, on the other hand, is a high-level library that gives you the flexibility and power of the .NET framework on the server, whether you prefer C#, VB.NET, or any other language that .NET supports. The client will typically be JavaScript running in a browser, but clients can also be built for .NET, Windows Phone, Silverlight, and iOS.

The efficiency that can be achieved with a streamlined library like SignalR is impressive, as compared to a standard HTTP connection. For an example of how quickly SignalR can process message throughput, see the realtime arcade-style game ShootR, at the SignalR site.