Love TypeScript. tsc by itself is amazingly fast. Writing stuff in TypeScript has huge benefits, you can still publish your packages so they work in plain-old

Love TypeScript. tsc by itself is amazingly fast. Writing stuff in TypeScript has huge benefits, you can still publish your packages so they work in plain-old ES. Interfaces that define structure of objects go a long way to reign in a codebase of unknowns. Also, various benefits when editing: Type-based checks via tsc and linter, autocompletion (life saver). These things add up quickly in a big codebase. That's not to speak of utility functions: https://www.typescriptlang.org/docs/handbook/utility-types.html https://www.typescriptlang.org/docs/handbook/utility-types.h... I will nitpick one area: generics. While I use them a lot in practice, I seldom write new ones. Example: In DefinitelyTyped's definitions for @types/react, it makes sense to have a generic in React components. This lets the user pass-in their own interface for their props, e.g. const MyComponent: React.FC<{ isFirst: boolean }> = ({isFirst, children}) => ( <div className={`${isFirst ? 'first' : 'after' }`}>{children}</div> ) Declarations for React's FC (points to `FunctionComponent`): https://github.com/DefinitelyTyped/DefinitelyTyped/blob/9d56fee/types/react/index.d.ts#L539 https://github.com/DefinitelyTyped/DefinitelyTyped/blob/9d56... In the case of a widely used library, generics make sense at scale. It's reused and components revolve around the shape of props. Not to mention, DefinitelyTyped's superb community, continuous integration and maintainers around the globe. Microsoft keeps pushing open source forward in so many ways. Anyway - Outside of that, I've come to eschew writing new generics internally. The reason why is complexity not being worth the trade offs. I'd rather use generics already available (see utility types above). Less cognitive overhead.