8 reasons startups prefer Node.js over .NET, and are they justified?

I’ve been a .NET software developer for my entire career, and I love it. I love the C# language, the productivity of the platform, and the ecosystem. But I’ve been dealing with an existential crisis for years now. I see how companies, especially startups, don’t seem to choose .NET as their platform of choice. That role seems to be reserved to Node.js in recent years [1] [2] [3] .

Over the last few years, I got to work with Node.js myself and I think I finally understand why it’s so popular. Below are 8 reasons why I believe startups prefer Node.js over .NET. Some of those reasons are justified, some used to be true in the past but not anymore, and some are false perceptions that somehow got to be popular opinions.

Disclaimer: I’m currently a Microsoft employee. All opinions in this blog are my own. I have no relation to the .NET development team within Microsoft.

1. You can get started quicker with Node.js?

I think Node.js was able to crack the formula to make server development painless very early on. After installing Node.js, you write a few lines of JavaScript code, run node myapp.js in the command line, and get a running server. For most software developers, this is love at first sight.

// Example with Express.js, one of the most popular Node.js frameworks
const express = require('express')
const app = express()
const port = 3000

app.get('/', (req, res) => {
  res.send('Hello World!')
})

app.listen(port, () => {
  console.log(`Example app listening on port ${port}`)
})

Up until recently, the ASP.NET template of a simple “hello world” API was 6 files and 160 lines of boilerplate code. An ASP.NET project included a whole lot of ceremony with its Controllers, route attributes, and the cumbersome Startup class. In .NET 6 (released in November 2021), Minimal APIs were introduced, which makes new projects much simpler. In fact, a hello world .NET template has even fewer lines of code than that of Node.js. So even though it will take a while for the reputation to change, .NET is on the right track.

The verdict here is that this reason used to be true but not anymore.

2. Node.js gives a faster development feedback loop?

In Node.js, there is no compilation, since JavaScript runs with an interpreter. But you have other steps like linting, transpiling, and bundling. When you make a change, these steps have to be executed and the server or module should restart. When done automatically on each change, it’s called live reload and Node.js can do this with tools like nodemon . This live reload is usually so fast that by the time you’re checking your app, the change is already active. You’re getting feedback on your code changes practically immediately.

In .NET, on the other hand, a build is required to compile C# to byte code. Moreover, .NET projects are usually bigger, at least in my experience, so the build takes a lot of time. Sometimes minutes– an infinity in developer time. And up to recently, each change required you to manually stop execution and rebuild the project, adding many dead minutes to your day.

As of .NET 6, released in November 2021, ASP.NET Core 6 supports hot reload . This is a big win for .NET and should make development much nicer. When possible, hot reload doesn’t restart the app, but rather applies code changes while preserving the app state. A better experience than in Node.js potentially.

The initial build aside, the experience in .NET should be even better than in Node. There are some caveats to this. Such big features tend to need a few versions to get better, which we’re already seeing with hot reload improvements in .NET 7 . And most .NET projects will need to upgrade to .NET 6+ to enjoy this, which can be a big deal, especially if you’re still on .NET Framework.

The verdict here is that Node.js used to be much better, and still is for most existing projects, but looks like .NET is going to give an even better experience moving forward.

3. Node.js development is more lightweight?

Node.js was always perceived as a lightweight development experience. It’s quick to start with, build times are fast, you code in a fast editor like Visual Studio Code, and you do everything with the command line.

.NET, on the other hand, is associated with slow and bulky tools like Visual Studio, IIS Manager, and SQL Server Management Studio. Many dev shops use Visual Studio with ReSharper, which destroys IDE performance. Instead of the command line, like in Node.js, the .NET ecosystem appears to have UI for everything, which is easier to use at first, but slower than the command line. In addition, a Node server appears as a simple console window, whereas .NET uses IIS Express with its hundreds of settings and know-how.

I think some of those arguments are justified. While you can code nowadays with VS Code or Rider, most .NET development is done with Visual Studio on Windows. In many cases, programmers use extensions like ReSharper that makes everything slow, even with fast development machines. But you don’t have to use ReSharper or even Visual Studio to write C# code. You can use Visual Studio Code with the right extensions and get the same text editor feel as in JavaScript. And you can use the command line to run your .NET Core apps, just like in Node.js. As for the console window experience, the newer .NET Core can do the same thing, without IIS Express.

