5 ms·

Moving off of TypeScript, 2.5M lines of code

88 points by caliChander 1y ago

dustingetz 1y ago
they seem to mean on the backend
- CharlieDigital 1y ago
  Motion eng here: yes, this is a pure backend change; FE remains powered by React and TS with no plans to change it any time soon. Main pain points with TS have become more obvious as the team grew and the codebase resulted in a multitude of different models representing the same thing. - Prisma model representing the things (plural because Prisma generates a ton of variants for the different read/write scenarios) going in/out of the DB - Zod models for OpenAPI generation - Zod models for deserialization where we have `jsonb` - DTO models at the boundary - Additional front-end payload models that wrap the DTOs A developer building a simple API endpoint do to a read will often up writing a handful of models for the same entity to move it back and forth...A lot of this work simply ends up being related to the loss of runtime types requiring a lot more modeling work creating a spaghetti of Zod and types. Lots of papercuts in day-to-day and increasingly difficult to get otherwise competent engineers onboarded. At least I'm not under the impression that this is a Silver Bullet. Will C# make it better? We'll see!
  - Merad 1y ago
    For basic CRUD like is emphasized in TFA you probably only need EF models to represent the db and DTOs to form the input/output contracts of the API. Many .Net shops (claim to) do DDD and will have an extra layer of domain models, but if you understand that your API is primarily CRUD they're just unnecessary complexity. While you won't be able to share your back end models with the front end, OpenApi spec generation is pretty much automatic so you can generate the models or client code.
    - CharlieDigital 1y ago
      Yes; I think that's one thing that made this transition more sensible: we are not really sharing much of the BE with the FE and most of it is at the boundary already anyways.
  - junto 1y ago
    I don’t know if you’re using this already but there are quite a few tools to autogenerate the typescript api clients from your backend code every time you build. Makes life super easy. You can also just do it in your CI/CD.
  - sajadjalilian 1y ago
    After thinking for a year about my frontend choose; I decided to go with Razor-Pages + HTMX for all my new projects from now on.
    - kant2002 1y ago
      What do you use for HTMX in Razor? any library or some manual plumpbinng? How do you disable layout?
fabian-hiller 1y ago
Great article!
dafzal 1y ago
With code becoming increasingly LLM generated, static typing improves evaluation of code compile time. So A+ for _type safe_ AI generated PRs :).
rvz 1y ago
TypeScript is generally a horrific language to use on the backend and especially for performance and even as a compiler. Just ask the TypeScript developers rewritting the TS compiler in Golang with all the problems they encountered using it. C# is a much better choice to use for the backend and also a better designed language in general.
- CharlieDigital 1y ago
  They are close enough IMO that most devs can probably competently move between the two. I think the big gains come from a more mature ecosystem of things that "just work". e.g. EFC vs Prisma or Drizzle with EFC having, for example, automatic change tracking and automatic up/down migrations. The two NPM supply chain attacks this week also highlight another issue with the ecosystem in general. We'll see how this change goes and evolves in Motion; C# is still relatively rare for startups, but at series C, it's no longer a seed stage startup and it increasingly feels like "it's just another distributed enterprise backend" (or at least it should be).
pedroigor91 1y ago
I still don’t understand why more startups don’t adopt .NET. It’s such a powerful technology. ASP.NET has some of the best performance benchmarks out there, C# is a rich and expressive language, and the ecosystem along with the standard libraries are stable and mature. You rarely run into the kind of headaches you often see with more “trendy” stacks. In many cases, the bias comes down to perception — .NET is seen as “enterprise” or “legacy,” while in reality it’s open-source, cross-platform, and very well-supported by Microsoft and the community. For a startup that needs stability and performance without reinventing the wheel, .NET can be a huge win.
- bigonlogn 1y ago
  Also, you can achieve some pretty fast development velocity with .NET. C# is intuitive and the tools are great. I know everyone complains about Visual Studio, but even it's most vocal complainers will admit it sets the industry standard for debugging. One sticking point is that the tools, while community and small projects, are all behind a license. But, they are free for small teams making under something like $1M/year in revenue.
  - aeonax 1y ago
    If Visual Studio isn't to your liking then you can look at Rider or Visual Studio Code. Rider should make anyone who is used to JetBrains' other products fairly happy.
- pier25 1y ago
  I transitioned from Node to dotnet for backend last year and it's been great for APIs. Love C#. Performance is fantastic. The framework and tooling are very mature (with exceptions like hot reload ugh). Entity Framework is amazing, by far the best ORM I've ever used. I don't feel like an expert by any means but I'm productive. Some days I do hit some stuff that takes me longer that I would've hoped but I've been able to solve everything I've faced. I only use it for APIs though. The fullstack stuff is not great. Maybe if Microsoft improved hot-reload I would consider Razor with a Vite setup. Blazor is just useless for me. It's very cool from a technical standpoint but your frontend is 10x slower and more bloated than the worst JS solution you can think of. I connect my JS frontend layer with OpenAPI[1]. It's been ok but the whole OpenAPI experience is not as smooth as I had hoped. [1] https://openapi-ts.dev/ https://openapi-ts.dev/
vbilopav 1y ago
It looks to me team is clueless about database development. Typescript ORMz lol. Soft deletes make indexing, well, problmatic to say at least. Use temporal tabls instead for point in time recovery. Nevertheless it could have been solved on a database level without any help from ORMs, lookup RLS. Still, screws up indexing strategy.
zengid 1y ago
> In the end, I decided on C Sharp, even though I had never used it professionally I love C#, I use it every day, but who makes a decision like this?
brungarc 1y ago
.NET and C# are a great choice for web backend and CRUD apps.

