94

Since I've known about Node.js, I've always been a fan of it. But today I found about SignalR, which provides an alternative asynchronous - scalable - realtime model for ASP.NET.

As far as I know, the main advantage of Node.js over SignalR is sharing code between client-server (another advantage should be that it is cross-platform), and the main advantage of SignalR is a much more mature framework and far better tool (IDE) support. So I wonder: if SignalR is here, do we need Node.js on Windows anymore? Are there any advantages of Node.js I don't know?

Cel Skeggs
  • 1,827
  • 21
  • 38
Delta76
  • 13,931
  • 30
  • 95
  • 128
  • 32
    There seems to be some confusion here. Node.js is a development platform whilst SignalR is a library for ASP.NET. A better comparison would be node.js+socket.io vs ASP.NET+SignalR. Could this question please be updated to clarify? – leggetter Jan 30 '12 at 19:46
  • 6
    True and false, SignalR is a library for .NET. – davidfowl Feb 17 '12 at 10:04

1 Answers1

113

SignalR is a viable alternative to Socket.IO and Node.js. There are other reasons to use javascript on the server however.

  1. It flattens the stack. Almost any website these days has to have javascript on the browser, and if you use it on the server as well, you can cut one language out of the batch that you'll have to be proficient in.

  2. Message passing is very natural. JSON Everywhere! Especially combined with a document database which uses JSON, all message passing just becomes JSON objects. This makes reduces the amount of message brokering that has to happen throughout the system.

  3. It's not Microsoft. I personally love what Microsoft has done for the development community. They make fantastic tools and one of the best frameworks and languages around. That being said, some people just love to hate Microsoft.

  4. Cost. There are many good ways to get Microsoft tools for free or very cheap (Express editions and Biz Spark). There is still a higher cost associated with working with Microsoft tools. I believe this cost is worth the productivity gains in most instances, but not everyone agrees.

In addition to the above, there is still the story going around that you can't scale long polling requests on IIS due to the threading model. This has some truth to it, but with good code design, and some server tweaks, you can mostly get around these problems.

Timothy Strimple
  • 22,920
  • 6
  • 69
  • 76
  • 6
    I read Hanselman's blog entry http://www.hanselman.com/blog/AsynchronousScalableWebApplicationsWithRealtimePersistentLongrunningConnectionsWithSignalR.aspx that an ASP.NET/SignalR chat application can serve tens or hundreds of thousands clients, which is really amazing. I didn't dig deeper to see how they do that, but it's close with how "scalable" Nodejs can do... – Delta76 Jan 30 '12 at 09:30
  • 2
    What do you mean "_flattens the stack_" ? – Royi Namir Dec 21 '12 at 16:53
  • 7
    If you're using something like ASP.NET MVC you need to know JavaScript, HTML, CSS, C#, and Visual Studio. With JavaScript on the server side you can reduce it to JavaScript, HTML, CSS. – Daniel Lidström Jan 04 '13 at 15:47
  • 4
    asp.net and .net in general is actually not a MS only thing. Check out sharpdevelop and monodevelop for IDEs and mono for a alternative .net runtime. This takes out points 3&4. Also, I don't believe in the one language paradigm thingy. It's not hard to learn multiple languages unless you're just starting out. As for 2, creating a .net object from JSON is really not that hard. Also, checkout out SignalR for a long polling & realtime communication replacement – bbqchickenrobot Mar 03 '13 at 23:32
  • 1
    @bbqchickenrobot I call out SignalR in the very first sentence, and then go on to play devil's advocate as to why someone might choose Node.JS over ASP.NET + SignalR. Keep in mind this question was answered over a year ago, and SignalR hasn't had Mono support in the Master branch until a couple months ago. – Timothy Strimple Mar 04 '13 at 00:23
  • 1
    True, just added my .02 - for any others that may be persuaded by the anti M$ dogma, etc... – bbqchickenrobot Apr 20 '13 at 20:16
  • For those of us that care about the open source ethos - Node.js is open source. The SignalR project is open source, but unless you use mono, the ASP.NET stuff it uses is not. – ruffrey Jul 11 '13 at 21:57
  • 7
    @ruffrey You were saying? http://www.asp.net/open-source You can also self host SignalR using OWIN. – Timothy Strimple Jul 12 '13 at 03:32
  • thanks @TimothyStrimple, it is nice to know there are even more options for open source asp.net components since SignalR projects typically leverage .net – ruffrey Jul 12 '13 at 14:43
  • However as far as I can tell, the core MS .NET framework is not open source, while many products using .NET and built by MS are open source http://www.microsoft.com/opensource/directory.aspx – ruffrey Jul 12 '13 at 14:50
  • 3
    In response about cost, if you're working with "Enterprise" systems, there is a very good chance you will work with SQL Server, Oracle and DB2. Don't forget that .NET has very mature and stable libraries for working with these databases. I can't say the same about JavaScript. Having tried to get JavaScript to work efficiently with SQL Server in the past was frustrating. Not sure how much money I was saving then. Plus, it seems the world assumes that if you use Node.js, you use MongoDB. I love MongoDB. But try getting MongoDB to replace our $8m WMS running on DB2. – cbmeeks Dec 18 '13 at 19:39
  • 4
    @cbmeeks Different tools for different jobs. I guarantee you that Walmart has a pretty serious (and expensive) database setup behind the scenes, but that hasn't prevented them from optimizing their mobile website with Node.js. You'll probably find that is true of all the large enterprises successfully deploying Node.js. I doubt many of them have anything stored in Mongo. – Timothy Strimple Dec 18 '13 at 22:38
  • Interesting that these are the best reasons for preferring Node.js because 1. most developers have more than js in their toolbox 2. JSON does not require js 3. hating MS for being MS is for the political/proud, not productive and 4. cost does not scale with app. That said, I've been disenchanted with MS recently because of their disdain for lightweight frameworks (e.g. SOAP/REST, XML/JSON - and more recently killing Linq to SQL [which is awesome] for the bloated EF). Their focus is big business and not those living in the long tail. So, I'll keep looking for the silver bullet. – bob Jan 15 '14 at 01:16
  • 3
    @bob There is no silver bullet. The dirty secret is anything you can accomplish with one language you can accomplish with another. Some are more suited to certain tasks, but for the vast majority of projects out there, the choice of language doesn't matter. Pick what your development team is good at and happy with. Regarding MS and the disdain for lightweight frameworks... I just don't see it. WebApi is a good option for a light weight API framework. EF is also not bloated (comparatively speaking) and is better than LINQ to SQL in many ways. – Timothy Strimple Jan 15 '14 at 01:56
  • @TimothyStrimple WebApi is nice but is 10 years late to the party - and still prefers xml to json. EF is quirky and since I'm more of an IT guy than professional programmer it may be that I haven't learned it well - but I don't want to learn it well; I want to drop it in and have it just work. Every time I change my DB I have to offer a prayer to the relational gods before recompiling - then curse them afterwards. Maybe for large apps it is better but I prefer services that are simple, small, and totally visible. I fully agree with your utilitarian point of view, though. – bob Jan 15 '14 at 16:05
  • 1
    @bob That's one of the reasons I like EF more than many of the alternatives. It's very visible. There are basically three documents involved. One is your storage model, one is your conceptual model (what the objects look like), and the other maps between the two. No ORM is going to automagically work when you change the database behind the scenes. There has to be some changes at the code level to handle the new schema and most likely your objects are changing as well. – Timothy Strimple Jan 15 '14 at 23:03
  • Does the last part about scaling still hold up with .NET Core & ASP.NET Core? – Alexander Derck Sep 05 '18 at 12:43