Thoughts on TypeScript

In this post I would like to share with you some of the thoughts I’ve been having for quite some time about TypeScript (TS), after experiencing with it for a while. It is not as dramatic as it sounds 😁

What triggered me to write this was a Twitter thread discussing TS and a debate over its long-term benefits and ROI, and I felt that Twitter is probably not the best medium to express my impressions of TS, since some elaboration was in order on my part:

(you can find the entire thread here)

I know that these sorts of posts might trigger some emotional bursts for some of you who are heavily invested in TS and really enjoy it. I’m not here to piss you off, but I would like to ask you to keep an open mind and read an amateur TS coder expressing his thoughts about this technology.

The Hype

If you’d ask any developer transitioning from a strictly typed language (Java, C#) to JS, they would say that one of the key benefits and joys of JS is that it's a dynamic language. Suddenly they don’t have to write a code-poem for any variable they define and it’s ok to mix types like it’s the 60’s.
Yes, it demanded you to be more careful and there was no compiler to save you from making mistakes, but hey - it also meant that there was no compilation at all!

I first heard of TS when the Angular team joined forces with Microsoft and made TS a first-class citizen language for Angular development.
Before that, if you used VSCode you've probably noticed that when you inspected some JS APIs you’d be directed to a .d.ts file where you would find the type definition for it. Nothing to pay exceptional attention to.

Transpiled languages were nothing new to the web dev community. Let’s see - we had CoffeeScript, Flow, Elm, GWT counts? sure why not, and of course TS (and probably more I’ve neglected). So we must ask ourselves why TS won, right? Well, at least I did.

Perhaps it was the Angular collaboration, perhaps it was Facebook which pushed its own typed language “Flow” for React, but It seemed that slowly, more and more development teams found TS appealing. It found its way to some well known OS projects, and from there on many of the web community thought-leaders started pushing it as a great tool to maintain large code bases with a lot of developers contributing to it.

Perhaps it also allowed a smoother transition for BE developers in becoming what is known as a “full-stack developer”.

It came to the point where today TS is a required skill from any web developer. Companies and developers consider TS as the new and advanced way of writing code for the client and server, and so the trend was fully on.

Realization

Understanding that TS is no longer a thing to be ignored, I started learning it while also practicing it on my day job. The learning curve is somewhat tough but manageable, though I will admit that I still have a lot to learn, and consider myself an amateur TS coder.
Having said that, my relatively short experience with TS along with my vast experience with web development brought up some issues I found (and still finding) hard to accept. Here they are:

Readability

Let’s take this example of React’s FunctionComponent interface:

interface FunctionComponent<P = {}> {
       (props: PropsWithChildren<P>, context?: any): ReactElement<any, any> | null;
       propTypes?: WeakValidationMap<P> | undefined;
       contextTypes?: ValidationMap<any> | undefined;
       defaultProps?: Partial<P> | undefined;
       displayName?: string | undefined;
   }

I’m sure that TS expert coders can look at this interface and know right away what’s going on, but for me this looks like a noisy mess.

Before you say it, I know - it is a matter of getting used to it, same as with anything else, and you’d be right.
We, as humans, have this great ability to adapt to almost anything which comes our way. The question you should ask yourself is “what is the cost of adjusting your mental model to this?”.

This also applies to “simple” code - for example, take a React component in TS… so much clutter, so much metadata over the code which blurs the vision on what really matters.

Bad Compiler Errors

I remember playing with Elm and was amazed by its compiler messages. It really felt like I was coding with J.A.R.V.I.S on my side. Here is an example:

Damn that’s nice.

The experience I have with TS is the complete opposite. The messages are so enigmatic, sometimes repeating more than once for the same error, and not intuitive at all.

If one of the benefits of TS is getting notified over code errors by the compiler as you code, the minimum requirement is for these messages to be clear and precise. This makes working with TS so frustrating for me.

Additional build step

If you are running a full fledged web project you probably have Babel for transpiling your code, and then Webpack (or another tool) bundling it, and all of these are steps in building your final artifact.

Using TS means that on top of all of these you need to introduce yet another build step which transpiles TS into JS. This stands in contradiction to the growing need, of any medium and above project, to reduce the build steps (and time) it takes to produce production ready artifacts.

Low ROI

I think that this is the strongest argument I have here. I feel that I’ve yet to see the light of TS. I didn’t find myself at any steps along the way saying “wow, TS really helped me here! Time well spent”.

I sometimes spend a lot of time battling with interfaces, types, enum etc., when I know all along that the tests pass and the code is fulfilling its purpose in the best way.

Some say that TS shines when it comes to refactoring a large code base, but you have tests for that, don't you?. Another developer complained on Twitter that he spent 6 hours struggling with TS. Is it worth it? How many tests can be written in 6 hours instead of trying to bend TS rules?

Only thing I find useful with TS is that I don’t need to test the types of arguments a certain method is expecting. Sorry, not worth my time.

Proprietary

Not too long this word was considered a curse when related to technology. TS, for those who don’t know, belongs and is maintained by Microsoft as an open source.

I know that there are other technologies we use which are proprietary as well (like React), but it still remains proprietary and gives the corporation owning it the right to change its licensing in any given time, much like Facebook attempted to do with React back in the time.

There is a calculated risk we’re taking when embracing a proprietary technology. A risk that should not be taken lightly. When you are already heavily invested in this technology there is not much you can do.

(the “Proprietary” bullet influenced the title chosen for this post, can you tell why? ;)

Ok, it's not all bad

TSC, the TS compiler has it’s benefits. I, for one, found it very useful when I wanted to compile my package source code into 2 different module formats: ESM and CJS.

I think that in that sense it might be the better choice then going with Rollup, Babel or what-have-you, since it will allow you to introduce TS code in the future without the need to change anything, should you choose to do that, of course ;)

Wrapping up

I’m not here to trigger or convince you to choose this over that. I’m simply expressing my own thoughts about TS at the moment. I might see the TS light in the future and realize that the ROI is actually high, but this has not happened yet.

I’m also taking the web community trends into consideration. TS is nothing that a web developer can afford to ignore these days, and yes, you need to know your TS to stay relevant in our industry and be able to contribute to OS projects.

I do hope that what I wrote here made you think whether the effort you’re putting into TS is worth it, or maybe we’re all climbing a ladder leaning against the wrong wall...

Hey! If you liked what you've just read check out @mattibarzeev on Twitter 🍻

Photo by Aaron Burden on Unsplash