TypeScript is Like C# – A Backend Guide
11 comments
·March 22, 2025SebastianKra
neonsunset
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#.
koakuma-chan
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).
CharlieDigital
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).
koakuma-chan
> because the front-end models are typically a subset of the back-end models
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).
CharlieDigital
> (Setting up OpenAPI)...is way too arduous
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...
deskamess
Is it available as a backend language in an ASP .NET Core app? It would be nice if there was a VS project template that was Typescript end-to-end.
koakuma-chan
Not sure, I meant only using Typescript; no C# at all.
neonsunset
Using TypeScript in back-end is a downgrade.
null
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.