Pros and Cons of Typescript

2019-01-08

Typescript saw a massive explosion in recent years. I remember seeing it first when angular 4 came out, that was a big surprise and after trying it for a bit I wasn’t hooked or particularly happy. But recently I’ve started using it more and more. Somewhat because it eliminates a whole lot of bugs and somewhat because it’s so easy to just drop it into existing javascript codebase.

I am a big fan of functional programming and typescript support for that, let’s say, is not optimal. And you might see a lot of battering of typescript and praising other more functional languages like reason or elm. So, why did it succeed? Because similar to how c and c++ developers felt in love with golang, typescript achieved the same for javascript.

Your experience might vary about the pros and cons I’ve noticed and some of issues are sort of solvable but not in the most ergonomic way.

Pros

Probably the easiest one to integrate

In the modern javascript world, you will be using some sort of build system. Or something to support older browsers like babel. Swapping babel or webpack loaders to use typescript takes from 15min to half a day. Depending on your setup. And after that, you don’t even have to use typescript straight away. You can introduce it gradually.

You will find bugs and dead code

I could bet on that. If you have a decent size codebase and even if it has tests you will find unused parameters, parameter mismatches and just dead code after adding typescript, probably once a week. Maybe even once a day. So get ready for thinking “how did this even work?.

Fewer tests are needed.

Well, this is an obvious one. It doesn’t eliminate test altogether, but the amount is definitely smaller than javascript. Every now and then when I write a test for javascript it just feels like it should be a job of compiler to check the condition. You still need to assign your types properly.

if it compiles = it works (sort of).

undefined is not a function or similar error is a curse in javascript. You either write unit tests, check that dynamically or just yolo with it. So moving to compiled language gives somehow more deterministic results.

Most of the libraries have types.

Where other compile to javascript languages close themself in silos and create some sort of mechanisms to use javascript, typescript does it less. If you just want to use the library without any type safety it’s as straightforward as adding a single line to say that. But the beauty is in the fact that it’s possible to attach types to libraries without modifying the library itself. Because of that definitely typed exists. Which is a massive collection of types for common libraries. Even jquery is there.

Also because of the adoption quite a few libraries while not written in typescript, ship with typescript definitions on the side. And if you create your own you always can contribute back.

Autocomplete

If you ever worked with the typed language it’s not a novelty. But working with any sort of dynamic language means that autocomplete is not the best thing in the world. The best part of the typescript system is that you will get autocompletion even if you using javascript and you are consuming library written in javascript, as long as it has the type definitions. You need to have editor support, some editors come with inbuilt on some require running and extra typescript server. But all and all it’s there if you need.

Flexible type system, some smart things possible.

KISS is a common thing you hear as a software developer. And, yeah, it’s a good thing to have. But sometimes it’s nice when the tooling is “smart”. In the world of ducktape and bail wire which javascript regular type systems are not flexible enough to allow reuse of the code. Where is with typescript you can use types like dictionaries, use conditionals in types and it will merge type definitions for you. What makes it easier to put into an existing system.

Cons

Type definitions can clash.

Previously mentioned points about type merging can also be an obstacle. Some libraries will include different type definitions as dependencies, which will clash. Got plenty of those while trying working with node js and react-native.

Local linking can be a pain.

Similar to that local linking will mean that you might need to manually remove a folder from node_modules to make it work or some other shenanigans.

This might not always be a case, but I’ve experienced it a few times and it was a bit of a blocker, so worth pointing out.

null | undefined | ‘’.

Where in javascript these things are all falsy and you won’t think that much about where you use them. With typescript, you will have to be more strict about what you want to have as a value. If working on a team you might need to establish some sort of convention about that.

Not good for functional programming (missing variadic arg definition)

Because of the flexibility typescript type system provides it’s not the best suited for functional programming. While you can achieve functional-style code, you might need to jump through a few hoops or do some hacks here and there. Or just sacrifice the type safety. One of the things for example to get a generic enough pipe and compose functions you’d need variadic type arguments, you could get a workaround with very smart types, but it’s just a hack at that point.

Sometimes enforces public/private or other concepts

With typescript, you can pick and choose how strict the rules of anything are. I have had a set of rules there it was enforcing usage of public, private and so on. There are some proposals of that in ECMAScript drafts, but in general, these concepts don’t exist in javascript. Similar to namespaces. While some of them can be a beneficial to the codebase, they can also alienate the code for other developers.

Every now and then decides on stupid things ¯_(ツ)_/¯

Sometimes compiler decides that you have an error in your code. Even though it’s completely valid. It might just pick a wrong type definition and that’s it. You can’t really argue with it. So you might need to do some things to get around it. Which of course can get annoying, when rather than bashing out your code, you have to bash your way through typescript.

It’s a little bit behind

At some point typescript team implemented decorators, but the spec has changed for es6 meaning they will need rewriting. After that typescript team is a little bit more defensive about the features they add. Mainly, the feature has to be in stage 3 or later to be implemented. So to get bleeding-edge features you will need some extra steps like babel and etc.

So is it worth it?

If you are working on a small project you might be better off with just plain javascript. Will have less friction and it will do the job for you. If you are in a team though it might bring some benefits in terms of self-documenting code and preventing others from doing bad things. If you already have a reasonable amount of code which has some system to check the types and safety at runtime, test time, let’s say prop types or a large set of unit tests, you could actually benefit from typescript.

So, all in, I’d say if you can, use it.