DEV Community

Cover image for Downsides of TypeScript?
Rammina
Rammina

Posted on • Updated on • Originally published at rammina.com

Downsides of TypeScript?

I love Typescript and enjoy using it. However, it's not perfect and has its downsides.

Some downsides of Typescript (based on my experiences and what others have shared):

  • another thing to learn
  • more code boilerplate, especially for 3rd party libraries (glares at Redux)
  • installation costs initial time (but it makes up for it later with the type safety)
  • npm modules without typedef are difficult to work with TS
  • it only starts to pay off once your codebase gets larger and complex
  • the resources are scattered in multiple places (no universal, comprehensive resource like MDN; I find the Typescript handbook lacking)
  • slower compile/build time

I most likely will use Typescript for most of my projects from here on, unless a third-party library has no type definitions or doesn't work well with it.

DISCLAIMER:

This post only expresses my thoughts and opinions (based on my limited knowledge) and is in no way a substitute for actual references. If I ever make a mistake or if you disagree, I would appreciate corrections in the comments!

Other Media

Feel free to reach out to me in other media!

Rammina Logo

Twitter logo

Github logo

Top comments (21)

Collapse
 
latobibor profile image
András Tóth

It's the fault of redux for their faux typescript implementation. In the sadly dying overmindjs types work as you expect after an initial configuration. You do not tell the selector function what kind of item you expect from it, it is inferred.

So, let's start using alternatives instead of that library.

Collapse
 
phryneas profile image
Lenz Weber • Edited

Since 2019 we officially recommend using Redux Toolkit, which not only gets rid of most boilerplate, it also gets rid of almost all TypeScript annotations.
Modern Redux at this point is almost completely inferred, with a few manual type casts during setup that cannot be avoided. Please see redux-toolkit.js.org/tutorials/typ...

Also, you don't write any switch..case reducers, ACTION_TYPE constants, hand-written action creators or immutable reducer logic any more.

If you want to see how modern Redux looks like with TypeScript, just do npx create-react-app my-app --template redux-typescript and take a look around.

Honestly, I don't know what else we can do except repeatedly communicate that on all available channels.
I don't see how we're at fault for devs not ever revisiting the documentation for years and years.

Collapse
 
fkhadra profile image
Fadi Khadra

I think one of the main issue is that most people don't read the documentation 😔.

Thread Thread
 
phryneas profile image
Lenz Weber

Yeah, that's why we're also commenting on articles ^^

Collapse
 
latobibor profile image
András Tóth

This is great news, I will check it!

Collapse
 
rammina profile image
Rammina

Thank you for very much for informing us. This helps a lot because seems like not many are aware of this. Going to try it out!

Collapse
 
jonrandy profile image
Jon Randy 🎖️

Downsides off the top of my head:

  • Strong typing
  • More ludicrous tooling
  • Promotes a tendency to over-engineer stuff
  • Restricts creativity

Yes, I'm a huge fan 😀

Collapse
 
patarapolw profile image
Pacharapol Withayasakpunt

Some may disagree, but my favorite thing to like, is as; or even as unknown as.

Real static typed languages can't even do this.

Collapse
 
rammina profile image
Rammina

Oh yeah! as is a really nice addition that Typescript has.

Off-topic: Cute Homura pfp

Collapse
 
rammina profile image
Rammina

Strong typing can be an advantage.

How would you say it causes a tendency to over-engineer stuff?

Collapse
 
andreidascalu profile image
Andrei Dascalu • Edited

Also, it's a superset of JS that helps with some typing problems but not all and it does carry downsides.

'any' basically disables the typecheck altogether. Not sure why it's even there as it has the potential to mess things up badly.

It can lead to an unjustified false sense of security in typing, which is why linters have emerged as must-have tools, yet another tool in the toolchain but one that goes beyond its definition (it's not just linting but doing more complex static analysis)

Collapse
 
rammina profile image
Rammina

Explicit 'any' can help with third-party libraries with really bad typedef or no typedef.

Sometimes, you just need to move on with the development process, while keeping in mind the consequences of using explicit 'any'.

Collapse
 
andreidascalu profile image
Andrei Dascalu

Yes, but that thing gets obscured in time, leading to hidden risks made worse by people coming in later to see typescript and think "oh, it's ok". I can keep in mind what I did and group decisions to an extent but we all know long term docs are a pipe dream.
So yeah, it requires careful evaluation of long term risks

Collapse
 
dastasoft profile image
dastasoft

However, there are nuances:

  • another thing to learn: this should not be a negative thing, learning other approaches is basic for a good programmer.
  • the reward is for bigger projects: using create-react-app and lodash for example, any IntellIsense and documentation you have at that moment thanks to TS is already giving you something.

It has a learning curve (not much for the first steps if you already master JS) and you need to type more, but when you realize that you can spot a lot of bugs without having to start the whole project, go through documentation or internal class/component definitions, that's a big time saver.

At the end of the day TS allows you to write more understandable code that will be needed if you work with other people or even for yourself in the future.

My biggest gig with TS is that if you use TS with a poorly architected project, it can be a bigger mess than with JS.

Collapse
 
rammina profile image
Rammina

I agree with your counter-arguments for these certain points. They are definitely minor downsides for the great benefits that it gives, especially in the long run and in larger scale projects.

I will definitely keep this in mind and most likely will borrow your idea when people refuse to use TypeScript without good reason.

Collapse
 
bradtaniguchi profile image
Brad

There is also the downside, that you can use TypeScript totally wrong and end up with code that is more complicated than plain JavaScript, but without any of the real benefits of TypeScript. Since its flexible enough, you could end up just using it wrong and not really getting enough benefits.

I personally thing making things as strict as possible can really help, but to each their own :D

Collapse
 
rammina profile image
Rammina

Yeah, I try my best not to have too many explicit any and cheat like that. Need to learn more about the concepts to avoid unnecessarily bloating the code without gaining the benefits of TypeScript.

Collapse
 
lexiebkm profile image
Alexander B.K.
  • "another thing to learn" - Yeah this is the main reason.
  • "I find the Typescript handbook lacking" - Last time I read from this handbook doc, I didn't complain. I was only confused with the characteristics of Interface which are different from ones found in established OOP languages like Java and C++.

Because I am interested in using Angular, I have to learn TS.

Collapse
 
oreychandan profile image
oreychandan

Yes I totally agree with the typescript handbook lacking.

Collapse
 
talr98 profile image
Tal Rofe

No rule applies any project. Some projects would fit using Typescript, some wouldn't.
Typescript is for more complex and bigger projects in general.

Collapse
 
rammina profile image
Rammina

I agree! I most likely will use TypeScript for team projects and large-scale applications after I'm done practicing it.