I was an extreme skeptic on the use of Typescript over just regular Javascript. When my team decided to try an experimental project with it on AWS Lambdas, I saw some benefit in it when I imported the aws event interfaces. I thought, oh this could be really useful for asserting an API interface and getting all the intellisense for that in vscode so I don't have to look at docs as much.
Because of that thought, a year later my team moved an existing legacy project to GraphQL. On the FE we ran a script that used a codegen tool: graphql-code-generator.com/
This hits the introspection endpoint on graphql and genrates all the types for queries and mutation and fields. It will also generate an sdk for your FE GQL queries, which are typed of course.
This was the point of no return for me and I commited to TS 100%, at least in the work environment. It saved so much time and made it so much more enjoyable to work with the data layer in the FE.
Occasionally I still spin up some small projects at home using just a node script but when it grows to a certain level of complexity, I start missing TS and feel the urge to define some interfaces, so I'll end up switching over back to TS pretty quickly. In a team environment I wouldn't consider going any other way as it just saves so much time and grief and no one has to interpret the intention or parameters of functions, etc. We do have at least one team member that hates Typescript. Sometimes he complains about how a particular typing error is just wrong or unnecessary but when one of us looks at it, it almost always turns out that TS was trying to help him cover a case he hadn't thought of or that he had a wrong concept of what the data was. On the other hand, that developer is very good at running down production bugs so I guess there are different strengths and preferences out there and it depends on what type of programmer personality you have.
For myself, if it's a question of, do you want to move fast and fix bugs in prod vs, take a bit longer solidifying your data abstraction and have less bugs later, I'll go with that latter choice.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I was an extreme skeptic on the use of Typescript over just regular Javascript. When my team decided to try an experimental project with it on AWS Lambdas, I saw some benefit in it when I imported the aws event interfaces. I thought, oh this could be really useful for asserting an API interface and getting all the intellisense for that in vscode so I don't have to look at docs as much.
Because of that thought, a year later my team moved an existing legacy project to GraphQL. On the FE we ran a script that used a codegen tool: graphql-code-generator.com/
This hits the introspection endpoint on graphql and genrates all the types for queries and mutation and fields. It will also generate an sdk for your FE GQL queries, which are typed of course.
This was the point of no return for me and I commited to TS 100%, at least in the work environment. It saved so much time and made it so much more enjoyable to work with the data layer in the FE.
Occasionally I still spin up some small projects at home using just a node script but when it grows to a certain level of complexity, I start missing TS and feel the urge to define some interfaces, so I'll end up switching over back to TS pretty quickly. In a team environment I wouldn't consider going any other way as it just saves so much time and grief and no one has to interpret the intention or parameters of functions, etc. We do have at least one team member that hates Typescript. Sometimes he complains about how a particular typing error is just wrong or unnecessary but when one of us looks at it, it almost always turns out that TS was trying to help him cover a case he hadn't thought of or that he had a wrong concept of what the data was. On the other hand, that developer is very good at running down production bugs so I guess there are different strengths and preferences out there and it depends on what type of programmer personality you have.
For myself, if it's a question of, do you want to move fast and fix bugs in prod vs, take a bit longer solidifying your data abstraction and have less bugs later, I'll go with that latter choice.