My two favourite (and unexpected) benefits of using Typescript

We’ve been happily using Typescript at Qualdesk (exclusively) for over a year and a half, and we’ve seen many benefits of it in our day-to-day. My vim is set up to maximise all the autosuggest opportunities and every now and then our CI errors when someone does a lazy hotfix without running it locally.

However, I’ve noticed two behaviour changes in our development team—things I haven’t seen mentioned in articles about static typing before. And for me they became the top benefits of using Typescript in our team.

Improving our conversations about solutions

As a team that depends heavily on code reviews in the form of Pull Requests, getting other people’s opinions about our solutions is second nature.

However, Pull Requests come pretty late in the process —at the time when most of the work is already done. While this doesn't stop anyone from giving their honest opinion, it can be difficult to trade off implementing feedback vs shipping the code that has already been written. Even when feedback points to an objectively better solution.

Feedback about a particular approach can be achieved earlier with a short document, a draft of a diagram or a gist with pseudo-code -these are all perfect ways to get feedback on potential solutions. The disadvantage to these is the additional time taken creating something that wouldn’t have to exist otherwise. And sometimes actual code is a better language to communicate your concept with.

With that in mind, Typescript interfaces allowed us to get this early sense check without leaving a text editor. We can start building by defining interfaces and data models —not unlike in Interface-based Programming —and use those to start the conversation about the approach. Other members of the team can more easily understand how the proposed solution will work, and can ask more targeted questions (how it interacts with the rest of the code, how it impacts our plans, etc.)

Recently one of my colleagues, Callum, used this method to ask for feedback on approach for "content bundles". This led to a conversation about specifics of the implementation, helped him clarify the idea in his head and prepare his approach for the changes that were happening in parallel. If he had to write up the solution as a document he would most probably jump straight into coding instead and wait for feedback on his Pull Request (which, I guarantee you, would conflict with the work that was happening in parallel).

Writing simpler code

In this case, rather than Typescript enabling something, this is about it stopping us from doing something bad.

Typescript makes it really difficult to write overly complex code.

No matter which direction you approach it — types first, implementation first or any other way of organising your work — if the code is complex, the types for it will be as well.

If during code review you start reading through types that are not immediately understandable, there is a high chance that the underlying implementation could be simpler.

Another thing about Typescript —it stops you from writing code that is prematurely abstracted or over-generalised. Generalised code in Typescript will either use generics or types for things that don’t exist in code yet. The former might be correct, but quite quickly gets more difficult to understand than the implementation itself. And writing types for things that haven't come up yet is not difficult— it's impossible. You very quickly conclude that you’re making things up, and you shouldn’t commit that to the repo… because you aren’t gonna need it.

These two benefits ensure I won’t be going back to vanilla JS anytime soon. They makes me consider what languages we might add to our tech stack in the future  – static typing will be high on the requirement list.

I’d love to hear what you think  – do you prefer the relaxed environment of dynamically typed languages or the benefits of static typing? Are there any other benefits you noticed from using Typescript? Tweet me at @lukaszsagol