Cons #4 : Development overhead and syntax complexity

Scaling and building complex types needs work.

Is it useful for small projects ?

I mean, it depends, if you’re not “fluent” with TypeScript tooling and setup, using it for a really small project will may not be worth it.

But, in the era of Webpack and “zero-config” building tools — think about Parcel and Create React App — setting up TypeScript is not that big a deal, and even small projects could benefit from it. Let’s admit though that overhead exists on big ones. ⤵️

Scaling types need practice

By scaling types, I mean being able to reuse types.

We might easily think that it comes naturally with code factoring, but it doesn’t :

types are about data, not function signatures.

That’s why factorising types is hard : types are tied to your data.

One good inspiration is GraphQL Fragment that represents “sub-GraphQL Type” or common fields on a GraphQL Type.

For example, one can break down a User type into several smaller types:

User = BasicUserFragment | PlatformUserFragment | SpaceUserFragment

This avoids having many User types around the application describing the same data in different ways.

Complex types are still difficult to define