Wintellect Blogs

Five Reasons ASP.NET Developers Should Care About Node.js

13 Mar , 2014  

Unless you’ve been living under a rock (or perhaps in a van down by the river) you may have noticed that Node.js is kind of a big deal. Since its introduction in late 2009, Node has steadily grown in popularity and now occupies prime real estate as a (if not *the*) de facto choice of server-side infrastructure for the modern web stack.

Node’s popularity is based on a few distinct advantages relative to its competition. First, Node is fast and very scalable, due to its lightweight hosting model and default pattern of asynchronous I/O (which is a fancy way of saying Node doesn’t wait around doing nothing while that 5 second database query you just issued hasn’t returned yet). Second, in contrast to its power, Node’s core programming model (the concepts needed to understand “the Node way”, and the actual APIs that implement those concepts) is very simple and straightforward. Here is Node’s “hello world” in its entirety:


var http = require('http');

var port = process.env.port || 8888;

http.createServer(function (req, res) {
    res.writeHead(200, { 'Content-Type': 'text/plain' });
    res.end('Hello World\n');


Just a few lines of code, a few more lines of config (not shown), and that’s it! Of course, the complexity ratchets up a few notches once you start building real software… but a surprisingly high percentage of the core Node concepts are found in those few lines. How does your web stack compare? Last, JavaScript is everywhere. JavaScript is the web’s assembly language. And now JavaScript is on the server, too. Node programs are implemented in the same JavaScript you use to write browser-based logic. It executes in the same virtual machine (Chrome’s V8) that many of you are currently using to view this page. If you write JavaScript for the client now, many of the same tips, tricks, open-source libraries, and homespun wisdom you already have in your mental tool belt will work very well in Node. There is a power and utility in having a single language with which to implement your full web application stack.

So far this isn’t terribly controversial, or illuminating… Node is big, its useful, people like it, etc. Gee, thanks Josh. But the devil is in the details. Node may be huge in some highly visible retail corners of the web and in countless small-but-diabolically-fashionable Valley startups, but not all web development occurs in service to the largest retailers on the planet or at the behest of high-brow VCs. So what should the rest of us think about Node?

Here at Wintellect we focus on enterprise web development and talk to a lot of customers across many verticals… energy, engineering, finance, media, etc. Most of them trend toward medium-to-large size in scale, and many (most?) have a variety of technologies (and even technology stacks) at the core of their business. So a key aspect of our consulting is helping customers align their current technology investments with the ever-shifting “industry landscape” and providing context for pending technology decisions. And Node definitely appears on the enterprise radar… for some it’s a buzzword from a magazine article, for others it’s merely tire-kicking. Some are even building on top of it already. But fewer and fewer can afford to ignore it entirely.

Because so many of our enterprise customers are heavily invested in the Microsoft stack, we’ve had time and opportunity to consider “why Node?” in that context. Node has some specific advantages (and even some disadvantages… more on that in another blog post) for the traditional ASP.NET team to consider.

1. Node is a fast, lightweight means to serve static content + JSON

As browser capabilities and JavaScript VMs have improved over the last several years, we’ve seen a steady movement of “application behavior logic” (not necessarily the same thing as business logic) from the server to the client. Where the traditional approach has been to consume server resources to dynamically generate HTML and push it to the browser (Web Forms, Razor, etc.), in the interest of performance and scale (and continuing comfort with JavaScript as an application platform unto itself) we increasingly offload dynamic UI behaviors to the browser through manipulation of “static” HTML via CSS and JavaScript, backfilled by JSON data from the server. Thus today’s web server has comparatively less work to do than yesterday’s… which makes Node’s lightweight model a potentially attractive alternative to ASP.NET’s more heavyweight, prescriptive model that came of age when server-side rendering was state-of-the-art. Ask yourself… if you’re primarily serving static HTML, CSS, and JavaScript files + JSON data from REST endpoints, do you really need ASP.NET for that?

2. Node is a great choice for teams with extensive JavaScript skills investments

Certainly if you’re a .NET developer then you’ve invested heavily in the Microsoft stack and the requisite skillsets to maximize that. But the days of the monochromatic enterprise are gone, and even we C# diehards have had to (sometimes grudgingly Smile) bolster our JavaScript skills in order to stay current. If your team is staffed with a bunch of JS rockstar-ninja-samauri-megacoders then by all means take a closer look at Node for your next project. The ability to share tribal wisdom, libraries, and best practices across your entire application codebase and team is very powerful. Ironically we’ve been there before in the not-too-distant past… this time it appears we’ll have a different outcome.

3. Node integrates very nicely with Visual Studio

In November 2013 Microsoft released the Node.js Tools for Visual Studio, which do exactly what you’d expect from the name… provide an integrated development and (importantly) debugging experience for Node applications, right inside VS.NET. You get breakpoints, variable values, call stacks, editor niceties, NPM integration (NPM is NuGet for Node, in essence), and more. It’s an alpha release, but very usable. Especially if you’re planning to continue .NET development in addition to exploring Node, I highly recommend it.

Check out this brief video tour from the team who built it:


4. Node has a burgeoning ecosystem for Windows and .NET integration

As a long-time .NET developer, this has been the most pleasant surprise (and my favorite part) of getting to know Node. There are a handful of Node modules (opt-in extensions and frameworks that augment Node’s core behaviors) that make transitioning from .NET to Node less painful, even comfortable. If you know .NET and you’re getting to know Node, make time for these as well. In no particular order:

iisnode – This module allows you to host Node applications inside IIS on Windows (Node still runs in its own process(es) so it’s not quite “inside”). This conveys several useful advantages to your Node apps… IIS process lifetime management, support for web gardens (important for scaling Node on multi-core machines), integrated security, etc.

httpsys – This is a drop-in replacement for Node’s built-in HTTP stack. It utilizes the kernel-mode http.sys driver in Windows to provide increased performance and kernel-level output caching (among others). Not compatible with iisnode (so, useful for self-hosted Node apps on Windows).

node-sqlserver – A module developed by the Azure team at Microsoft for querying against local or cloud-based SQL Server instances, from within a Node app. Not as wrist-friendly as Entity Framework Smile but certainly gets the job done.

passport-windowsauth – This module provides Integrated Windows authentication for Node applications, similar to the traditional integrated auth experience in ASP.NET. It also does forms-based authentication. It depends upon the passport.js Node authentication module.

TypeScript – Not a Node module per-se, but its worth noting that TS provides a great experience for building and maintaining Node applications. Especially useful for C# devs moving to Node and struggling to build out large-ish codebases.

edge – Edge.js is my favorite module for Node/.NET integration. Edge allows you to call virtually any arbitrary .NET code from within a Node application. Any .NET code you can shoehorn into an async delegate is usable. This is great for integrating with existing .NET code libraries… you can write new Node applications and still leverage valuable core business functionality written in .NET, without having to re-write it in JavaScript! Very powerful stuff. If you’re coming from .NET and going to Node, check it out.

5. Node works great with Windows Azure

Whether you’re talking about IaaS Virtual Machines or PaaS Web Sites or Cloud Services, Node.js deploys easily and runs great on the Azure cloud platform. To help you get started, the Azure folks provide a comprehensive, Node-centric overview on how to target the various platform services like Tables, Queues, Service Bus, etc. Node+Azure isn’t seen too often in the wild (at least in the enterprise arena that Wintellect occupies) but that’s a shame… it’s a very powerful combination. You get the simplicity of the Node app model with the feature set and dynamic performance and scale of a major cloud infrastructure. What’s not to like about that? Oh, and by the way… Microsoft themselves liked Node well enough that they based their initial Azure Mobile Services infrastructure on it (they’ve since implemented a .NET version, as well).

Here’s an animation showing how easy it is to deploy from VS.NET to Azure Web Sites:

deploying node to azure 2


To be fair, Node has weaknesses to consider as well, just like any other web development stack. And transitioning from ASP.NET to Node isn’t always a sure win… ASP.NET hasn’t exactly stood still during Node’s rise to prominence. The last few years we’ve seen the addition of Web API for building RESTful services, better support for rich browser frameworks, and efforts to standardize the interfaces between components of the modern web stack (OWIN). And even greater things are in store from Redmond. I’ll have more to say on reasons to stick with ASP.NET over Node in a follow up post.

That said, Node is an undeniably interesting and powerful technology. So if I’ve piqued your interest then I’d urge you to take a closer look at what Node has to offer and how it might play a role in your next project. For more information about how Node fits into a .NET developer’s world, see my video “Node.js For the Confused – A Practical Guide For .NET Developers” on WintellectNOW. Use promo code Lane-13 for a free trial.

, ,

  • Anonymous

    So how does node.js address the problem that it’s almost impossible to write good, clean, maintainable code in javascript? No inheritance, no polymorphism, no interfaces…

    The clue is in the name – javaSCRIPT. Don’t get me wrong, for it’s intended purpose – small snippets of client-side functionality to support a website and remove the need for an unnecessary server request – javascript is great! But the idea of trying to write enterprise-level solutions that require long-term maintenance in it is the stuff of nightmares.

    The sooner the current fad for javascript is over, the better.

  • Anonymous

    This is like comparing a hammer to a nail gun. Hey, I have this nice lightweight hammer. I only need one quick swing to hit a nail on its head. How much extra effort do you need if you use a nail gun? Good luck selling your hammer to enterprises!

  • Anonymous

    You lost me at “Node is fast and very scalable.”

  • High level, great post. And +1 for Node.

    At the same time I want to make a comment regarding your point #1: Node.js being a good way to serve static content. It is not. Regardless if you run Node on Windows or *nix, there is usually a more performant way of serving static content than through Node. You don’t want to use Node.js to serve static content any more (ok, maybe slightly more) than you would want to use .NET or Python to serve your static files.

    I really like Node.js. I like it more than .NET. I worked on Node.js for more than 3 years as of this writing (most of that time at Microsoft, until 9/2013). I am the author of three projects from the list of “ecosystem” projects you mention: iisnode, httpsys, and edge. Node is certainly a _convenient_ way of serving static content accompanying your otherwise dynamic HTTP endpoints since it allows all your application logic to reside in JavaScript. However, in the context of Windows based development which this post is about, Node.js is a far cry from the performance offered by HTTP.SYS/IIS (for static content). HTTP.SYS/IIS can serve static content running mostly kernel mode code, and some _native_ user mode code. In contrast, every HTTP request in the Node.js stack is going from Kernel, to native user mode code, to managed V8 execution environment (garbage collection & Co), and back. Add to this the option of kernel mode output caching in HTTP.SYS, and we are talking about HTTP.SYS/IIS being 10x faster than Node.js for serving _static_ content on Windows. For details, check out and

    Again, I really like Node. But if you deeply care about performance, serve the static content of your web application from S3, Azure Blob Storage, a CDN, or directly from a native web server rather than through Node.js, and save your Node.js code for those dynamic HTTP endpoints.

  • Anonymous

    Ben P don’t speak too much if you haven’t write an application in NodeJs. You’re like going to a war without any weapons. So please don’t speak

  • Anonymous

    You should try Go. It’s like node, for grown-ups.

  • Josh,

    Great write up. I would tend to disagree that you can write the same exact code in the browser as you do on the server. I have been called in to help fix many applications over the past year that tried to implement good node patterns in the client to have them fail. For example require is great on the client, but honestly makes a mess in the browser, even when using r.js to ‘clean’ it up. The two contexts are very different, there is no critical rendering path on the server for example.

    To Ben P, you are completely wrong, it is very easy to write scalable, extensible JavaScript that allows inheritance. JavaScript has a prototype that is easy to extend. You do not need interfaces per se because JavaScript is a dynamic language. The dynamic nature of JavaScript makes it very different from its static counterparts like C#. This is an example of where traditional C# and Java programmers tend to struggle with JavaScript. The {} and ; throw them off and they think it is the same syntax, but it is not. Once you shed that mentality JavaScript is very simple and easy to work with. It is very easy to make extensible modules that also utilize dependency injection, etc. It is also easier to setup unit tests because of the dynamic nature.

  • jlane

    @Ben P

    Node.js doesn’t address the issue of how to structure your JavaScript code. Nor does it purport to. As for JavaScript being “impossible” to write in a clean, maintainable way… that’s painting with a pretty broad brush. I won’t argue that some people have challenges there, and that the traditional enterprise IT dept. might fall into that camp. But there are already large enterprise codebases being written in JavaScript today, particularly on the client. There’s nothing inherently special about the server that makes it fundamentally different. Tools like TypeScript add type and interface definition, editor-based intellisense, etc. to JS. Some people even find they like prototype-based inheritance, over time.

    Should every enterprise app be built in JavaScript? No, of course not. Heck, I love C# and would be perfectly happy living in that world forever. But that’s not reality. JavaScript is everywhere, and while not every app will be written with it, lots of apps will be, and the enterprise needs to reconcile that reality and find ways to make peace with it.

  • jlane


    Care to elaborate? I’d love to hear specifics.

    I don’t see that Node is inherently faster or more scalable than well-crafted server code on other platforms, but Node does make writing well-crafted server code easier for a significant subset of developers. That sort of thing can be pretty useful to your average enterprise.

  • Anonymous

    @Ben P

    Wow, the immense ignorance by .NET stack developers is incredible, and it’s not just your comments.
    Too many of you act like fanboys, for a framework. Grow up.

    “So how does node.js address the problem that it’s almost impossible to write good, clean, maintainable code in javascript? No inheritance, no polymorphism, no interfaces…”

    No, it’s impossible for an incompetent JavaScript developer to do what you ask. You live in the nineties, educate yourself instead of succumb in some C# circle jerk.
    As always, too many old .NET developers says, if it does more, it does it best, which is just as silly as it sounds.
    This can do that, this, this and that…reasonable well, sometimes awful, but not best at anything.

  • jcarroll

    @Ben P

    I want to address some of your criticisms of JavaScript. I am one of the senior consultants here at Wintellect and have been doing JS development for quite a while. For the past year and a half I have been working on a very large enterprise application using Angular.js with tens of thousands of lines of JavaScript.

    I’ll do my best to pull out each individual argument, but if at any point I am putting words into your mouth, or misinterpreting what you have said, then by all means feel free to correct me.

    1.) JavaScript lacks language level constructs that make it difficult to maintain “inheritance, polymorphism, interfaces…”

    The first two are simply not true, just a little different than traditional inheritance in languages like C# or C++.

    JavaScript is a prototype based language. Objects don’t inherit from classes, rather they inherit from other objects, known as prototypes. It is fully possibly to do classical inheritance in JS, and there are numerous articles written on how to do that. Here are just a few links you can check out:

    Because JS walks the prototype inheritance chain looking for an appropriate method, it’s very easy to achieve polymorphism. I can override methods or properties on my sub-types, or even at the instance level.

    Interfaces aren’t really needed in JavaScript because they are a compile time construct. An interface in C# is used by the compiler to enforce that a particular type will adhere to a strict contract. This is essentially meaningless in JS because an object can change at runtime. While this may seem like an abomination, it’s this very flexibility that makes JavaScript exceptionally well suited for a whole host of problems that are inherently difficult for statically typed languages.

    JavaScript is less concerned with the “Is-A” relationship of OO than it is with the “Has-A” relationship. I can still check for adherence to the “Has-A” relationship of an object at runtime. This is a good thing, because I can evolve the interface of an API while ensuring decent backward compatibility for existing consumers. I cannot change an interface in a statically typed language without breaking the API.

    All that being said, ECMA Script 6 is right around the corner and contains numerous language level constructs that address all of the above. If you don’t want to wait, you can use a pre-processor like TypeScript to give you first class interfaces, classes, and inheritance.

    2.) JavaScript isn’t a full featured language, and is only good for small bits of functionality in the browser. It simply isn’t up to the task of the kind of scale that Enterprise development requires.

    Mocha was originally created by Brendan Eich in 10 days, and while any language developed in that short period of time is going to have some rough points, it is a full featured, and expressive programming language. The name change to “JavaScript” was more of a marketing thing by Netscape, but JavaScript and Java have about as much in common as World War Z the movie and World War Z the book.

    If developing large scale enterprise applications in JavaScript is impossible, then my team didn’t get the memo. We have almost 30 developers working in the same code base using TypeScript and Angular.js. The project is huge, but I can assure you our biggest challenges have absolutely nothing to do with our use of JavaScript.

    I have worked on dozens of C# code bases that were a nightmare. There is nothing in C# that will prevent you from writing bad code, and JavaScript is no different. A compiler is a poor substitute for solid design, and a good suite of automated tests. After having worked on this code base for the past year and a half, I can assure you that maintenance is not the stuff of nightmares.

    3.) JavaScript is just a fad, and will eventually go away.

    JavaScript isn’t going anywhere, anytime soon.

    For decades now our industry has been trying to solve the platform independence issue, but keeps failing miserably for one reason or another. Like it or not… JavaScript wins this battle hands down. I can write a web server powered by JavaScript on the server using Node.js that runs on both Windows and Linux without doing anything special. That web server can serve up a rich, full featured client side experience using JavaScript that is guaranteed to run in every major browser, and the majority of mobile devices.

    That means I get *true* write once run everywhere portability using a single language on both the client and the server. Not only that, but I can tap into hardware accelerated graphics capabilities using CSS3 and WebGL.

    For better or worse, where .Net and Java have failed, JavaScript succeeded. It’s not “just a fad” and hasn’t been for several years at this point.

  • Anonymous

    Except for #2 and maybe #1, I don’t see anything on this list that is an advantage of node or JavaScript over .NET. I might be missing something, but doesn’t async/await eliminate the main reason folks wanted Node in the first place? I.e. threads don’t sit idle waiting for IO-bound resources.

    The only compelling reason I can see to using Node is the ability to easily share code between the client and server. If there is tons of logic that is replicated in both places, Node might be right call. But that aside, as a language JavaScript has so many issues and shortcomings I can’t see why anyone would select it over something like C#, without any other real benefits.

  • jlane


    Thanks for the point about serving static content via CDN, etc. You’re right of course… Node makes it easy but that doesn’t mean its the right thing to do, at least not in the general case.

    And thanks so much for your hard work on iisnode, edge, etc. Those are really terrific modules and they’ve made Node a better, happier place for Windows and .NET developers to live. Great work!

  • Anonymous

    > For better or worse, where .Net and Java have failed, JavaScript succeeded. It’s not “just a fad” and hasn’t been for several years at this point.

    This is why I cry.

  • Anonymous

    @Mr C#,

    Make that “it’s impossible for incompetent developers to clean maintainable code in anything”.

  • Anonymous

    The interesting question to ask – how much more Microsoft is going to invest into supporting this scriptkiddie nonsense? Doing this solely on purpose of looking hip and trendy among yesterday’s SEO specialists, management graduates and other “multi-professionals” may harm minds of many young and innocent people. The sooner you cut this, the better.

  • dbanister

    As another Wintellect consultant, I would like to chime in on some of these comments. The premise of the article was that ASP.NET developers should care about Node. I think Josh did a great job of providing thoughtful insight into why Node should be on your radar. Node does exist, and arguments that JavaScript is stupid seem unwarranted here and unprofessional in general. As I am much more keen to debate the finer points of the viability of Node, please take those kinds of comments to my post below, and please stick to professional comments about Node’s applicability here.

  • Colin Phillips

    This is to all the the ASP.NET developers just stop using it and node , it’s faster more scalable best architecture for real time apps , and apps that need to serve an insane amount of clients , communicates better with the client which is in javascript by just using JSON , less expensive development will be easier as well , even better using it on the MEAN stack I mean honestly who does MVC on the server side or serve web pages on the server that is just asking for a super slow app ,oh yes it’s also faster (do a test yourself under any conditions 😉 ) than WEB API before I start hearing ASP.NET is a framework it doesn’t only have A it also has B,C and D well it’s faster and easier to develop in option/tool A,B,C and D that ASP.NET has to over so yes it is better then the whole ASP.Net framework,+ you won’t have to hack your way around things any more so give it a shot and you won’t need a slow bulky framework that one language node / MEAN stack can do for for you .

  • aaron

    I am still a little puzzled by NodeJs. Most nodejs articles have that ubiquitous simplistic http server example. Will that suffice to host an enterprise level web application?