This is probably written by someone who works with C# much more than with Typescript.
There's nothing here about narrowing, (proper) type inference, union and intersection types etc...
When I tried C#, coming from Typescript, I was frequently hitting limitations that made sense from a historical perspective, but were killing elegant solutions.
For example, C# has null-safety, but it's different for Value-Types than for Reference-Types. So you can't have a generic function over Optional<T>.
Tbf, I was using Unity, which adds its own layer of insanity. And, as with any language, you eventually learn to work around the limitations. But presenting both languages as interchangeable is naive.
Unity is stuck with an ancient version of the language and uses its own custom runtime which lacks access to most of the wider ecosysteTS has _too much_ “useless” type complexity which has no impact on code execution which is polar opposite to C#.
Everyone should use TypeScript on the backend because it allows to share types with the front end extremely easily, and things like Astro actions (or equivalent, depends on your framework) give you an easy RPC (no need to deal with GraphQL or whatever).
It's pretty easy to generate TypeScript bindings on the fly with .NET and OpenAPI and then generate TS client bindings[0].
I don't think simply having the same types is a great reason to use TS on the backend given that many teams end up generating OpenAPI bindings in any case because the front-end models are typically a subset of the backend models (it is probably an anti-pattern to share your Prisma models with your FE).
It's actually quite minimal in .NET 9 :) Just a few lines of config and then pick your preferred Node tool of choice for generating the types from the spec. It's a 1 time setup and you get very clean separation at the boundary.
Even with Node frameworks like Nest.js, it is quite simple[0].
Beyond front-end use cases, the OpenAPI spec is pretty much required anyways if you are building a real API since tools like Redocly and other API documentation tools use the OpenAPI spec to generate your docs. Infrastructure like AWS API Gateway also consumes OpenAPI[1]; it seems to me quite handy to use the OpenAPI schema then as the source for client-side DTOs.
There's nothing here about narrowing, (proper) type inference, union and intersection types etc...
When I tried C#, coming from Typescript, I was frequently hitting limitations that made sense from a historical perspective, but were killing elegant solutions.
For example, C# has null-safety, but it's different for Value-Types than for Reference-Types. So you can't have a generic function over Optional<T>.
Tbf, I was using Unity, which adds its own layer of insanity. And, as with any language, you eventually learn to work around the limitations. But presenting both languages as interchangeable is naive.
I don't think simply having the same types is a great reason to use TS on the backend given that many teams end up generating OpenAPI bindings in any case because the front-end models are typically a subset of the backend models (it is probably an anti-pattern to share your Prisma models with your FE).
[0] https://github.com/CharlieDigital/dn9-openapi-codegen
That’s true, and Pick<BackendModel, …> works extremely well for me.
Setting up GraphQL or OpenAPI or any other code generation is way too arduous compared to just using TypeScript (also allows sharing logic).
Even with Node frameworks like Nest.js, it is quite simple[0].
Beyond front-end use cases, the OpenAPI spec is pretty much required anyways if you are building a real API since tools like Redocly and other API documentation tools use the OpenAPI spec to generate your docs. Infrastructure like AWS API Gateway also consumes OpenAPI[1]; it seems to me quite handy to use the OpenAPI schema then as the source for client-side DTOs.
[0] https://docs.nestjs.com/openapi/introduction
[1] https://docs.aws.amazon.com/apigateway/latest/developerguide...