Why Should You Care About NodeJS?

  • Jan 17, 2014 at 11:16 PM
  • Shawn Wildermuth

javascriptI know that many of my readers are .NET guys and a core constituency actively hate JavaScript so bear with me and let’s talk about NodeJS for a minute.

Just to be clear, I am not advocating anything by this post. What I think is important is that as you mature as a developer that you look at whatever is happening in the community and be open to why something is new  and what new ideas are being proffered by the new technology. My hope is that this post will show some of that.

What is NodeJS?

Simply put, NodeJS is a runtime for JavaScript that encourages non-blocking I/O and fast networking. NodeJS itself isn’t written in JavaScript but it executes JavaScript using Chrome’s V8 engine. It is the engine that powers a lot of cool tools these days (e.g. Bower, GruntJS, etc.) but is primarily used as simple web server platform.

Is NodeJS Magically Scalable?

When I first heard about NodeJS, the comments were always about how you could create fast, scalable web sites/apps with it. While this is true, it’s nature isn’t magic. The trick here is that NodeJS encourages non-blocking behaviors. NodeJS itself is single threaded (though you can run multiple instances of it) but it encourages you to think in terms of events and callbacks. The thread isn’t busy while waiting for these callbacks so it can accommodate a lot more traffic than a traditional web server (e.g. IIS or Apache) per thread.

While NodeJS is an admirable technology, I think it’s real benefit is that it doesn’t rely on thread pools to achieve smart asynchrony. It encourages writing asynchronous code on the server. And if the request is waiting for an operation, it can release the thread to serve another request.

This means you can build better scalability, easier with NodeJS – per thread. Full throughput of NodeJS isn’t necessarily more than you’d get from IIS or Apache, but that’s because they can throw more threads at the problem. NodeJS out of the box doesn’t have the concept of scaling out as an obvious switch. Instead, it relies on that being applied to it separately. There are solutions for this, but it is something that you’d seek out or ‘buy’ (e.g. Azure, AWS, etc.)

What Can .NET Learn from NodeJS?

As far as I can tell (and I am ankle deep into a lot of these technologies), I think .NET is learning from NodeJS. That’s what a lot of the OWIN stuff is about. Combining OWIN and scriptcs gets you pretty close to the vision for NodeJS on .NET. But as a developer, what can you learn?

If you’re like me, you have a lot of skills and experience with ASP.NET (et al.) and I’d love to achieve some of the benefits of NodeJS. One of the concepts you should think about is non-blocking I/O and event callbacks. Much of this is accomplished with Asynchronous Controllers in ASP.NET MVC and Web API. Often developers won’t both worrying about asynchrony here unless they’re doing something that takes a lot of time (like calling out to another web server or calling a database), but I think that you should be thinking about asynchrony every time you make a call that takes any time. The Windows team started thinking like this for WinRT in that any call that is > 50ms requires you to call it via an asynchronous API. The C# async stuff makes this pretty easy so we in web development land should treat it the same way. Most Controllers should be Asynchronous as far as I am concerned. Especially now that EF6 supports asynchronous queries.

Should You Be Looking at NodeJS?


Ok, maybe more is useful. I think you should be looking at NodeJS to understand it’s philosophy. You may find for certain types of projects (e.g. APIs or networking projects) that NodeJS is a great model and you should deploy NodeJS project. But at a minimum I think programming NodeJS will teach you how to think in terms of non-blocking I/O. That’s a great skill to have regardless of how you build software.




Andy Monday, January 20, 2014

I've just started looking into SignalR for .Net clients, which (I understand) is based on OWIN. From a coding point of view the async model makes it very easy to write client code, but as it still runs in IIS I assume server performance will be nowhere near that of NodeJS. Not sure how much of a difference it would make if it was run self-hosted?


Richard Monday, January 20, 2014

@Andy IIS and ASP.NET have vastly superior throughput to NodeJS when setup using async request handlers, and doing the same task. Async handlers are not new, but they are not part of the common implementation of WebForms, so they are not common. Learning NodeJS (or jQuery for that matter) should be a means to challenge you as a developer to think more about non-blocking patters. Get cracking with Tasks and you'll soon see what I mean.


Kannan Monday, January 20, 2014

I have a bunch of REST APIs developed using ASP NET Web API, all of these APIs are expected to return asap (avg. 200-300 ms) and scale well , they all do varying set of operations include CRUD calls and external web service calls, is it advisable to use async here. One of my concerns is, for high performance APIs the context switching cost would be too high, any recommendations ?


Mark Monday, January 20, 2014

"but as it still runs in IIS I assume server performance will be nowhere near that of NodeJS".

I keep seeing statements like this around the web. Node.js is relatively fast and scalable if you're coming from a Ruby background, but a well-written .NET site running under IIS will run rings round it.


TheReverand Monday, January 20, 2014

Mark is absolutely correct. IIS and a we crafted .Net web app will make nodejs go cross eyed. Using some instance stacking and intelligent routing you can get nodejs into the same suberb as .Net but it's not really all that close.

I happen to like nodejs as a great way to write cross platform tools. Something it excels at, and I can use coffeescript or typescript so I'm happy.


Wayne Tuesday, January 21, 2014

Well said!


Gates VP Tuesday, January 21, 2014

It looks like the comments devolved to FUD pretty quickly.

Node.JS is competitively fast. Techempower has run some of the most complete open-source benchmarks available There are some differences, but there is no 10x, "running circles around" differences. Both are in the same realm of performance, if you really wanted top performance you would write it all on FPGAs :)


Learning Node.js is a great way to start looking at the world asynchronously. It's also a very simple tool for writing basic "network" applications. Listening to data flowing over a socket is really easy with node.

The other key takeaway from node is really "Streams and Transforms". Basically everything we do with programming is simply transforming some piece of data into another piece and passing it along the pipe. Node.JS really makes this obvious.

Nearly everything in node is exposed as a stream. So you can start looking at Databases and file systems and web services and HTTP calls as variants on the same thing. Once you start thinking of things as Streams, Node.js becomes a very good "glue" language.

It's really easy to take data from a file and pipe it to a DB, or take data from a DB and pipe into a web-service call, etc.


Pavel Dvorak Tuesday, January 21, 2014

Thanks Shawn for voicing your opinion. Have been looking for a solid analysis of Node.js advantages especially (as a core .net guy) in comparison to .NET. but so far mostly dubious benefit statements such as "1. it is cool", "can create a browser-based chat app", better package management (actual quotes from StackOverflow) or "it doesn’t rely on thread pools to achieve smart asynchrony" (also a quote :) were available. Apparently however, to the Java Script core constituency who are actively hating technologies like WAS and WCF this is sufficiently attractive especially compared to the sad state of PHP modules etc. (as discussed above) and so that's where all the migration success stories appear to come from. There is also the important aspect of having your language available
on the server, quite understandably a big deal.
Your post however points out the programming model, which when reading it I realised is probably more important than the current limitations of the runtime. Adoption of asynchrony in C# is slow [Jon Skeet], it is still stretching developers' skills (and nerves in the applications such as async MVC controllers), so maybe just not having any other way of writing apps is the long-term winner. At the speed the wave is travelling maybe even a mid-term winner.


Paul Lockwood Saturday, February 08, 2014

Good post Shawn.

Until literally a week ago I was preparing to move to Node/ 100% JavaScript. Node is going to be hot this summer; that ball is unstoppable now. After spending a good amount of (unpaid) time improving my JavaScript knowledge and learning Node here are my conclusions:


Leave a Comment