Node.js is a runtime, not a language. It is quite capable, but as per usual, it depends on what you need/have/know, ASP.NET Core is a very good choice too.
In my experience ASP.NET 9 is vastly more productive and capable than Node.js. It has a nicer developer experience, it is faster to compile, faster to deploy, faster to start, serves responses faster, it has more "batteries included", etc, etc...
It has terrible half-completed versions of everything, all of which are subtly incompatible with everything else.
I regularly see popular packages that are developed by essentially one person, or a tiny volunteer team that has priorities other than things working.
Something else I noticed is that NPM packages have little to no "foresight" or planning ahead... because they're simply an itch that someone needed to scratch. There's no cohesive vision or corporate plan as a driving force, so you get a random mish-mash of support, compatibility, lifecycle, support, etc...
That's fun, I suppose, if you enjoy a combinatorial explosion of choice and tinkering with compatibility shims all day instead of delivering boring stuff like "business value".
I used to agree but when you have libraries like Mediatr, mass transit and moq going/looking to go paid I’m not confident that the wider ecosystem is in a much better spot.
It's still single-threaded, it still uses millions of tiny files (making startup very slow), it still has wildly inconsistent basic management because it doesn't have "batteries included", etc...
This is the first I'm hearing of this, and a quick Google search found me a bunch of conflicting "methods" just within the NestJS ecosystem, and no clear indication of which one actually works.
nest build --webpack
nest build --builder=webpack
... and of course I get errors with both of those that I don't get with a plain "nest build". (The error also helpfully specifies only the directory in the source, not the filename! Wtf?)
Is this because NestJS is a "squishy scripting system" designed for hobbyists that edit API controller scripts live on the production server, and this is the first time that it has been actually built, or... is it because webpack has some obscure compatibility issue with a package?
... or is it because I have the "wrong" hieroglyphics in some Typescript config file?
Who knows!
> There's this thing called worker_threads.
Which are not even remotely the same as the .NET runtime and ASP.NET, which have a symmetric threading model where requests are handled on a thread pool by default. Node.js allows "special" computations to be offloaded to workers, but not HTTP requests. These worker threads can only communicate with the main thread through byte buffers!
In .NET land I can simply use a concurrent dictionary or any similar shared data structure... and it just works. Heck, I can process a single IEnumerable, list, or array using parallel workers trivially.
If you read my comment I said there are downsides:
"But yes there are downsides. But the biggest ones you brought up are not true."
My point is.. what you said is NOT true. And even after you're reply, it's still not true. You brought up some downsides in your subsequent reply... but again, your initial reply wasn't true.
That's all. I acknowledge the downsides, but my point remains the same.
No. Because C#, while far from perfect, is still a drastically better language than JS (or even TS), and .NET stdlib comes with a lot of batteries included. Also because the JS package ecosystem is, to put it bluntly, insane; everything breaks all the time. The probability of successfully running a random Node.js project that hasn't been maintained for a few years is rather low.
Node.js is a runtime, not a language. It is quite capable, but as per usual, it depends on what you need/have/know, ASP.NET Core is a very good choice too.
> ASP.NET Core is a very good choice too.
I have found this to not be true.
Recently?
In my experience ASP.NET 9 is vastly more productive and capable than Node.js. It has a nicer developer experience, it is faster to compile, faster to deploy, faster to start, serves responses faster, it has more "batteries included", etc, etc...
What's the downside?
Compile speed and a subjective DX opinion are very debatable.
The breadth of npm packages is a good reason to use node. It has basically everything.
It has terrible half-completed versions of everything, all of which are subtly incompatible with everything else.
I regularly see popular packages that are developed by essentially one person, or a tiny volunteer team that has priorities other than things working.
Something else I noticed is that NPM packages have little to no "foresight" or planning ahead... because they're simply an itch that someone needed to scratch. There's no cohesive vision or corporate plan as a driving force, so you get a random mish-mash of support, compatibility, lifecycle, support, etc...
That's fun, I suppose, if you enjoy a combinatorial explosion of choice and tinkering with compatibility shims all day instead of delivering boring stuff like "business value".
If your willing to stick to pure MS libraries…
I used to agree but when you have libraries like Mediatr, mass transit and moq going/looking to go paid I’m not confident that the wider ecosystem is in a much better spot.
In my experience, no.
It's still single-threaded, it still uses millions of tiny files (making startup very slow), it still has wildly inconsistent basic management because it doesn't have "batteries included", etc...
You can bundle it all into one file and it's not single threaded anymore. There's this thing called worker_threads.
But yes there are downsides. But the biggest ones you brought up are not true.
> You can bundle it all into one file
This is the first I'm hearing of this, and a quick Google search found me a bunch of conflicting "methods" just within the NestJS ecosystem, and no clear indication of which one actually works.
... and of course I get errors with both of those that I don't get with a plain "nest build". (The error also helpfully specifies only the directory in the source, not the filename! Wtf?)Is this because NestJS is a "squishy scripting system" designed for hobbyists that edit API controller scripts live on the production server, and this is the first time that it has been actually built, or... is it because webpack has some obscure compatibility issue with a package?
... or is it because I have the "wrong" hieroglyphics in some Typescript config file?
Who knows!
> There's this thing called worker_threads.
Which are not even remotely the same as the .NET runtime and ASP.NET, which have a symmetric threading model where requests are handled on a thread pool by default. Node.js allows "special" computations to be offloaded to workers, but not HTTP requests. These worker threads can only communicate with the main thread through byte buffers!
In .NET land I can simply use a concurrent dictionary or any similar shared data structure... and it just works. Heck, I can process a single IEnumerable, list, or array using parallel workers trivially.
If you read my comment I said there are downsides:
"But yes there are downsides. But the biggest ones you brought up are not true."
My point is.. what you said is NOT true. And even after you're reply, it's still not true. You brought up some downsides in your subsequent reply... but again, your initial reply wasn't true.
That's all. I acknowledge the downsides, but my point remains the same.
No. Because C#, while far from perfect, is still a drastically better language than JS (or even TS), and .NET stdlib comes with a lot of batteries included. Also because the JS package ecosystem is, to put it bluntly, insane; everything breaks all the time. The probability of successfully running a random Node.js project that hasn't been maintained for a few years is rather low.