3 ms·

I think I'd need to see some studies on those "benefits" to believe them- I do really like intellisense working with typescript sometimes saving me a click or t

by naet 3y ago

I think I'd need to see some studies on those "benefits" to believe them- I do really like intellisense working with typescript sometimes saving me a click or two on viewing another file (when I can just over over something and see a little description of the types)... but I've also lost a ton of time trying to fight with a complex type when I know what I want to accomplish and could have done it more trivially with vanilla JS. You might catch more bugs because you spend more time on writing the code, and the ratio might be positive or negative compared to just spending that time in dynamic types. You can slap an "any" here and there for that but it's not always obvious where to or if that will cause problems down the line, and some purists will say you should never use any.

shepherdjerred 3y ago
> I've also lost a ton of time trying to fight with a complex type when I know what I want to accomplish and could have done it more trivially with vanilla JS. Type systems are an investment to learn. The good news is that the knowledge is transferable. Statically typed languages borrow a lot from each other. For TypeScript, I would highly recommend Type-Level TypeScript [0] which teaches programming in the TypeScript type system. After going through that, I was able to understand more advanced types and a lot of the magic is peeled away. I can read types from libraries and understand what is going on, and, when needed, I can write sufficiently flexible types for our application that gives my applications a _lot_ of safety. --- As an aside, using `any` gives you the worst of both worlds: you have to fight with a type system, and the type system isn't even doing anything. For TypeScript, Zod [1] (or any other validation library) fixes often can help with a lot of casts, e.g. when parsing API responses or other data coming from outside of your type system. [0]: https://type-level-typescript.com/ https://type-level-typescript.com/ [1]: https://zod.dev/ https://zod.dev/
- IshKebab 3y ago
  > As an aside, using `any` gives you the worst of both worlds: you have to fight with a type system, and the type system isn't even doing anything Not sure I agree there. You can use `any` judiciously so that don't have to fight the type system where it's too difficult, and yet still get the benefits elsewhere in your program. I think it's actually one of the biggest benefits of dynamic typing - in rare cases you can use `any`. Most static type systems don't really let you do that. (I think Dart is one of the rare exceptions because it started dynamically typed and switched to statically typed.)
  - shepherdjerred 3y ago
    If you're using `any` just because the type is complex, then using it sparingly isn't a huge deal, so long as you are confident that the type is correct. The problem is using `any` when you _don't_ actually know the type of something, e.g. ``` const data = JSON.parse(localStorage.get("my_data")) as any as UserSettings; ``` In the above case you're just hoping that what's in local storage matches your type, and it makes your type system less effective.

by naet 3y ago

shepherdjerred 3y ago

> I've also lost a ton of time trying to fight with a complex type when I know what I want to accomplish and could have done it more trivially with vanilla JS. Type systems are an investment to learn. The good news is that the knowledge is transferable. Statically typed languages borrow a lot from each other. For TypeScript, I would highly recommend Type-Level TypeScript [0] which teaches programming in the TypeScript type system. After going through that, I was able to understand more advanced types and a lot of the magic is peeled away. I can read types from libraries and understand what is going on, and, when needed, I can write sufficiently flexible types for our application that gives my applications a _lot_ of safety. --- As an aside, using `any` gives you the worst of both worlds: you have to fight with a type system, and the type system isn't even doing anything. For TypeScript, Zod [1] (or any other validation library) fixes often can help with a lot of casts, e.g. when parsing API responses or other data coming from outside of your type system. [0]: https://type-level-typescript.com/ https://type-level-typescript.com/ [1]: https://zod.dev/ https://zod.dev/

IshKebab 3y ago
> As an aside, using `any` gives you the worst of both worlds: you have to fight with a type system, and the type system isn't even doing anything Not sure I agree there. You can use `any` judiciously so that don't have to fight the type system where it's too difficult, and yet still get the benefits elsewhere in your program. I think it's actually one of the biggest benefits of dynamic typing - in rare cases you can use `any`. Most static type systems don't really let you do that. (I think Dart is one of the rare exceptions because it started dynamically typed and switched to statically typed.)
- shepherdjerred 3y ago
  If you're using `any` just because the type is complex, then using it sparingly isn't a huge deal, so long as you are confident that the type is correct. The problem is using `any` when you _don't_ actually know the type of something, e.g. ``` const data = JSON.parse(localStorage.get("my_data")) as any as UserSettings; ``` In the above case you're just hoping that what's in local storage matches your type, and it makes your type system less effective.