4 ms·

The biggest con is that you have to do all of the legwork of learning how static typing works, and types in TS can be fairly complex. When you have a team of e

The biggest con is that you have to do all of the legwork of learning how static typing works, and types in TS can be fairly complex. When you have a team of engineers, this means your entire team needs to either learn or lean on an expert when tougher situations arise.

akdor1154 2y ago
Less charitably, it means you need a competent team?
- shepherdjerred 2y ago
  Competent in types, yes. Just like you’d want a team competent in functional programming before starting a project in Haskell. It would be unfair to consider your team incompetent just because they are experts with another set of tools. It’s also unreasonable to expect these things to be quickly learned (TypeScript types are not friendly). But I think it’s reasonable to explain the benefits of this approach and to help your ramp up and learn the skill. But, anyway, I understand the frustration. I’m usually the one trying to get my team to understand the value of modeling problems in type systems.
tubthumper8 2y ago
If complex situations arise, they can slap `any` on it, at least it would be explicit, and marker to revisit in the future. Is there really that much legwork otherwise? Adding ": string" to a function parameter assumes they know what a string is (which should already be the case), adding an object type assumes knowing what an object is, etc.
- shepherdjerred 2y ago
  There is a big difference between typing your application (e.g. changing (arg) => {} to (arg: string): void => {}) and modeling your application in the type system. Simply adding types is usually not too difficult and it is still quite beneficial. It does eliminate certain kinds of bugs. Modeling your application in a type system means making invalid states unrepresentable and being as precise as possible. This is a lot more work, but again is eliminates more kinds of bugs that can occur. An example of this being complex: earlier this week I wrote a generic React component that allows users to define which columns of a table are sortable. I wanted to prevent any invalid configurations from being passed in. This is what it looks like: https://tinyurl.com/bdh6xbp6 https://tinyurl.com/bdh6xbp6 It's a bit complex but the compiler can guarantee that you're using the component correctly. This is more important and useful when it comes to business logic.
turbojet1321 2y ago
The thing is, you have to implicitly understand the "types" of javascript objects anyway, otherwise you can't use them. All the type system does is make that implicit knowledge explicit, and a long the way, stops you from doing things that are likely to cause issues.
- shepherdjerred 2y ago
  Yes, but properly typing your JS objects can still be quite hard
digging 2y ago
Yes, but, I'd argue it's trading one type of endless, tedious work for a different type of concrete, meaningful work.
- shepherdjerred 2y ago
  I agree! It’s still not an easy sell though.

akdor1154 2y ago

Less charitably, it means you need a competent team?

shepherdjerred 2y ago
Competent in types, yes. Just like you’d want a team competent in functional programming before starting a project in Haskell. It would be unfair to consider your team incompetent just because they are experts with another set of tools. It’s also unreasonable to expect these things to be quickly learned (TypeScript types are not friendly). But I think it’s reasonable to explain the benefits of this approach and to help your ramp up and learn the skill. But, anyway, I understand the frustration. I’m usually the one trying to get my team to understand the value of modeling problems in type systems.

tubthumper8 2y ago

If complex situations arise, they can slap `any` on it, at least it would be explicit, and marker to revisit in the future. Is there really that much legwork otherwise? Adding ": string" to a function parameter assumes they know what a string is (which should already be the case), adding an object type assumes knowing what an object is, etc.

shepherdjerred 2y ago
There is a big difference between typing your application (e.g. changing (arg) => {} to (arg: string): void => {}) and modeling your application in the type system. Simply adding types is usually not too difficult and it is still quite beneficial. It does eliminate certain kinds of bugs. Modeling your application in a type system means making invalid states unrepresentable and being as precise as possible. This is a lot more work, but again is eliminates more kinds of bugs that can occur. An example of this being complex: earlier this week I wrote a generic React component that allows users to define which columns of a table are sortable. I wanted to prevent any invalid configurations from being passed in. This is what it looks like: https://tinyurl.com/bdh6xbp6 https://tinyurl.com/bdh6xbp6 It's a bit complex but the compiler can guarantee that you're using the component correctly. This is more important and useful when it comes to business logic.

turbojet1321 2y ago

The thing is, you have to implicitly understand the "types" of javascript objects anyway, otherwise you can't use them. All the type system does is make that implicit knowledge explicit, and a long the way, stops you from doing things that are likely to cause issues.

shepherdjerred 2y ago
Yes, but properly typing your JS objects can still be quite hard

digging 2y ago

Yes, but, I'd argue it's trading one type of endless, tedious work for a different type of concrete, meaningful work.

shepherdjerred 2y ago
I agree! It’s still not an easy sell though.