For the verdict for this, I think that while .NET allows for an experience similar to Node, most developers do use heavier tools like Visual Studio and ReSharper, so this argument is somewhat justified. Though these tools provide a ton of value, which is actually a big point in favor of .NET.

4. Node.js allows full-stack JavaScript code

I have to admit there are advantages to having the front-end and back-end use the same language. You can have shared DTOs and shared libraries. Serialization issues are little to none. And your front-end and back-end teams understand each other better. You can, for example, use the same developers for back-end tasks and front-end tasks.

I guess I could argue that .NET has Blazor now, which allows one to write C# in the front-end and back-end both. However, this technology seems more of a niche still and far from penetrating the industry mainstream.

You could also claim that mixing the front and back ends is bad, that it creates coupling and leads to unnecessary dependencies. I guess it does add another way you could shoot yourself in the foot, but that shouldn’t be a reason not to use something good.

This argument is justified and an advantage of Node.js, especially if you have a heavily JS-oriented existing team.

5. Node.js is faster for non-compute requests?

Node.js has a reputation for being able to handle a high load of requests, even though it’s single-threaded and uses the V8 JavaScript Engine (not the fastest of runtimes). It does so by the magic of asynchronous I/O operations and the event loop. When something like a database request operation waits for a response, Node.js frees its only thread for other requests. Once done, a callback function is queued on the main thread with the result. This allows the execution of many requests in parallel, whereas, in other multi-threaded languages, a dedicated thread supposedly waits for the I/O operation to finish. At least that’s how the story is often told .

In truth, modern languages like .NET can utilize the same I/O completion port mechanism and support async operations without hanging a thread. In fact, most benchmarks show that .NET Core is faster and can handle a higher load than Node.js. For example, here’s the latest multiple queries benchmark from techempower.com :

Perhaps when Node.js started, it was faster, I don’t know. But, regardless of the reality, the reputation remains. This reason is a false perception that somehow stuck in people’s minds.

6. The .NET story keeps changing?

Node.js has been very consistent for over 10 years. You write pretty much the same code now as you did in the first release. The innovations are in newer JavaScript versions, evolution of the ecosystem, and new frameworks like Express . Not so with .NET where each version requires different code, different dependencies, or a different approach entirely.

In 2012, ASP.NET Web API was introduced and allowed to work with front-end single page applications. In 2016, .NET Core 1.0 was released, which was open source, added a decent command-line interface, and most importantly allowed cross-platform development. This was great, but it changed how we write ASP.NET applications (adding middleware, dependency injection, project.json, etc). Not to mention that all of the existing apps and libraries from .NET Framework didn’t work with the new stuff. Then, each new version of .NET Core changed things, like removing project.json , adding SDK-style csproj , and in .NET Core 6 we get an entirely new story with Minimal APIs. And we also have Blazor Server , which is something different entirely, but also a part of the ASP.NET family.

Don’t get me wrong, most of those changes are huge improvements, and the .NET ecosystem is famous for its backward compatibility. But from the outside, it looks like Microsoft is announcing the great new thing every 2-3 years and you always know there’s going to be a different great new thing sooner than later.

Having said that, since .NET Core 3.0 in 2019, the story has been pretty consistent. The backbone of the framework remains the same and each version adds mostly new functionality and performance improvements. Minimal APIs is an outlier because it allows a new way to construct your app, removing much of the ceremony, but the infrastructure of the app, like how the middleware and dependency injection works, remains the same. As for Blazor, it’s a whole different thing that gets a lot of hype and mostly confuses everyone. So I’d say this argument to use Node.js over ASP.NET used to be true, but not anymore.

7. .NET requires working on Windows?

When your startup is getting started and making its first technology choices, it might not want to use Windows computers for whatever reason. Web developers, especially silicon valley developers, really like their Macs for some strange reason. So if .NET locks you to Windows, it can be a deal breaker for some founders. But is it really necessary to use Windows for .NET?