88 points by caliChander 1y ago

dustingetz 1y ago

they seem to mean on the backend

CharlieDigital 1y ago
Motion eng here: yes, this is a pure backend change; FE remains powered by React and TS with no plans to change it any time soon. Main pain points with TS have become more obvious as the team grew and the codebase resulted in a multitude of different models representing the same thing. - Prisma model representing the things (plural because Prisma generates a ton of variants for the different read/write scenarios) going in/out of the DB - Zod models for OpenAPI generation - Zod models for deserialization where we have `jsonb` - DTO models at the boundary - Additional front-end payload models that wrap the DTOs A developer building a simple API endpoint do to a read will often up writing a handful of models for the same entity to move it back and forth...A lot of this work simply ends up being related to the loss of runtime types requiring a lot more modeling work creating a spaghetti of Zod and types. Lots of papercuts in day-to-day and increasingly difficult to get otherwise competent engineers onboarded. At least I'm not under the impression that this is a Silver Bullet. Will C# make it better? We'll see!
- Merad 1y ago
  For basic CRUD like is emphasized in TFA you probably only need EF models to represent the db and DTOs to form the input/output contracts of the API. Many .Net shops (claim to) do DDD and will have an extra layer of domain models, but if you understand that your API is primarily CRUD they're just unnecessary complexity. While you won't be able to share your back end models with the front end, OpenApi spec generation is pretty much automatic so you can generate the models or client code.
  - CharlieDigital 1y ago
    Yes; I think that's one thing that made this transition more sensible: we are not really sharing much of the BE with the FE and most of it is at the boundary already anyways.
- junto 1y ago
  I don’t know if you’re using this already but there are quite a few tools to autogenerate the typescript api clients from your backend code every time you build. Makes life super easy. You can also just do it in your CI/CD.
- sajadjalilian 1y ago
  After thinking for a year about my frontend choose; I decided to go with Razor-Pages + HTMX for all my new projects from now on.
  - kant2002 1y ago
    What do you use for HTMX in Razor? any library or some manual plumpbinng? How do you disable layout?

fabian-hiller 1y ago

Great article!

dafzal 1y ago

With code becoming increasingly LLM generated, static typing improves evaluation of code compile time. So A+ for _type safe_ AI generated PRs :).

rvz 1y ago

TypeScript is generally a horrific language to use on the backend and especially for performance and even as a compiler. Just ask the TypeScript developers rewritting the TS compiler in Golang with all the problems they encountered using it. C# is a much better choice to use for the backend and also a better designed language in general.

CharlieDigital 1y ago
They are close enough IMO that most devs can probably competently move between the two. I think the big gains come from a more mature ecosystem of things that "just work". e.g. EFC vs Prisma or Drizzle with EFC having, for example, automatic change tracking and automatic up/down migrations. The two NPM supply chain attacks this week also highlight another issue with the ecosystem in general. We'll see how this change goes and evolves in Motion; C# is still relatively rare for startups, but at series C, it's no longer a seed stage startup and it increasingly feels like "it's just another distributed enterprise backend" (or at least it should be).

pedroigor91 1y ago

I still don’t understand why more startups don’t adopt .NET. It’s such a powerful technology. ASP.NET has some of the best performance benchmarks out there, C# is a rich and expressive language, and the ecosystem along with the standard libraries are stable and mature. You rarely run into the kind of headaches you often see with more “trendy” stacks. In many cases, the bias comes down to perception — .NET is seen as “enterprise” or “legacy,” while in reality it’s open-source, cross-platform, and very well-supported by Microsoft and the community. For a startup that needs stability and performance without reinventing the wheel, .NET can be a huge win.

bigonlogn 1y ago
Also, you can achieve some pretty fast development velocity with .NET. C# is intuitive and the tools are great. I know everyone complains about Visual Studio, but even it's most vocal complainers will admit it sets the industry standard for debugging. One sticking point is that the tools, while community and small projects, are all behind a license. But, they are free for small teams making under something like $1M/year in revenue.
- aeonax 1y ago
  If Visual Studio isn't to your liking then you can look at Rider or Visual Studio Code. Rider should make anyone who is used to JetBrains' other products fairly happy.
pier25 1y ago
I transitioned from Node to dotnet for backend last year and it's been great for APIs. Love C#. Performance is fantastic. The framework and tooling are very mature (with exceptions like hot reload ugh). Entity Framework is amazing, by far the best ORM I've ever used. I don't feel like an expert by any means but I'm productive. Some days I do hit some stuff that takes me longer that I would've hoped but I've been able to solve everything I've faced. I only use it for APIs though. The fullstack stuff is not great. Maybe if Microsoft improved hot-reload I would consider Razor with a Vite setup. Blazor is just useless for me. It's very cool from a technical standpoint but your frontend is 10x slower and more bloated than the worst JS solution you can think of. I connect my JS frontend layer with OpenAPI[1]. It's been ok but the whole OpenAPI experience is not as smooth as I had hoped. [1] https://openapi-ts.dev/ https://openapi-ts.dev/

vbilopav 1y ago

It looks to me team is clueless about database development. Typescript ORMz lol. Soft deletes make indexing, well, problmatic to say at least. Use temporal tabls instead for point in time recovery. Nevertheless it could have been solved on a database level without any help from ORMs, lookup RLS. Still, screws up indexing strategy.

zengid 1y ago

> In the end, I decided on C Sharp, even though I had never used it professionally I love C#, I use it every day, but who makes a decision like this?

brungarc 1y ago

.NET and C# are a great choice for web backend and CRUD apps.