Exploring Node.js for .NET Developers at Conferences

Over the last few months I’ve had the opportunity to present at a few conferences on the subject of Node.js. No surprise, most of the folks I get to talk to are .NET developers who are interested in learning what Node.js is. In this post I wanted to explain what Node.js is for the .NET developer. Let me very clear: I’m not trying to say one thing is better than the other. In my eyes it’s another tool in your toolbox. I’m not trying to convince you to use one over the other… I’m just drawing some analogies that I find to help you get a jump start on picking up a technology that may be new to you.

First: Why I Like Node.js

Before I get started, I want to throw my opinion in here. After a more than six months working with Node.js I can say I’m a fan. For me the biggest appeal is that I can use one language across my entire solution from the client-side web application to the server side API / MVC site (via Node.js) to the tooling, build (using Gulp) & deployment process. I can use the same language and for the most part the same tools for all my tests including those tests for the client-side web application and the server-side site. I like how the same tooling can be used across the whole stack. I like how it’s cross platform so I can use it to create applications using Windows or OS X (or even Linux which I don’t use) that can be hosted in any environment including Azure web apps or even micro controllers like Anduino’s or Raspberry Pi’s.

I often get the question “Do I like it more than .NET?” or ”Would you recommend it over .NET?” My answer to that is no but not why you think. I don’t recommend .NET or Node.js over either one… to me, it’s just another tool in the toolbox. You pick what’s best for you, your project, your company and your team. To broadly say .NET is better or worse than Node.js or vice versa in a vacuum is simply irresponsible in my eyes.

OK, onto the post…

Node.js Overview

What is Node.js? Node is a cross-platform runtime wrapper around V8 that gives your JavaScript programs APIs to work with things like the network stack or filesystem or other host environment things such as environment variables or OS things.

What is V8? This is the JavaScript runtime that Google wrote that can be found within the Chromium project which is at the core of the Google Chrome browser. What Node.js does is load your JavaScript program into the V8 engine for execution and provide APIs to your program to talk to server-side processes.

What about external libraries? You know how in the .NET world we have a way to distribute packages across projects very easily using NuGet? Well we have a similar packaging system in Node.js as well called the Node Package Manager but everyone calls it npm. There are a huge number of packages available. There are plenty of similarities but there are some very key differences such as:

• npm is unopinioned whereas NuGet is opinionated: With NuGet, all packages will live in the solution or project’s /packages folder. While npm does put npm packages in a folder named node_modules, you can change this with a setting in the packages.json file which serves the same purpose as NuGet’s packages.config file.
• npm packages don’t share dependencies: With NuGet, when you download a package, it may have dependent packages but they are downloaded at a parallel level to each other. However with NuGet npm, each package downloads it’s own dependencies as subfolders within the current package. This is a good and bad thing… it’s good because you never get conflicts, but it’s bad because it can lead to some crazy deep folder structures which cause hell trying to resolve on Windows.
• npm packages are used to deploy tools as well: NuGet is only used to deploy code packages. While npm is used for the same thing, it’s also used to deploy full blown executables. For instance the cross platform Azure command line interface (CLI) is distributed using npm.
• npm packages can be installed locally or globally: All NuGet packages are installed locally to a project or solution, but npm gives you the option to install packages globally as well. This is handy when you have things like the Azure CLI that you want to access from anywhere on your system.

One big difference between Node.js & ASP.NET (and IIS for that matter) is that with ASP.NET & IIS you basically get everything you need to host your site. You get the MVC framework, view & tempting engine (in Razor), logging, authentication… you name it. However with Node.js, you really don’t get anything. You just get an execution environment. If you want logging you need to get a module for that. Authentication? Go get something. Cookie management & session support? Again, you need to get a module. This is good and bad. It’s bad because you have to go assemble everything you need, but it’s good in that you don’t have this bloated stack of stuff that you might not use.

What’s this Node.js & io.js Deal?

Here’s the shortest history on it: The main contributors for Node.js got pissed at the lack of progress and openness in 2014 and forked it to io.js. There a ton of progress was made, but it also started to diverge from Node.js. However in the last few months, they’ve come back together for the good.

Node.js Set up

Installing Node.js is very simple… You simply head over to the Node.js website and download an installer. It will give you the latest version of Node.js and npm in one package.

If you’re installing Node.js on Windows, check this post out: John Papa: Tips for Running Node and npm on Windows.

But if you’re on OS X, when you try to install a npm package globally you gave to run SUDO (like “Run as Administrator” on Windows) because they are installed in a global spot that requires admin rights.

What I do is use this process John Papa composed to install global packages in my user directory so I don’t need admin permissions when I install globally. Check his article out here for details: John Papa: How to use npm Global Without Sudo on OSX.