.NET has made big changes since its first release 20 years ago. The initial policy was to run exclusively on Windows, to encourage customers to use Windows everywhere, but that policy changed 180 degrees. .NET Core 1.0 was released in 2016 as an open-source and cross-platform runtime. As far as tooling for .NET is concerned, it wouldn’t be true to say Windows, Linux, and Mac are equal.

The most popular IDE for .NET, Visual Studio, is Windows-only. There’s Visual Studio for Mac , but it’s Xamarin Studio, a different product that was rebranded. There are two other great cross-platform options: Rider , the IntelliJ and ReSharper-based IDE from JetBrains, and Visual Studio Code. I’d say those make a powerful IDE selection, at least on par with Node.js options, which are usually going to be Visual Studio Code as well.

But there are other tools and considerations like debugging, crash monitoring, performance counters, and profiling. Visual Studio for Windows has the best debugger, but VS Code and Rider are not bad. For troubleshooting, Windows has some unique tools like PerfView and WER . But there’s decent support for Linux as well, like the .NET SDK command-line tools dotnet-dump , dotnet-counter , dotnet-trace , and most of the JetBrains suite of tools for .NET (Rider , dotTrace , dotMemory ). In some cases, you’ll have to use a command-line tool to capture a snapshot or a crash dump on Linux, copy it to a Windows machine, and open it with PerfView or dotMemory. But I wouldn’t count those rare cases as vendor lock-in to Windows.

Node.js enjoys the cross-platform Chrome developer tools, which are good and consistent on all operating systems.

I’d say you absolutely can develop .NET Core apps on non-Windows machines. In relatively rare cases, you’ll have to use worse tooling, and you might even have to use Windows once in a blue moon.

8. Node.js has a better ecosystem?

.NET and Node.js have polarized approaches when it comes to the development ecosystem. In .NET, Microsoft tools like Visual Studio and .NET SDK take care of everything. They will build, lint, optimize, and deploy your services. In Node.js, on the other hand, you get a clean slate, and you have to add 3rd party tools for everything. These tools might be bundlers like Webpack, linters like ESLint, transpilers like Babel, and language transcompilers like TypeScript. Node.js provides a template, but it’s just an initial collection of libraries.

You can argue about which approach is better. The approach in .NET is easier and more stable. Whereas in JavaScript development you’ll quickly have to deal with Webpack plugins, package.json tasks, linting configurations, and whatnot. But I think Node.js has a big advantage here because it has a free market of sorts for libraries. In Node.js, each problem has multiple good solutions, and you get to choose what suits your projects. The rules of evolution dictate that having many options is better because the best solutions survive. Besides, Node.js has an unfair advantage here because it shares an ecosystem with the entire front-end development community.

The JavaScript ecosystem is not void of problems. There are so many solutions that choosing among them is a task on its own. Even keeping track of all the new libraries is difficult. Most of the library maintainers are mostly volunteers, so stability is sometimes an issue, key developers might stop contributing for whatever reason and a library can die or stagnate, and there are more concerns for security and privacy. In contrast, the protective bubble Microsoft created for .NET saves a lot of work and concerns.

So which ecosystem is better? The free market of 3rd party libraries? Or the protective bubble of one (huge) company supported by hundreds of well-paid engineers? I think I’ll leave this one open-ended.

Finishing up

I think Node.js has a good case to justify its popularity. It has a great ecosystem, community, and tools. It allows fast development with a quick feedback loop and responsive tools. And it uses the same language as in front-end code, which contributes to better collaboration and code sharing.

.NET has gotten a lot better over the years. In some areas, it was worse than Node.js, but it closed the gap. In other cases, like with performance and hot reload, it surpassed Node.js. In many cases though, these platforms are just different and it’s harder to judge which is better. Like the choice of language or the differences in the ecosystem.

If you got strong opinions about this, go ahead and leave a comment below.

Note the role of Microsoft in this popularity contest. Although it’s the primary owner of the .NET ecosystem, it wouldn’t be fair to say it’s Microsoft tech vs non-Microsoft or open-source tech. Microsoft has been a massive contributor to the JS ecosystem, developing Visual Studio Code and the TypeScript language for example. After purchasing GitHub, Microsoft is even the owner of npm .