by jiggawatts | 2025-06-26 11:07:56+00:00
ASP.NET Just Works and has Batteries Included.

As an example, just over the last few days, I hit all of these common issues with Node.js apps (that don't happen with ASP.NET):

1) Node apps are typically a "transpiled language on a language" because JavaScript is unusable for large-scale software development so everyone uses TypeScript compiled to JavaScript instead. But this is a hack! A clever, useful hack, but a hack nonetheless. You can't go two steps without finding the rough edges, such as "any" everywhere or the use of "monkeypatching" which makes static analysis impossible for either tools or humans. (This reminds me of the earliest days of C++ where compilers like Cfront transpiled C++ to C.)

2) It's single-threaded! Sure, this is simpler, right up until it's not. It means you need about one process per core. Which means that on typical hardware you get a max of 4-8 GB of memory per process, because that's what most hardware has per core. This means in-memory caching is generally too inefficient. (I finally understand why Redis is so popular!)

2b) Okay, let's take a look at Redis! What do you mean it doesn't properly support multiple databases per cluster!? It's single threaded too!? Wat!? Is this a database for children?

3) It takes minutes to start! I hope you never have an emergency update that needs to go out right now!. ASP.NET takes seconds at most. This is largely because it's precompiled and ships as a small number of large binary files instead of millions (literally!) of tiny files that are very slow on almost all server-grade storage. There's now ahead-of-time (AoT) compilation modes for ASP.NET that make it comparable to C++, Rust, or Go in startup performance!

4) I'm sure Node people have heard of certificates and HTTPS, but I'm fairly certain they think it's a fad and it'll just "go away" eventually.

5) NPM libraries are under constant churn. Just updating packages requires minutes of 100% computer power to resolve the dependency graph logic... which has changed. In a breaking way. Either way, it can be mathematically impossible to disentangle the mess before the heat death of the universe. I'm not kidding! It's possible to get into a situation where "error: timed out" doesn't quite do it justice.

6) In .NET land there's basically only two ORMs used: Entity Framework from Microsoft and Dapper from StackOverflow. They work fine. Someone at $dayjob picked "typeorm" for Node. Is it the best? Who knows! There's dozens to pick from! None of them work properly, of course. I do know that typeorm doesn't allow me to pick my own database driver. Why? Because they're too busy, according to the GitHub issue tickets. Entity Framework uses a pluggable interface with dozens of well-supported implementations. This is because the entire platform, all of its database support, and the ORM on top were written by one vendor in a coordinated way and is pluggable via interfaces in the standard library instead of a hodge-podge of random code thrown together by literal children. [2]

Etc, etc...

[1] Under-funded is the more generous reason.

[2] A very significant portion of NPM packages were written by people under the age of 18. This is either commendable or horrifying depending on your perspective. It's hard to prove though, because contributions are effectively anonymous.