DEV Community

Cover image for Thoughts on TypeScript
Matti Bar-Zeev
Matti Bar-Zeev

Posted on

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:

Image description

(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;
   }
Enter fullscreen mode Exit fullscreen mode

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:

Image description

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

Top comments (10)

Collapse
 
cski profile image
Patryk Cieszkowski

The argument of TS being a propriatery software doesn't hit me at all. It's published under Apache 2.0 license, they can't back that off - they could however start publishing newer versions under a new license, but I don't believe the changes they implement are worth the hassle - the vast majority of the software would still remain opensource.

My issue with TS is the fact it doesn't work; it's sole purpose is supposed to be implementation of typechecking capabilities. And that works OKish, up until the pre-compile stage of development. It doesn't help you at all during actual runtime.

Collapse
 
thewix profile image
TheWix

If you have anti-corruption layers then you can trust what was compiled at runtime. You will not have issues unless you incorrectly deal with untyped data. This is a fact with untyped JS or even C#/Java/etc. If you incorrectly handle values from a form or API you will get an error in any language, typed or not.

Collapse
 
kof profile image
Kof

After years of building big backend projects, transitioning to TS was such an upgrade for me. Apart from making the code more readable, it was a life saver on big refactors.

Other than that the only caveat for me, is having to wait the compilation time each run.

Collapse
 
mbarzeev profile image
Matti Bar-Zeev • Edited

Thanks for the time going over and giving your point of view on each!
BTW, I find that the Babel plugin is a different impl than TSC, which kinda ale
Alarms me. This can cause all sorts of errors along the way which will be hard to trace... Oh well 😏

Collapse
 
etienneburdet profile image
Etienne Burdet

Understanding that TS is no longer a thing to be ignored.

Learning a technology with that reason in mind won't yield any results. It's not TS—or React's—fault. You add a tech to your stack because it solves problem: less runtime errors, less defensive conditions, less Proptypes, safer production builds etc. If it doesn't scratch an itch, then why bother?

In the codebase I work on it's priceless, I use components my team didn't design and I have all the informations straight away instead of digging dozens of subcomponents and I'm more confident I'm feeding them the right stuff.

For a solo dev, that might not be the case… at least if you doesn't have a single clue on how it would remotely solve a problem you face everyday.

Collapse
 
mbarzeev profile image
Matti Bar-Zeev

I think, and don't get this the wrong way please, that saying that you learn only what is derived by whether it solves a problem or not is a bit naive. The industry is well invested in TS, and if you'd like to keep you options open, you need to know you way with it, for it will give you an advantage over another candidate which does not know it.

Collapse
 
etienneburdet profile image
Etienne Burdet

I can understand that-although for something as simple as TS, it's a bit overkill imo.

But then don't expect to see the benefits if it's "just in case" for a project you don't work on yet.

Collapse
 
christiankozalla profile image
Christian Kozalla

Concerning your comment about "proprietary" and licensing: OP stated that Microsoft or Facebook have the right to change the license whenever they like. So, what's the point of referencing the current Apache license? If they can change it whenever they see fit..

Collapse
 
cski profile image
Patryk Cieszkowski

…making it useless.

 
cski profile image
Patryk Cieszkowski

Do you even understand the difference between a language, and a superset?