Why I start every Node.js project with TypeScript today

Types as Life Insurance

The most important realization for any developer is the moment that reading code is more important than writing it. From that point on, code is written with increasing awareness, always to understand later what was developed, in what way and, more importantly, why. This doesn't necessarily have to be for others. The future me might look at the lines of code with frustration.

Of course, in my opinion, there are even more mundane reasons to use TypeScript. Besides clarifying the intention, it also reduces mental strain, as the code editor can provide helpful suggestions. And in the age of AI, it goes beyond mere autocomplete.

function getUser(id: number): User | null {
  // ...
}
// Depending on whether I allow the return value of null,
// I clarify how I intended the method to be used.

Architecture and Communication

In the previous section, I already touched on this aspect: a clear definition allows me to describe my intention and, by extension, the underlying modelling. This could, for example, be data modelling or interface definition. These are essential aspects of software architecture.

Furthermore, I communicate with my colleagues (or with my future self) through my types. It's a form of documentation, a relatively unpopular discipline, yet crucial for good software.

interface User {
  id: number;
  name: string;
  email?: string;
}
// It's clear what "User" is. The email address is not a required field.
// Here, one could discuss whether "email: string | null" would be better.
// The main thing is that the modeling is identical everywhere, given the same intention.

Increased Speed

Thanks to improved support from development environments, TypeScript accelerates refactoring and further development. If I had to choose, I would prefer test-driven development. However, I can usually have both and use them accordingly.

I am notably faster at reading TypeScript code. I typically spend 80% of my time doing this. This includes considering how to adapt or further develop the code. The percentage may vary depending on the project status (initially, a larger proportion is spent writing code) – eventually, it shifts in that direction.

Conclusion

I am convinced that my development quality is better with TypeScript than without it. I know some good arguments against TypeScript, but they don't apply to my workflow. The fast feedback in the form of readable code or IDE support outweighs these drawbacks for me. The additional level of complexity in the tool chain is acceptable. I will describe precisely how this complexity manifests itself for me later this month.