4 ms·

> 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.

> 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.

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.