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.

That's really an insightful answer I enjoyed reading. Really brings me back!

I dislike nodejs for the same reasons. But do get the feeling that rust and go, maybe even something more exotic like elixir would be good alternatives as well for your use case.

I have barely anything to compare to your requirements tho. I personally would get panic attacks and couldn't sleep anymore if my dependencies aren't open source and I would depend on a company for any reason. But that's just me, it definitely sounds very mature

> I personally would get panic attacks and couldn't sleep anymore if my dependencies aren't open source and I would depend on a company for any reason. But that's just me, it definitely sounds very mature

.NET is open source.

To my understanding the "batteries" as in "batteries included" from above aren't.

That includes also all the "batteries" (https://github.com/dotnet).

You clearly have not worked with in a competent JS-based project. Literally none of your objections are valid except for the single-threaded nature of JS.

Which is also not quite valid, given that .NET has async now, with all the same faults.

> 3) It takes minutes to start! I hope you never have an emergency update that needs to go out right now!

This clearly shows that:

1. "Just copy it" leads to messes that need sub-second deployments. Probably manual ones, because simply spinning up CI/CD and running the tests typically takes longer. Were you responsible for that CrowdStrike outage?

2. My JS project compilation takes 10 seconds from an empty directory to the compiled asset.

> 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.

We're using PNMP and our library resolution takes seconds.

> 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!

It's interesting that you think that not having choice of libraries is good.

I guess that's OK when your worldview has shrunk down to the confines of MSDN, and you can't see anything outside of it.

“Just deviate from the defaults and then you’ll have a good time!” is not a convincing argument for someone who’s used to being wildly productive… with the defaults.