IDK, TypeScript types are extremely ergonomic, and if you're not overzealous makes everything very readable, and given many things are I/O bound anyway, it doesn't matter much.
So now you need to add in Zod or Valibot as well to validate your types. If you have view models and DTOs, then you add more Zod. Might as well use a statically typed language?
Working with OpenAPI is much easier when you already have a static type system.
How about database transactions? Ran into an interesting issue this week. In a .NET world, every ORM can participate in an ambient transaction because everyone uses System.Transactions. Not the case in Node because there's no such thing.
Would not build backends in TS except for true microservices. The ergonomics of a Nest.js vs .NET Web API are night and day.
I mean you could say the same thing about TypeScript - if your entire stack is TypeScript then there's no need for the type validation either.
You can't just accept any JSON payload and expect it to be valid.
In Java or .NET, it will fail at serialization when the runtime tries to map it to a static type (automatic). This is not the case at runtime with JS (because at runtime, it's no longer TS). Thus you need a Zod or a Valibot to ensure the incoming payload is actually valid by describing the valid types (even if your whole stack is TS at dev time because schema mismatches are a runtime problem).
.NETs System.Text.Json does the mapping and validation using either reflection or AOT generated serializers transparently and automatically because it has static types.
For TypeScript with only types and without validation, a bad payload gets through, and there is no telling where in the workflow it will explode. This could waste more time and developer resources in debugging.
IMO, a lot of the JS world seems mentally fixated on express.js-levels of abstraction still. Anything more is viewed as "magic" and viewed as suspect because it requires learning.
var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();
app.MapGet("/{userId}", (int userId) => userId);
app.Run();
I've put it into a short clip for you: https://imgur.com/a/WNbGUQD
The fact that it’s built in is neat but not really important. Most people are not making thousands of toy apps. If the necessary they will integrate and move on.
There are more compelling reasons to use .net than this.
Of course if you’re writing a full stack app you can share everything, validating the front and backend with the same code. Clearly that would be a strange thing to hold against .net, similar to the lack of built in validation in typescript.
if you're using typescript in the front end, seems double to even bother to introduce .net, when typescript and node is fine for the backend too.
> [amazingamazing 31 minutes ago] I mean you could say the same thing about TypeScript - if your entire stack is TypeScript then there's no need for the type validation either.
also, with curl you'd use isomorphic type safety, or just know what you're expecting and hard code the types per inputs, trivial with typescript.
anyway, I'm done here since this conversation is going in circles.