7 Reasons for Startups to Choose ASP.NET Over Node.js

Node.js is probably the most popular backend technology in the industry. Companies like Twitter, LinkedIn, Uber, and many others use Node.js as their primary server technology or combine it with other languages. It has a lot of things going for it like a huge community, a great ecosystem, and it uses the same language in the front end and back end.

Since C# and .NET are my main programming languages, I’m trying to figure out if I’m using an underrated technology or if the market trend has a point. ASP.NET, the .NET server framework, is popular in its own right. Ever since the .NET runtime became open source and cross-platform, it’s been improving and gaining popularity, but it’s still far from Node.js, especially among startups.

I recently wrote an article about the pros of Node.js and why startups are all-in on this tech. But taking the other side of the argument, .NET has a lot of advantages as well, ones I know very well. Here are 7 reasons for startups to consider choosing .NET over Node.

1. .NET has better Performance

Performance is the biggest weakness of Node.js. Not to say that Node.js is unbearably slow, but when you need any sort of computation on the backend or a high throughput of requests, Node.js isn’t a good choice. The main reason is that the runtime is single-threaded, which is a big waste with today’s multi-core processors that allow executing many operations in parallel. Recent benchmarks in techempower show Node.js is far behind ASP.NET Core.

.NET is not the fastest tech. That title would probably go to some minimalistic Rust or C++ implementation. But out of the mainstream web frameworks (excluding niche projects like Just or may_minihttp ), it’s one of the fastest.

Single query benchmark:

Multiple queries benchmark:

Fortune cookie benchmark:

2. Node.js requires to mix & match languages to compensate for performance

When looking deeper into tech stacks of companies that chose Node.js, it’s almost always used in a microservice architecture combined with other languages and runtimes like Go, Rust, Java, and Python. Node.js and JavaScript are great for high-level REST servers that just send queries to a database, a queue, or another service. It’s not good, however, when you need to do some compute work, like run an algorithm or work with the file system.

C# and the .NET runtime, in contrast, are fast and versatile. In most use cases, you won’t need to use a native language like Rust or C++ to gain an extra performance benefit. This means that you can save the overhead of adding an additional language to your project’s tech stack. Another language is always best avoided because you’ll need more specialists, more infrastructure, and the teams become less versatile.

3. C# is an amazing language

It’s hard to argue about which language is better. Everyone has their preferences and biases. But I’d claim C# is one of the most powerful, productive, and popular languages in the industry right now.

• It’s a high-level c-style object-oriented language, which will be familiar and productive for most developers.
• Despite being a high-level language, it allows low-level control over sensitive code when needed for performance optimizations. You can work with pointers and direct access memory access if you choose to.
• It has rich functional language capabilities like LINQ and extension methods .
• It’s type-safe, much more so than TypeScript, but it also has dynamic capabilities like JavaScript when you need them.
• It has great documentation and a sizeable community. Not as big as in the realm of JavaScript development, but still very big.

A few examples of projects using C# are the Bing search engine, StackOverflow, and Unity (the most popular game engine) which lets you use C# as the programming language.

4. Best tooling available

I’d argue that C# has the best tools in the world. The best IDEs, the best debugging experience, and the best profilers.

JavaScript or TypeScript doesn’t have the strongly-typed nature of C#, so advanced code navigation and refactorings aren’t possible. In many cases, it’s not feasible to know who implements your interface or who references your class’s function. Often Node.js has to rely on basic text search, whereas in C# IDEs you can navigate to usage and implementations with a shortcut key. The same goes for powerful refactor capabilities, like implementing interfaces, adding parameters, and extracting functions or classes. If you’ve been using Visual Studio or Rider for a long time, you’ll probably experience a real loss in productivity moving to Visual Studio Code.

As far as debugging concerns, the Chrome Developer Tools debugger or VSCode debugger don’t come close to Visual Studio’s experience. I might be a bit biased since I know all the features in .NET, having written a book about it , but I’m a rather average user when it comes to debugging Node.js.

5. Easier built-in development loop

