[wbobeirne]

I assume the startup wasn't also leveraging typescript heavily on the frontend, that tends to shift the weight in its favor. Having one set of tools to use across everything, being able to share logic and types without needing to go through lossy translation layers, and giving (especially small) teams better flexibility to move people around is a huge benefit.

[CharlieDigital]

We are using TS on the FE with React.

But the reality is that at some point, your FE and BE teams will diverge anyways and we use an OpenAPI spec as the contract (Nest.js, not Next.js).

So there was no benefit to using TS on both ends; only pain on the BE.

If a team is going to ship an OpenAPI spec and run it through a transformer, then it changes the selection criteria for a BE language:

    - Easy for a TS team to adopt; similar core semantics like `async/await`, exception handling, etc.
    - Flexible and pluggable OpenAPI spec generation for edge cases and advanced scenarios
    - Excellent ORM to improve productivity around CRUD
    - Good tooling
    - Extensive docs, platform maturity, but modern language features

C# meets all of those in ways that no other language and platform does.

[wbobeirne]

I can't speak to your use case, but for past projects I've not only wanted to share types but actual logic. For instance, if you want instantaneous validation on the frontend, while applying the same logic on the backend with submitted data. In many instances that would be simple and maybe even serializable, but in my case I was working with architectural data that had extremely detailed logic for what was and was not valid.