To Node.js Or Not To Node.js

Node.js – it has rapidly become the “new hotness” in the tech start-up realm. With each passing day, the fan base of Node lovers grows larger, spreading their rhetoric like a religion. How do you spot a Node.js user? Don’t worry, they’ll let you know. 😉

One day you’re at a regular user group meeting, sipping soda and talking with some colleagues, when the subject turns to Node. “Have you guys tried Node.js?” asks one of the people in your group. “It’s all the rage. All of the cool kids in Silicon Valley are using it!” “What does it do?” you ask, only to be bombarded with a sales pitch worthy of the best of used car lots. “Oh, it’s amazing!” they reply, sipping their diet coke and shuffling their hipster fedora and backpack with MacBook Pro in it (or something like that), “It’s server side JavaScript. It runs on a single thread and it can do 100,000 web requests a second!” They glance at the group for the oohs and ahhs, but most people just stare back with amazement in their eyes. Then, your hipster Node-loving friend drops the words that start wars: “It’s way better than .NET” – and just like that, your group is hooked. They go home, download the Node.js tools, write “Hello World”, and suddenly they’re on their way to the next user group meeting to talk about how great Node is.

Okay, so I might be exaggerating the appearance and demeanour of your average Node lover a little (read: a lot, almost entirely in fact). However, I have had this exact scenario happen repeatedly over the last six months, with ever-increasing intensity and frequency. Node users love Node. They want you to love Node. They’re excited about it.

Having given it some thought, why wouldn’t Node.js developers be excited? Want to fire up a “Hello World” web server in Node? It’s trivial:

// Load the http module to create an http server.
var http = require('http');