In Node.js you can build your development environment pipeline in any way you want with tools like Babel, Webpack , ESLint , etc. You can use different JavaScript versions, bundle everything into a single file or to many slices, minify, and more. This is a very customizable process. There are many different tools for every part of the pipeline. Webpack can be replaced by Rollup or Parcel , ESLint can be changed to prettier , etc. There are a million different ways to build your JavaScript project and every single company seems to have its own unique setup. A setup that requires a whole lot of development and maintenance. Although I have to admit there are modern ways to get a rich development environment up and running quickly with tools like Vite .

The situation in .NET is quite the opposite. There are not many technological choices in your build setup because you’ll always be using Microsoft’s MSBuild, .NET SDK, and Visual Studio. You can do some customization, sure, but it’s nothing like a JavaScript project. The only “choices” you’ll be doing are which .NET version to use, which is always going to be the latest, and which type of project you’re building: ASP.NET Web API or ASP.NET MVC, which should be an obvious choice depending on how you want to develop the front-end.

So you can consider the flexibility of Node.js an advantage, which is reasonable, but you can also look at it as a liability. In .NET development, there’s not much that needs to be done with the development environment except in very big projects or special cases. Visual Studio and MSBuild just work and they can handle huge enterprise applications and servers without too many problems.

6. Stable ecosystem

As just mentioned, Node.js and JavaScript have a very rich ecosystem. That includes development tooling, libraries, documentation, etc. For better or worse, this ecosystem is mostly open-source and developed by the community. In many cases, a library you depend on is developed by a small team or even a single person. If that person decides to stop working on the project, you’re screwed. Sure, someone else could pick up the work, or you can fork it yourself and add whatever missing piece you need, but that’s a big hassle for a startup that sprints to create its first product. It’s not the only problem with small open-source projects. What happens when they introduce bugs or security breaches? The maintainers aren’t exactly accountable if their hobby project caused damage to your startup, are they?

I’m not saying big companies don’t have bugs in their products. They might have more for all I know. But you can complain, open a ticket, and even sue Microsoft. You can be certain that a project will continue to be supported for a very long time, and if it stops being supported, you’ll get a notice a few years in advance. As far as stability and reliability, I’m betting the Microsoft .NET runtime and all its tooling are better tested than most open-source libraries for Node.js. This might cost in slower version releases, but it will be more stable.

Having said that, there are plenty of well-maintained libraries that have many contributors and are well-backed by big companies.

7. Compliance, privacy, and security

This argument is based mostly on common sense, not on my experience or expertise. Sorry in advance if I’m making some false assumptions.

You might not consider compliance issues as important or particularly interesting when beginning a startup. I’d imagine founders are focused on making a product, hiring, raising funds, and choosing the company’s logo. But it’s one of the most important aspects of your product. In some industries, like healthcare, military, and government, it’s crucial that your app will be secure, protect personal information, and comply with standards like HIPAA , GDPR , and ISO 27001 . Even if you’re not working in such an organization, you probably want the big customers that do care about these things.

Going back to our choice of technology, does it matter for compliance/privacy/security if you choose Node.js or ASP.NET? Applications running on both technologies can be compliant with standards or not, secure or not, and protected for privacy or not. But when you choose Node.js, you also choose to use open-source libraries and ecosystems. There’s a bigger chance that some library has security or privacy breaches. And there’s a much bigger chance these projects don’t adhere to the crazy standards Microsoft sets for itself in terms of compliance. And even if you’re taking the best steps to secure your application, doing penetration testing and whatnot, you can’t compete with Microsoft’s reputation. If a government customer knows you’re using Microsoft tech stack from top to bottom, they’ll be more likely to trust your app.

Finishing up

I hope I convinced you of at least some of these points. A lot of the arguments are subjective, like who has better tooling, or which programming language is better. I’ll be the first to admit Node.js has advantages over ASP.NET as well, as I wrote in my previous article 8 reasons startups prefer Node.js over .NET, and are they justified? . What’s your opinion? Write a comment below and let me know. Cheers.