// Configure our HTTP server to respond with Hello World to all requests.
var server = http.createServer(function (request, response) {
  response.writeHead(200, {"Content-Type": "text/plain"});
  response.end("Hello World\n");

// Listen on port 8000, IP defaults to

Want to do the same thing in .NET? Be prepared to learn about IIS, the Machine.config, the Web.config, the Process Model, how Global.asax works, either ASP.NET MVC or WebForms (huge paradigms in themselves), and how Visual Studio works. Don’t forget to learn how to create a solution, at least one web project, and how to deploy the application to IIS. Oh, and one little detail: go ahead and learn C# while you’re at it. All of that’s pretty much just as easy and intuitive as Node.js, right?

.NET is incredibly complicated. Node.js is incredibly simple. On the merits of that fact alone it’s no wonder that these .NET developers and fresh-out-of-college kids who have already dabbled in JavaScript are transferring these skills to the server side and standing up web servers in literally 5 minutes and 5 lines of code. How can you deny the sexiness of that? The bragging rights it gives you? The ease and comfort of a language you’re already familiar with?

This, in my opinion, is why Node.js is becoming huge. It has simplified and streamlined the development process and made programming very accessible to almost everyone (or at least anyone who has ever played with JavaScript).

However, to those who sell Node.js as single-threaded, and to those who sell Node.js as having significantly better performance than .NET, I say this: you are wrong.

With simplicity comes misunderstanding and the concept of “Leaky Abstractions.” As my good friend and colleague Thomas B. said to me during dinner last week: Node.js is opinionated. It has an opinion on how you should do things, and it forces you to do them a certain way.

Node.js is not single-threaded, though many Node developers in my experience believe it to be. Node’s creator believes that a single-threaded listener delegating I/O-bound work to a thread pool is the key to a highly available application. As a result, Node.js forces you into this paradigm of event-based asynchronous execution of I/O operations via a thread pool.

Node.js has a single thread listening for connections. All of the code which you as the Node developer write is executed on this single thread. This single thread is all that is exposed to you. As soon as a connection is received, Node’s listening thread executes your coded event on the same listener thread. This event either does quick, non-CPU intensive work (like returning static content to a client), or long-running I/O bound operations (like reading data from a database). In the case of the former, the listener thread does in fact block for the duration of the request, but the request happens so quickly that the delay is trivial. In the case of the latter, Node uses V8 and libuv (which it is built upon) to delegate the I/O work to a thread from an underlying pool of native C++ threads. The single listening thread kicks off the work to an I/O worker thread with a callback that says “tell me when you’re done” and immediately returns to listening for the next connection. It is thus plain to see that Node.js is indeed multi-threaded, though this functionality is not directly exposed to the Node developer.

An important note regarding Node.js is that any CPU-intensive code which you write will block the entire system and make your application scale poorly or become entirely unresponsive. As a result, you would not want to use Node.js when you need to write an application that will do CPU-intensive work such as performing calculations or creating reports.

This is how a single thread can handle multiple requests at once; receiving a request and either serving static/simple content or delegating it to an I/O thread from a thread pool are both very cheap and quick operations. When the thread pool thread that is doing the long-running I/O work signals to the single listener thread that the work is done, the listener thread picks up the response and sends it back to the user; this is another very cheap operation. The core idea is that the single listener thread never blocks: it only does fast, cheap processing or delegation of requests to other threads and the serving of responses to clients. The diagram below (taken from Stack Overflow) explains this visually:

Node.js Processing Model

This is a very good, scalable, highly-available way to write code; Node.js nailed their approach and developers benefit from it. However, as of .NET 4.5, you can easily create this exact paradigm/pattern in your .NET applications. The difference is that .NET does not force you to do so.

With the introduction of a very tidy wrapper around asynchronous programming in .NET 4.5 (async/await keywords), Microsoft made asynchronous, event-based programming quite a bit easier and more intuitive. And with recent conformance by Microsoft to the jointly-created OWIN specification, the web pipeline of .NET has become much simpler.

In fact, you can now write the “Hello World” asynchronous web server in .NET in about as few lines as Node.js! In this example, I host a web server in a console application which is terminated when a key is pressed:

/// <summary>
/// A simple program to show off an OWIN self-hosted web app.
/// </summary>
public class Program
    /// <summary>
    /// The entry point for the console application.
    /// </summary>
    /// <param name="args">The arguments to the execution of the console application. Ignored.</param>
    static void Main(string[] args)
        // Start OWIN host
        using (WebApp.Start<Startup>(url: "http://localhost:8000"))
            // Runs until a key is pressed

    /// <summary>
    /// This code configures the OWIN web app. The Startup class is specified as a type parameter in the WebApp.Start method.
    /// </summary>
    private class Startup
        /// <summary>
        /// Configures the web app.
        /// </summary>
        /// <param name="app">The app builder.</param>
        public void Configuration( IAppBuilder app )
            // We ignore any rules here and just return the same response for any request
            app.Run( context =>
                context.Response.ContentType = "text/plain";
                return context.Response.WriteAsync( "Hello World\n" );
            } );

One of the big positives of Node.js is that you opt-in to complexity. You start very simply and add on functionality as you need it. I’m a big fan of this approach and I feel that this is where Node really shines. Nothing bothers me more than starting an “Empty MVC 4 Web Application” from template in Visual Studio only to have it install about 15 Nuget packages, one of which is Entity Framework. Great, I fired up a blank application and already my ORM has been decided for me. Who said I even needed one in the first place?!

The above OWIN-based approach to hosting a web app in .NET allows you to benefit from Node’s simplistic approach. I have started out simply, and can now add Dapper if I need an ORM, Newtonsoft.Json if I need to serialize to and from JSON, Unity if I care about dependency injection, etc. It’s a nice, clean slate upon which I can build any framework that I desire.

This approach in .NET is very comparable to Node.js, with a few differences:

  • Node.js uses 1 listener thread, while .NET uses N listener threads. If your Node.js application does CPU-intensive work at all, it will block the entire system and potentially cause your application to become unresponsive. .NET, on the other hand, is designed to do CPU intensive work. Tying up a thread to do some CPU work is not of concern because there are other threads available in the listener thread pool to take other requests while this is happening. However, both Node.js and .NET are limited by the server resources; in either case, if you max out the CPU or RAM, your app will perform horribly, regardless of thread delegation. This is known as resource contention.
  • Node.js delegates I/O bound work to an I/O thread worker pool, and .NET implemented asynchronously (async methods and the async/await keywords) does the same.
  • Node.js uses an event-based paradigm, and .NET does also when implemented asynchronously.
  • Node.js offers high performance for I/O bound, low CPU operations, and .NET offers comparable performance when you skip the IIS pipeline. IIS tacks on a significant amount of performance overhead due to things like session state management, forms authentication, the process model, request lifecycle events, etc. These are not bad things to have and use, but if you don’t need IIS, session state, forms auth, request lifecycle events, or the process model, then don’t use them!
  • Node.js must parse/serialize to and from JSON, and .NET must serialize to and from JSON to interact with .NET objects. Parsing is going to be much cheaper in Node.js than serializing is in .NET, but .NET also enables you to serialize to XML, Atom RSS, and anything else that you desire. With Node, this is a bit trickier, and the serialization overhead comes back into play to even the field.

When someone compares Node.js to .NET, I find that they often actually compare Node.js to IIS hosted frameworks such as ASP.NET MVC, ASP.NET WebForms, and ASP.NET Web API (in IIS hosted mode). These are all tools built on top of ASP.NET to simplify enterprise web development and to do CPU-intensive calculations. In these scenarios, Node.js will have an advantage, because it is designed specifically to NOT do CPU-intensive calculations. You are effectively comparing CPU-intensive Apples to low-CPU-usage Oranges. It is not a fair comparison.

When someone compares Node.js to a self-hosted .NET web app which does I/O-bound long-running operations via asynchronous thread pool delegation, they find that there is not much of a difference in performance between the two runtimes. In fact, comparing Node.js to self-hosted Web API (NOT using IIS) doing low-CPU work, the numbers are very close:

Web API vs Node.js

This image was taken from a benchmark done in 2012 with the Web API Release Candidate (not Web API 2, and NOT OWIN hosted). Given that Web API 2 exists, and can be self-hosted via OWIN, I’d love to see a more recent benchmark comparing the two. In fact, I will try and do this for my next blog post.

So, to Node.js or not to Node.js? I submit these final thoughts:

I guess the point of all of this has been that neither Node.js or .NET is necessarily better/the best/the new hotness. They both serve a purpose, and while Node.js is much easier to use and more accessible to developers, .NET is very versatile and powerful as well. They are built to do different things: Node.js specializes in performing and scaling well for low-CPU, highly I/O-bound operations. .NET can perform well in this scenario as well, but can also perform well with high-CPU operations. In fact, I would argue that .NET excels at CPU-intensive operations, especially when compared to Node.

There are many .NET developers in the current tech scene that are capable and competent. This means that it’s not too hard to find, hire, and retain good .NET talent. They can pick up self-hosted OWIN web apps in a matter of days, and begin to write very scalable, high-performance web apps and services based on it. They can even easily host Web API in an OWIN web app via console, a Windows service, or Azure. There’s a community that has existed for over a decade that evolves the .NET framework with amazing tools and add-ons like Dapper, Unity, and Newtonsoft.Json. This community is mature and there are many prominent voices within it that offer advice and help.

Relative to .NET, there aren’t as many Node.js developers in the current tech scene that are capable and competent. This is because fortune favours the bold, and only a few have been early adopters of Node.js. In my experience, few Node developers will truly understand what is going on in the Node.js processing model and how to exploit it for maximum performance, though the opinionated paradigm of Node.js will force developers to write good asynchronous code. It can be hard to find, hire, and retain good Node.js talent. This will become less of a concern as Node’s following grows. The Node.js community is budding and has created some amazing tools and add-ons for Node.js as well such as ORMs and DI frameworks. This community is not yet mature and I am not aware of many prominent voices within it that offer advice and help. As a result, it could be difficult to find support and tools for Node.js if you encounter a problem.

In conclusion, both Node.js and .NET are great. Which one to pick for a particular solution/application, however, depends on many factors; it is not black and white but a full colour spectrum. It would be very foolish and naive for a .NET developer to use .NET to solve every single problem just because “that’s what we use.” It would be similarly foolish for a Node.js developer to propose Node.js as a solution for every project or problem that he or she encounters. One must choose the right tool for a given job, and be open to different paradigms in order to truly excel.

In general, use Node.js when you have highly I/O-bound operations that don’t use much CPU. Use .NET when you need to calculate things and use a lot of CPU.

Don’t use Node.js solely on the reasoning that it’s much faster and performs way better than .NET: it depends on how you use .NET. And don’t use .NET if all you’re doing is heavily I/O-bound operations with low CPU usage: that’s where Node.js excels.

Tags: , , , ,

82 Responses to “To Node.js Or Not To Node.js”

  1. Dmitry says :

    What is about pros and cons .NET and Node.js when related to other OS like Linux and Mac? .NET, even there exists Mono framework but this is not the same product as .NET from Microsoft, is tightly coupled with Windows environment.

  2. Ivan Pelovski says :

    I think the motto of ASP.NET and .NET as a whole is “Why should it be easy when it can be complicated?”. Once I was a passionate .NET developer and believed that everything not coming from Microsoft sucked. But gradually I started to feel the pain from the tools and the process of developing .NET software. I felt the limitations of C# which the C# creators also felt and that’s why they started to add dynamic and functional features to the language. And here comes one of my colleague talking about more powerful languages and more advanced concepts that exists in other technologies. That colleague and my interest in JavaScript made me learn that the non-Microsoft world is full of bright colors and rainbows. A world so stunningly vivid that everything Microsoftish started looking to me greyish and dull. That’s why I’m now a Node.js developer, I’m learning Python, have written an interpreter for Scheme, and continue enjoying programming.

    • ryan says :

      C# didn’t add dynamic and functional concepts because the language was “too limited” and painful.
      That’s crazy talk.
      Javascript is not nearly as powerful a language as C#. NodeJS is pretty sweet, no doubt but if you left .Net because Javascript is so much more “advanced and powerful” then I feel bad for you.

    • Pieter DR says :

      What a bunch of crap. If you’re really serious that C# has less possibilities than JavaScript (JavaScript!!!) then I’m really sad for you. While NodeJS can be great and might be easier for less-educated programmers, saying it’s better or faster or the holy grail is simply a lie. You can do all AND more than what you can do with NodeJS in .NET as well. Often in a similar way, sometimes better.

      Again, I haven’t got a single thing against NodeJS. If you want to use it, then you should. Try it out. But don’t start talking crap like it’s going to solve all your problems and make applications so much faster.

      The truth is that most NodeJS lovers are attracted to it “because it’s where the cool kids are”.
      My truth is that you should deliver an application with the best ROI. Technology is secondary.

      • Dexter Miguel says :

        “Where the cool kids are” LOL

        You seem very strongly opinionated against Node.js, which is okay. Things that people don’t understand can sometimes be scary and even seem far-fetched.

        However, if you even sat down for a few minutes with a Node.js developer and began looking at their Node.js workflow you may just change your opinion. Node.js may not bring huge performance improvements through the wire, but development of Node.js applications has opened up a world of opportunities for a .NET developer such as myself.

        It’s been a pleasure to use Node.js. Projects compile within seconds, automation makes my life easier when making changes to builds and using free open-source tools like Git and Jenkins I can ensure continuous integration with my production and staging servers.

        I’m not sure why you think Node.js lovers “are just there because it’s cool”. It’s almost like Apple and iPhone detractors who seem to think that people use Apple “because it’s cool”. They’re great products. And when great products deliver great results, people will use them.

        If you really care about ROI, Node.js would almost always be your best bet, considering almost all Node.js tools are free. That being said, the real reason to consider whether to use Node.js over ASP.NET would be environment.

        – Do your bosses want to use or currently use SQL Server/SSIS/SSAS/SSRS? Are you willing to bridge the gap between Node.js implementations of SQL Server clients and actual business needs?
        – What does your development team look like? How many developers are well-versed with JavaScript? Do your developers have a flexible (but working) development workflow?
        – Does using Node.js bring a performance benefit in the rate of development? Does it simplify processes or make them harder? Are there any specific advantages that Node.js brings to the table that ASP.NET does not?

        • Anonymous says :

          C# is more advanced language than JavaScript. Instead of JavaScript, NODE.js people should use typescript.

        • Arman says :

          We have couple of Node.js coders in our team that have no idea how Node.js works. Hmm they even had done banchmarking between Node.js vs .Net & PHP just to show and make a point that Node.js is faster, therefor it’s better. One thing they messed up with banchmarking was that they had synchronous I/O operations for .Net & PHP without realizing that Node.js by default does asynchronous I/O operations. This comes to show that majority of “cool kids” do not now about the technology they so much exited.

          We did redid the banchmark Node.js vs Owin Web Api (.Net) and .Net was faster almost a minute for 10,000 consequent requests.

          • James P. says :

            The cool kids found out that
            -nodejs + javascript can solve 99% of the development problem
            – you can scale without paying server license to the OS
            – you can run you nodejs in Dockers with NGINX, cluster.js,
            -Isomorphic development language (Client & Server use the same language) and async come default
            – the npm install is > the Nuget and it’s cross platform
            – the huge crazy open source community. MS did provide a great IDE – VS Code
            -for anything else you like if you have a not-so-smart CEO/CTO/TechLead – Be your own boss, get yourself a nice Macbook Pro and start writing code that will make you money using nodejs

          • Brandon says :

            Node.js vs .Net & PHP?

            That is the equivalent of comparing apples v. a stamp collection & russian mail-order brides.

            When I see people start doing comparisons of a framework vs a runtime vs a language I know we have stumbled into deep waters, haha.

            BTW – I am a .net developer and I find Node.js quite easy and pleasing. Plus, with vs2015 or WebStorm the development is quite quick. Three books and a few days of hacking around Node and Express and you can put together some pretty awesome stuff.

            I still like Web Api (not better or worse – very different), but to discount the effectiveness of either Web Api, or Node.js is not good, especially when we still have a ton of spaghetti PHP coders that we need to help stop band-aiding their next wordpress blog together. (*note – I have nothing against PHP, I have actually made some great apps in PHP, but the language makes it easy for a new-comer to see some dynamic content after 5 mins of trying the language out, and start hacking html/php together like a lumberjack. Learning patterns before using PHP is a huge plus and anyone can see it when they go to debug a 5,000 line index.php file, haha)

        • Alex says :

          I’m C# Dev. Honestly I won’t to get off from Microsoft. I would never to go to Node.js, just because it uses JavaScript. You might think that my experience with JavaScript is very limited, but the main reason is because of the nature of the language. You don’t have compile time errors. Some time ago, when I started using TypeScript, I started to think about Node.js. When I read about single threaded I stopped interesting further. After that article I have just few more concerns, I really like Resharper, Castle DI, WCF and Castle WCF facility.

          The Resharper is the thing which I like. I can’t do similar refactoring in Javascript or TypeScript. Even Resharper does some refactoring for TypeScript it is still very limited. I was thinking that WebStorm(which is done by the same team as Resharper) will have same limitations as Resharper in TypeScript.

          Castle DI, WCF and Castle WCF facility – this is another things which I really like. My classes implementations do not have a clue what services they’re using. It can be real implementation or WCF service.

          If I have replacement to all those things I would give it a try,

          I heard that some people also saying that Node.js has benefit of the ability to use same code on frontend and backend. This is good thing, but what if your implementation has a bug? What if someone will be able to discover that and exploit it?

        • Aditya Deshpande says :

          I think most people speaking against NodeJS are missing one important factor. The cost of hosting a Microsoft server on the cloud. It is far higher than bringing up a Linux based instance.

    • big-d says :

      Dude you are walking right into a hornets nest 🙂
      Don’t expect 1 – 3 language developers to ever understand. Besides javascript is a rather hard language to master, if you use your compiler as diapers and pacifiers, you simply won’t get it.
      I’m a solution architect with 20+ years xp. started out with basic, pascal, vb, delph.
      But when i started with c/c++ i fell in love, later on i had kinda the same experience with c#. and for the next 13 years c# was my goto language for EVERYTHING!!!! (i did some minor projects in other languages: java, php, ruby, and even cobolt)
      Then i was introduced to nodejs, by some very young hip developers… i hated it.. I felt it was a hacked mess. What audacity to hack a frontend scripting language into a backend technology (and single-threaded)
      For a year og so i tried to ignore it, but the young hip dudes kept impressing with short dev spurts: and responsive apps.
      So I did what any seasoned developer, would do, I turned to the dark side.
      Seriously: nodejs rocks! it’s not for all projects, and the learning curve is rather steep (sure you can get started in 10 minutes, but you have to make all the mistakes before you get your 1337-wings)
      Still: nodejs is not the best bet for all projects.
      c# is still a good tool (and java, and c++, and…) but give nodejs a try, you might like it (if you’re not as pigheaded as i was)
      clojure is also an interesting technology to look into.

      Have fun coding: Don’t be a tech-religious fanatic,- that’s just sad.

    • dev says :

      Dont forget c# also built on ECMAScript 6…so the c# developers has bright futures too 🙂

  3. jack says :

    All these scripting languages are made for people who don’t have a formal education on computer engineering. If you want to play “let’s be programmers!” probably you should have gone to university. 100.000 requests per second withour knowing the hw means nothing, and calling some script “real time” is a joke. Seriously, go play doctors or architects, leave engineering alone.

    • ferbraz says :

      This is the only good comment here. Your conclusion is better than the entire article.

    • Grant says :

      I’m a part of several projects involving different languages and have gone through the basic guidance of university. After 7 years of Java and 3 of C#, I now have to create projects geared to business and profit for international venture startups and all I’ll say about monolithic languages is that fitting a good stack together is too unnatural to be done quickly and cleanly if your community doesn’t build plugins that work together out of the box. Netty + HTTP alone is a tricky combination without knowing Scala or Play. Spring MVC is for people who practice it enough to memorize the steps of configuration, and C# wants too much money for every tool I would need: Windows Server license, VS commercial, etc or lacks modern productivity (excluding NuGet). What I mean is, in most new frameworks and maybe WebStorm provides zero time startup of new projects and reloads your website as you’re coding so you can see the changes while typing. When you have a 2 month deadline every second adds up. Node and Express are mature technologies along with all the blazing NoSQL databases with proper ORMs like Mongoose. They have more established and working open source NPM packages that can be installed with one line inside your command line or IDE than Java’s Maven and .NET NuGet repository combined. Everything you will ever need is there, all in one folder without debug/release artifacts. In 3D world, Unity uses both C# and JavaScript and at the end it doesn’t really matter which one was picked. You can write production video games for consoles and browsers in both languages and they both have mature garbage collection. C# is good for large groups because the type checking makes sure everybody is not checking in mistakes. JavaScript is a sharp barber’s razor that will give you the clean professional production look with clean (no extra files or lines) source code as well. Want a new data object and start using it? Add one file to Mongoose and it magically appears in your database without having to open it. Do the same in SQL Management Studio… a lot more pausing to think about data architecture, but at least you get Lambda selection for conciseness in C#. CoffeeScript has Lambda too, and TypeScript adds types. Node has simple partials like Razor and can scale to the cores in your machine. Both have async.

      Bottom line is that theory is nice, and fun. You can be proud of it and look down on scripts even if they run on C++ and written on V8 by Google. Google is doing better than Bing by the way. You might have a fulfilling career ahead of you, I don’t know how your work life is. But if you want to ride on millions of dollars and make something big of yourself instead of being a religious student, you’re going to care about development momentum and WebSockets more advanced than SignalR. Your company will pay you a large equity if you can be trusted to get an infrastructure up within weeks and not bleed them with licensing fees which can range from $3000 to $30,000 to go live with enterprise editions of certain tools. That’s money out of your pockets. Datasource strings will seem to you an obscure and cryptic format while a mongo url looks like a regular http link. SQL can be fast, but MongoDB is faster Mongo inserts 10,000 documents in 2 seconds versus Microsoft SQL’s 204 seconds. That’s over 3 minutes that your one backend is locked up and out of threads in the pool. I’m sure 2 seconds feels more real-time to 10,000 concurrent users than staring at a loading screen for 3 minutes does.

      Do you want to be rich and not ignorant to tools that will help you do it for free? Put the book down and make a real plan to research and benchmark your choices. Go the scientific route, engineer. Global 100, multimillion startups, a mediocre degree, 10+ certs and 15 years of programming won’t lie to you. Care about your future enough to learn without pride.

      • Alex says :

        this is changing right now , and all is subjetive , we have the new .net asp core going open source , we have , we have webapi and owin , we have visual studio code , we have visual studio community , we have support for all the noSQL db on the .net plataform , you can go .NET without a single dollar man. i have to say im a .NET developer , begining right now with Rails and node , rail for me is awesome , simplistic to the core , easy , fast development , but i know MS is going in the right way , fighting , taking the strengths from others and merging it in the .net plataform , everything is awesome , so lets code in all the languages that exists.

      • Alex says :

        You started from C# and combined every product from microsoft, even MSSQL. What relation MSSQL has to the C# vs Node? Or what relation Mongo has to the question?
        FIY, I use mongo in C#.
        Honestly, I’m not happy with many things Microsoft does but I don’t see a better alternative to C# right bow. To be correct, I don’t see an alternative to C# + Resharper. I came here to find out if I can use Typescript + Nodejs, but single thread killed whole interest in NodeJS.
        To those who moved from C# to Javascript – I feel sorry for you. Look into Typescript.

      • Brett says :

        I’m sorry. I was actually listening to you up until you started claiming the benefits of Mongo vs. SQL server.

        Yes, in the tests that you linked to, Mongo handily beat down SQL Server. A real bashing to be sure. And no Admin worth his weight would ever let you use it. Why you ask? Because Mongo didn’t actually COMMIT any of those 10,000 documents to disk.

        Mongo always uses lazy commit, SQL Server never does. So at the end of that test you would have pulled the plug on your “production” server, your precious Mongo DB would have exactly 0 records in it. The SQL Server would have exactly 10,000 records still in it.

        So yeah, Mongo is blazing fast. So fast it doesn’t have time to keep your data safe.

        So please continue; Tell us how you’ve used Mongo in a mission critical production environment.

        • Brandon says :

          Haha! Nice one.

          I just stopped reading when mongo that post when a comparison to MSSQL was made of Mongo.

          I have used both, and never would use them in the same sentence, or paragraph.

          I use MSSQL for most of our web apps, on a daily basis, but am also trying to wrap my head around Azure Table as well. It is a different way of thinking in the design phase.

          I just love reading the comments of people who have never used certain technologies but because of some benchmarks they think that since language a can handle 10,000 iops on server x, that they will somehow create an application that would come close to throttling it.

          I will read a back and forth between two guys who have a total of 53 concurrent users on all of their live applications argue about their language being able to handle 150,000 concurrent requests so it is better, haha.

          I never hear people with extremely succesful applications completely bashing other languages, because we have usually built apps in many different languages with many different dbs, and hosted in many different environments. All have some strengths and weaknesses.

          We had a junior developer freak out this week when I coded a quick app in PHP, and he asked me, “You know PHP?” I said “Yeah, why”, He said, “Because when you hired me you told me to stay away from PHP and trained me in C#, I thought you speaking down on PHP meant you didn’t like or know it”. I told him, “I saw your code and know you need more structure, so PHP will not help you, being that some of the most spaghetti code I have ever looked at was in PHP and it was not the languages fault, it was the developer. Of course I can code in PHP and do so when I have a pre-built template that will allow me to get the job done, and done right, quickly. We don’t need security, authentication, async, etc for this app and I can get it out in a few days since I have one built from a few years ago” — Moral of the story, don’t bring a knife to a gun fight, or bring up Mongo and try to compare it to MSSQL, haha

        • Gee says :

          Talk about ignorance. Many of the largest companies in the world with the highest volume websites serving hundreds of millions of users use mongo in production.

          Saying mongo always uses lazy commits shows a complete misunderstanding of the nosql world in general and mongo in particular.

          Write concerns are highly configurable in mongo, all the way from fire and forget to journaling and acknowledged commits across an entire replica set. What you use would depend on the nature of the data, and what you are willing to trade-off in performance vs integrity.

          But where mongo and nosql shine are on the read side. From a read perspective it’s usually like using a data warehouse. No expensive join operations needed.

          Mongo is much easier to shard and scale horizontally, so it is a particularly good choice for cloud-based applications with very large data needs. When your SQL Server and your ‘safe’ normalized tables are grinding down a $500,000 server under the load of a few petabytes of data, mongo is still producing sub-millisecond responses on a network of cheap consumer boxes.

          Both are great tools and have their place, but to belittle a technology that you don’t understand just makes you look small.

          • BD9000 says :

            Unfortunately, MongoDB’s security, still has much to be desired as so many of these megauser sites have been hacked at the DB level at the cost of billions of dollars of litigation and more.
            This is the price you pay for free (take away all the DB checks & balances, of course it will be faster than SQLServer and Oracle, just not safe nor reliable).
            Thanks EquiFax! 🙂

  4. Dev says :

    Someone implemented a Reactor pattern with package management in JavaScript: “OMG, it’s the best thing in the world, static typing was invented for no reason, let’s dump it”.

  5. Pete says :

    Nice post! Well done and thanks for writing this up.

  6. Jon says :

    Ok, so I’m interested in node not because it’s “cool”, but because it’s *accessible*. I
    hate VS & I hate writing tons of code to get anything done. Also, I mostly use Javascript already. To Dev, (comment above,) I say, use Typescript if you like typed code. (I do too.)

    I’m unclear on one point this article makes:

    “…any CPU-intensive code you write will block the sytem and make your application slow.”

    Isn’t the proper approach here to simply put that CPU-intensive code in a child process, and let the main thread continue on it’s merry way? Granted, I’m just getting started with back-end dev, bur this is my impression thus far.

    That being said, I’m here for the purpose of due diligemce and informed decisions, so please do reply, (or, if you must, retort.)

    • Simon says :

      Indeed. I feel the author is incorrect when saying that Node.js can’t handle computation intensive work. The Node.js child_process module and its abstractions on top of it allow heavy computations that would otherwise block the main thread to be offloaded to child threads. These threads can communicate with the main thread by means of message passing and event handling.
      API Reference for child_process.send

      • eudaimos says :

        To be clear to those new to Node.js, using child_process will spawn new processes on the server, not threads. Child Processes do not have shared memory, but using child_process.fork or child_process.spawn will create a pipe that the parent & child process can be used to communicate with each other.

        Threads on the other hand execute within a Process and have shared memory space. AFAIK, threads aren’t implemented in Node.js, although there are some experimental projects going on to include them, despite the architectural decision to specifically not include threading in Node.js in order to not have to worry about shared state.

        • Eric Rasmussen says :

          Yes, exactly. Processes also induce a huge amount of overhead on the host operating system when compared to threads. You can start many thousands of threads and the OS will be fine. Trying starting a few hundred processes and the OS will begin to groan under the load of all the process management it’s trying to do.

          Node.JS’s handling of computation threads is terrible, unfortunately. I suspect this will be addressed in future releases.

          • Gee says :

            But you get no value out of thousands of threads. One thread per CPU core/hardware thread is ideal. One process per core is not much of a drain on an OS.

            The only value you get out of more threads is in blocking IO, which doesn’t happen in Node.

    • Glados says :

      > I hate VS & I hate writing tons of code

      You perhaps are in the wrong field. Thought of that?

  7. Gilles says :

    The benchmark comparing Node.js with WebApi self hosted and using async/await to do some I/O work shows that they are in par BUT what is surprising is that they achieve this with still a very different execution model. As far as I understand, in Node.js there is a single event queue (javascript queue) from which tasks are given to the underlying I/O sub-system (using libev library) and ASP.NET web api that sill takes the incoming http requests from the ASP.NET thread pool and efficiently does I/O with MS IOCP by just using the async/await and doing non CPU work…The way the incoming http requests are processed by the 2 platforms is still different…and that they lead to the same performance is surprising to me… One question I have is the following: provided that the machine used to test the 2 technologies had multiple CPUs (it’s a given), how many Node.js processes were run, each one having affinity with one CPU/core verses only one instance of the ASP.NET using all the cores available?

    • Andrew K says :

      This is what I’ve been thinking! To truly compare we’d have to spin up a node process bound to each core. That would truly be the test.

  8. VJ says :

    Nice writeup. Always good to know your apples from oranges.

    Only issue I have is with the statement:
    “This means that it’s not too hard to find, hire, and retain good .NET talent.”

    Not in my world. Or maybe you need to better define “good”.

  9. MarianoC says :


    I’m looking into node.js, just because I can, maybe, share some code between client web apps an the server side. I have my own framework developed in .NET, but I find myself usually writing and using js libraries for the browser/phone world. So, I need to convert my .NET objects to JSON then send them to the client and write compatible JS libraries mapping the same functions I wrote in .NET, receive JSON from the client and convert to my .NET objects and then map same functions. Trivial things like validation rules must be mapped between the two code bases. Business or application logic must be duplicated and coded at both sides. So, I’m starting to look at using JS on the server side, because it makes sense to share the code between the two.

    So? Am I right or should I use another approach? I foresee that web apps will rule the next generation of phone apps, because they are easier to write than native apps and people like the JQuery team are doing an excellent job on running over different platforms, better than MS, Apple and Google. So I think it make sense to start looking how to share JS code base… but I would like that to be easier. I would like to access to power of .NET from server side JS, but it seems that is one thing or the other…




    • Martijn says :

      (Thanks to the author for initiating a great discussion.)

      You are right.

      We are building a pure javascript (typescript) semi SPA backed up by a .net backend. On the moment a lot of our business logic, dto’s, mapping, validation rules and utils are duplicated in the frontend (js) and backend (c#). You could solve this duplication, indeed, by using javascript from end to end and share components between the front and back, and for that reason i am looking into NodeJs as well (as a .NET developer).

      However in our case it is better to adopt a pure SPA architecture where business logic, routing and navigation are moved from the back to the front. Then the backend becomes much more lightweight, processing is shifting to the front, duplication concerns diminish and we have a full JS (typescript) development stack. Only validation, authorisation and dataaccess is left for the backend.

      We are also considering an json/object db like MongoDb to get rid of ORM.

      • Julian says :

        “using javascript from end to end and share components between the front and back”. This is how the MeteorJS framework works. The backend is Node. You write javascript, and if for example you wrap it in: “if (Meteor.isClient) ” then it won’t run on the server. Meteor also implements a version of MongoDB in the browser (minimongo), so you interact directly data using Mongo calls and Meteor takes care of syncing with the “real DB”.

        I’ve just inherited a .NET MVC project and my brain is totally frazzled just trying to understand the spaghetti. I swear every line of existing code just marches happily off the right hand side of my 30″ monitor.

      • Arman says :

        It is always a good design to have server side validation since js can be disabled from the browser. If you do have server side and front-end validation, than I don’t see how you will skip duplication of code without doing round trip to the server. Am I missing something here?

    • Alex says :

      I also use C#. Also was thinking about code reuse, but what about security? If someone may find a bug in your validation logic they may use it. When you’ve got 2 implementations and 2nd one is a black box to hack the system is not that easy.

  10. Asshole says :

    SOoo how long have you been working for Microsoft again?

  11. Teemo says :

    “It would be very foolish and naive for a .NET developer to use .NET to solve every single problem just because “that’s what we use.”

    F _ _ _ you , if you can’t decide on a your main preference, don’t be so politically correct . As .NET developer I will solve every singe problem with .NET !!! why ? because I don’t care about the Node JS buzz , and I don’t use annoying-script-language when I have Visual Studio which is much better , I don’t work @ Microsfot , and I don’t have sympathy for Microsoft , sometimes I really want to kill Microsoft .

  12. Sloedough says :

    .NET vs. Mono vs. Node.js. Sometimes it is best to step back and look at the whole picture.

    Is using one language over another better? Is one platform better than the other? No! It is all about using the best tools for the job at hand.

    I am not jumping in head first with node.js, but I am weighing the pros and cons of many different platforms. And not just “New” or “Fast” but risk vs. profit. And so far Node.js benefits are outweighing the risks, even the risks in this article.

    I will not know until I benchmark each platform with the most intensive parts of my logic, based on my needs. Game On!

    • Ray Long says :

      Not all technologies are created equally. Sometimes, a particular framework/tool/etc. is objectively better than the competition, but I don’t think a priori blanket statements (based on one’s personal bias) over which tool is the best are meaningful since due diligence really demands bench-marking and evaluating each part of a system’s design.

  13. Shawn says :

    For me, migrating towards a not-only-Microsoft world I settled on Javascript for the client and Scala on the server. No need for limiting ourselves to just Nodejs.

    Scala is a superset of both C# and javascript in terms of functionality and expressive power. It has an even stronger type system than C# while simultaneously embracing a functional paradigm. Combined with Akka, it is a superfast, super powerful combination for building systems that scale from tiny to Netflix.

    Javascript (and HTML) is the most ubiquitous client side technology, period. Nodejs is great for native javascript tooling (e.g. stylus, grunt/gulp, etc.).

  14. Evert Wiesenekker says :

    Highly interesting article. I am mainly a C# developer which dropped MVC and Web Forms in favour of AngularJS for the client. For the server I use C# and ServiceStack for supplying REST services to my clients. If I (for fun) and experimental reasons rebuild my server to NodeJS will I have the same flexibility? For example C# has Linq and I can use constructions like:

    results.OrderBy(t => t).Skip(request.Skip).Take(request.Take).ToList();

    My datastore is now Reddis which ServiceStack has a a very good support for, like:

    using (var redis = RedisManager.GetClient())
    var redisObject = redis.As();
    return redisObject.GetValue(someId));

    I very much like serialisation of strongly typed classes to and from Reddis. I saw some NodeJS Reddis clients but get the feeling I will loose a lot of functionality and the risk of non maintained client libraries.

    As I can see a server is very easily created with NodeJS (and OWIN) but what if you have 1 virtual server which serves different websites. I now use IIS which can easily be configured using the bindings option.

  15. Shine says :

    Great post.

    But it didn’t mention that with micro services architecture and node package like PM2 or even a few lines of javascript spawning child processes in a stateless application can make the problem of blocking thread reduced to minimal.

  16. Alex says :

    Where are the new benchmarks WEB API 2 OWIN vs Nodejs ?

  17. Alex says :

    I have been using Node.js for two years now. It wasn’t my choice, the company who hired me insisted on using it. There are certainly advantages in terms of quick setup and deployment, but on the other hand people tend to forget that pure Javascript is a trouble on its own. It has caused so much problems to our development team when they needed to introduce new features and refactor code. You don’t get any warnings and red flags when referencing a non-existing variable, a simple typo will eventually make your code crash, but you would find out only when that particular piece code gets executed on the server. Neither do you get a warning if you pass an incorrect argument to a function. It lacks code readability, you’d see a function that someone else has written it, and you expect that you’d be able to reuse it, but wait… you can’t tell what arguments it actually receives just by looking at their names, especially if it accepts an object. What about the output of the function? You can’t tell that either, you need to read the entire code to figure it out. Do I even need to mention the callback hell and how ugly code can get? Sure, some of these issues can be overcome just by using Typescript and write unit and integration tests, which is what I strongly recommend. But what about autcomplete i.e intellisense? It sure has an effect on productivity on the developer, it wasn’t invented for nothing. Do you know how many times while writing I wished it’d give me precise suggestions for a method call based on the definition of the module or object? The countless times I needed to find the definition of a function by using Search instead of just clicking on it. I can go on until tomorrow and tell how Node.js can have a negative effect on a developer productivity. I’d recommend use it only if you have to, if it fits the purpose, and you want to do something quick and simple, but I certainly wouldn’t advise you to use it for complex enterprise projects where data integrity is crucial.

    • Jonh says :

      Check this:

      Node.js plugin for IntelliJ

      Node.js Tools for Visual Studio

    • Richard Eng says :

      Agree 100%. JavaScript is a truly execrable language. I would use Node if it was based on a better language like Go or Elixir. I’d use Go anyway; it’s better at concurrency and execution speed than Node (with JavaScript).

    • Chris Cummings says :

      I totally agree. The biggest cost in software is development and support. JavaScript is terrible and I just don’t get how the industry is so willing to throw away 40 years of compiler technology to switch to an unsafe / untyped language. This could be an even worse mistake like back in the 80s when C was adopted as the de-facto language with a heap-based memory model with no bounds checking. This was all done in the name of performance and gave birth to the whole virus nightmare. There should have been counted strings. The performance argument against bounds check was bogus. How much CPU time was wasted in the strlen() function? How must time was spent figuring out heap corruption bugs? Having JavaScript on the server is going to cost a lot of wasted time…

  18. Geraman says :

    The benchmark was run on a Windows Server 2008 R2, hosted on an c1.medium Amazon EC2 –instance.
    That’s the same as running nodejs in linux.

    In my opinion a real benchmark, would be two identical quipos one another C # + Windows + Linux nodejs because in very few cases nodejs be in a windows server in a production environment.

    But, as this explains:

  19. Ray says :

    To return to the point that Dmitry made on March 27 2014, How will the OWIN rather than NodeJS approach work on non windows OSs?

    Does MONO (on say Linux) support all the .Net 4.5 async goodness?

  20. Richard Smith says :

    I’ve come late to the conversation, but as a .net developer who’s only really started looking at node in the last few weeks this was a well articulated and informative article. Thanks.

  21. chosenbreed says :

    My thanks to the author for taking the time to shed some light on this subject. I’ve not read all the comments but as usually there are those who totally agree all the way to those who disagree. I for one think this is part of a healthy ecosystem. Having said that I do wish there was less of talking down of alternative programming languages, paradigms, platforms, etc. You’re excited about something? Rave about it all you want. Leave the smearing to the marketing dudes and politicians (I think they should do it less too!).

    • Jerry T says :

      Cheers to that. I’m always surprised how every blog post has someone screaming profanities just b/c someone else decided to use another programming language than what you are using. And many times the anger is over something so silly as the choice of a word. “You said ‘all’ when you should have said ‘some’. YOU SHOULD DIE!!!!!!!!!!” Why do so many developers have such anger issues? ?? Oh well, at least we have good quality blog posts like this to benefit from, even if the comments deteriorate into flame wars.

  22. John says :

    Just wanted to thank the author for a very well written and informative article.

  23. Mani says :

    I have good experience in both C# and javascript.

    For all my mobile development I use Javascript lot (React-Native, React). So I thought of give a try to nodejs for my server implementation.

    Node js pros:
    Very attractive
    Easy to start
    Lots of modules in npm
    Runs any where

    Lots of modules in npm, Really confused to select a proper one
    Javascript is not nice when my project grown

    Many moved from AngularJS to React, the reason is on AngularJS we have to write more lines of JS. But in React everything is organized using tags, This clearly shows that JS is not easy for complex apps. Think of writing an whole BANKing system in Node, it will be too hard. However we can move complex logics to Java or C#, and can create API using node js.

    C# fits everywhere, from large apps to small API. The only place it lacks is number of modules in nuget. however it has everything to develop application on any scale.

    Finally I had hard time to select proper ORM for nodejs, tried many popular ones. not that great, everything has many features. but some are not implemented in right way, it was hard to understand my own code after a week. Now moved to c#, I dont need to write a comment for my code, it is self explained.

    But if the team has high technical strength,Javascript can be chosen.

    I will continue to use Javascript for client and C# for server. Waiting for .net core so that I will move to linux.

    c# pros
    fits everywhere small to complex application
    performance is near or greater than node js
    good readable code
    static typed, and supports dynamic too, so select your style
    battle tested opensource libraries (eg: Dapper, ServiceStack, Nancy etc…) Identity

    c# cons
    not much community initiative, but improving
    Many people has anti Microsoft mind set (don’t know why)
    Can run on linux, but there is some level of hesitation on industry to use it on linux

  24. Tim says :

    Good read, and highlights some of the reasons I was avoiding of node at first.

    while I have found its great for serving up my angular static content and simple crud oriented API for ajax calls I don’t like the idea of complex logic in javascript. I couldn’t stand going back to nested loops over LINQ.

    That being said for simple apps I actually prefer node / express to MVC / Web API because of how fast I can get things done, and the fact that Linux hosting is almost always substantially cheaper.

    deploying a node app + mongo to say Digital Ocean will cost you tens of dollars vs Azure or AWS where your looking at potentially a hundred or more for IIS and SQL Server to power .NET apps.

    I am sure this will improve over time especially as dot net core gets more Linux friendly but as of now .NET is more expensive and more complex for simple needs.

  25. Alan says :

    This is great, same when stupid Java people come to tell about the most stupid programming language Scala

  26. Jimmy says :

    If node.js is using a C++ thread for each request then why would it not be good at cpu-intensive calculations?

  27. Tristan says :

    Thank you for the article! Nicely done. When we get accustomed to our tools, we can do great things in a short time. Like a carpenter with her trusty toolbox that grows by a tool / technique here and there. I have come to leverage the new RESTful api support in WCF services using Visual Studio and find that I can spin up pretty much anything a modern nodejs based stack can do in just about the same time. This is because I have my own boilerplate and plenty of examples in my toolkit. That being said however, it is absolutely true that there is a cost associated to managing Windows servers, not only in licensing, but the volume of virtual hardware resources required to make the whole thing work. I’m talking about something as “everyday” as an architecture that can support a thousand clients or so. So despite being more comfortable with .net , I can see the benefit of firing up an array of docker images running Node (and other things the cool kids are running) as logical nodes and peppering these about a virtual infrastructure. Much less costs per logical functional. I’m not too sure that development time would be dramatically less than a standard .net approach where the teams already have boilerplate and standards. All my ramblings to say, that the technical merit of Node is clear .. it works, and that’s really all that matters. Beyond the technical, there are costs. Costs to setup, license, maintain ..etc etc. It certainly seems that Node would win this battle. But is this a battle between .NET and Node? .. or is it really the old argument of Linux or Windows. Clearly anybody here running node in prod would most likely opt for running on Linux unless they were forced to use Windows. My two cents.

  28. ZP says :

    You forgot node cluster. The below is targeted at probably most of you. Sorry if I sound offended, I am, and no apologies for offending you will be offered.

    I’ve worked with .NET for 10 years, Java for 7. Written in Scala and Clojure. I prefer nodejs because it is simpler for a majority of development tasks.

    Point in my case, your mileage may vary depending on how quickly you adapt. I implemented an isomorphic CQRS implementation in 1.5 weeks with Node. Similar implementations took 12 weeks in Java and C#.

    It seems the entire argument here is also predicated on the fact that you are running a single node instance. Ever wonder why it’s called node? Who does that outside of a development environment. You use node cluster or nginx and handle your own scheduling. You can use koa for longer processing. Yes this is work. Node is a toolkit as much as it is a language. Yes you get some of this this for free by using languages like c# or Java and web servers like IIS or tomcat.

    You also get a simplified container, an enormous library of free code and a lot of language flexibility provided you understand the concept of scope and closures. Can you screw up and write bad code? Yes. This includes every language. I would posit that it is harder not easier to write good code in node than it is in a strongly typed language. You have fewer guardrails after all. So all you guys out there making statements about how node programmers aren’t real programmers are honestly, a little funny and you should probably go back to standup instead of posting contentious statements online.

    If you don’t like it, stick to C#, or Java, or whatever you write in. But please don’t make blanket statements about things you have an obvious bias about. It’s like you’re the anti “node guy”.

    Netflix OSS includes node. Linked in runs node on 3 servers for its entire network. Still think it’s not production capable, fast, scales, and can compete with “enterprise class languages”? Guess all those guys are idiots and you’re right.

    Would I write an ANN in node? No. Would I write a 3D fps in node? No. Does it have its applications, yes. Are they wide and cover most of the common usages of languages like C# and Java? Yes.

    It’s a tool, like any other. I know 12 languages, and JavaScript and node is just one I use to solve problems.

    Anyone advocating blanket statements like this in either direction needs to give up their developer card.

    • J says :

      Well said! This article seems rather biased toward .NET. I used to work on .NET for 10 years and I can say after the bloated nonsense, service packs, nuget mess I am happier with Node.

      Adios .Net

  29. Gus says :

    Clearly with what’s been going on with .NET Core this subject needs review. I am looking at Node purely because my friends are using it and having fun with it. However, I use .NET NancyFx and this was not mentioned in this post. Nancy is a brilliant little framework that cuts out all the bloat and trouble from building .NET apps.
    You can self host or with OWIN:
    And you can run it on Linux or OSX without too much trouble.
    Nancy also supports async.
    Although I will take Node for a spin it’s hard to see a real benefit in switching from NancyFx/C#/Razor given how simple it is to get up and running with a Nancy template for VS, a db wrapper like Simpe.Data and a few other essentials.
    What worries me about Node is myself. Do I trust myself with a language like javascript? The article mentions how the popularity of Node stems in part from the way that devs with a smattering of js knowledge can be up and running in no time. But. Given the easy to fall into pitfalls of js, are they walking headlong into a nightmare? I find js a pretty confusing language to work with compared to C#.

  30. Richard Eng says :

    I agree that Node is a pretty good piece of technology. The problem I have with Node is that I have to use JavaScript (or TypeScript, which is a strict superset of JavaScript). I think JavaScript is a really, really horrible language.
    JavaScript is very weakly typed. No other major language is. This explains many of its long list of WATs and WTFs that make JavaScript the butt of many jokes.
    JavaScript can fail silently for syntactical reasons!!!
    JavaScript doesn’t have an integer data type. (What??? Say that again.) JavaScript doesn’t have a proper array type.
    JavaScript requires the use of linters (which are not infallible) just to avoid the many landmines in the language. I can’t think of another language that requires linters. Can you?
    JavaScript requires added discipline to use properly (see Douglas Crockford’s JavaScript: The Good Parts).
    I’ll stop now. I could go on and on and on, but you get the point.
    I’ve used so many languages in my 20+ years in IT (Fortran, Tandem TAL, C, C++, C#, Objective-C, Java, Python, Smalltalk). I’ve never seen anything as execrable as JavaScript. It’s a great pity that Node was based on such a language. Philosophically, then, I have to avoid Node.
    I much prefer Go language as an alternative. Most of the same benefits, but without the JavaScript crap.

    • Korr says :

      It’s fair to say that js has it’s limitations. What about using some of the many js pre-compilers? As a .net dev looking for a more productive stack I’m exploring clojure on node (amongst a lot of other things) and having a good bit of fun.

    • J says :

      Ever used unit tests? Anyone who doesn’t use unit tests with Node is looking for trouble and this goes for any language.

  31. James says :

    .NET C#,VB.NET… ok, compiled language is fast. Checked, Nodejs javascript a little slower, Checked.

    In production environment, I present you: The Hell of Microsoft
    .NET DLL Hell
    Windows Server Farm License Hell
    IIS Server Farm Hell
    SQL Server License Hell

    Let’s put it this way, if Netflix, Uber, Google, Amazon or PokemonGo used Microsoft .Net, MS will say:

    “All Your Bases are mine”

    The truth is Linux, Nodejs (and all the npms), Docker, Postgres, Mongodb, RethinkDB… and a sleth of other open source technologies able to run these enterprises without paying much ‘server licensing’ give us no excuse not to use this wonderful knowledge from Open Source communities.

    • Rick says :

      Everyone wants to make a living writing software but nobody wants to pay for the software that they use to write that software.

      It’s an interesting thing that happens in the software world. Imagine a carpenter not wanting to pay for his tools but wanting to get paid for the shelf he built you. Seems a bit odd when you look at it this way doesn’t it?

      Someone else put this correctly above I think. This is more of the same *nix vs Windows that has been going on for decades. If you’re a Windows person you’re more likely to be cool with .NET and the MS ecosystem. If you’re a *nix person (includes you Mac’s) you’re more likely to seek out other means.

      Some corporations like having the creator of the entire stack that they can call and blame when things go wrong. They see it as risk avoidance. MS fills that need. Some people like having full control of everything and want to be able to fix it themselves. The *nix world fills that need. These are just human preferences at their core.

  32. Peter G says :

    Interesting discussion! As a realtime control systems developer it has always been a struggle to try and take advantage of new technologies, either hardware or software, either frameworks or protocols. One thing remains after programming for over 35 years we still haven’t created anything similar to what nature created in terms of the blueprint for life, a cell with DNA. Once we get our heads around that pattern we won’t have to worry about which language, framework or technology is better, faster or cheaper.

  33. tunca says :

    .NET Core and Angular 2 is way to go!
    No place for non strongly typed languages.

  34. Aleksa says :

    Just one question. If Node.js was not free and if u have to pay like u have for Microsoft technologies, how many people would use it? NO ONE!

  35. Technology Dev says :

    I found the comments of this post more interesting (and more annoying) then the post itself. The author is correct in that both .Net and Node (and JS) are great.
    I’m a .Net developer with over 15 years professional .Net experience, and the last 3 years I’ve been building pure SPA’s, REST API’s (using node/express) and I must admit I do almost 100% JS coding now and only go into C# if I’m doing something client/server. Why? Do I think that Node is hip, and coolness, and do I just want to be one of the cool kids? Well, perhaps I do want all of those things but…not that’s not why I switched. I didn’t one day wake up and say, Node is better than .Net, PEACE! What happened was, I evolved. One day I finally (and reluctantly) migrated from Web Forms to MVC, and not long after that I jumped onto the SPA bandwagon because I liked the nice clean separation, de-coupling, standards-based web development. As a natural result, I learned JavaScript more and more until I was just as good (or probably these days better than) I was at C#. Server’s shouldn’t be dishing out HTML, they should be dishing out JSON, and the website shouldn’t be posting to the server every time the view needs to change, than should be handled client-side and when a data interaction needs to happen, then the two sides talk. After building enough SPA’s, and refining my toolkit, I eventually found myself still working in Visual Studio (the best IDE ever) but just using a Default.aspx page, with an empty code behind, and then folders and folders of javascript for the application logic. It was easier to learn Node/Express than to go WebAPI – because I’ve been doing JS for so long – and like other people mentioned, I like it’s simplicity. Before I knew it, I was a JS/Node guy – and I like it. I work with a bunch of C# developers and we joke around about tech and languages but the reality is you should use what’s simple and consistent. and I find HTML/CSS/JS client-side, and just pure/JS server-side to be a good toolkit. by the way, I was already well-versed in IIS and found IIS-Node to be a good solution to managing Node apps. I think the author mentioned that you don’t want to send a heavy process to Node because its initially single-threaded – but if you use Node-JS that’s not true, IIS will actaully spawn and load-balance Node apps for you based on need. Yes you still need Windows Server but I have that anyway so it’s not a problem for me. I laughed when I read one person’s comment that “JS is not as powerful as C#”. Lol, define powerful? JS is a language that is interpreted by something like V8 (written in C++) which is actually what Node uses. So on the server, you JS in Node is converted into pure C++/C (and some assembly) – it is very powerful, make no mistake. That’s all I have to say, I hope it helps someone.

    • rickg says :

      Thank you, your comment helped me a ton. I’m a .net stack c# guy with 15 or so years pro experiences and it sounds like we have a similar mindset.

      Thanks again for the excellent and thorough comment.

  36. Jim Wilson says :

    Might want to rerun your analysis with dotnet core without web api middleware vs. node.

  37. Damiano says :

    Ok can you show me the .NET equivalent of a setInterval and setTimeout keeping in mind that code will have to be invoked from an API end point.

    (btw I have been 80% of my career mostly .NET, yet I think node.js is far superior because of its simplicity and flexibility, also because of javascript of course)

Leave a Reply

Your email address will not be published. Required fields are marked *