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!
Top comments (21)
It's the fault of
reduxfor their faux typescript implementation. In the sadly dyingovermindjstypes 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.
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-typescriptand 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.
I think one of the main issue is that most people don't read the documentation 😔.
Yeah, that's why we're also commenting on articles ^^
This is great news, I will check it!
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!
Downsides off the top of my head:
Yes, I'm a huge fan 😀
Some may disagree, but my favorite thing to like, is
as; or evenas unknown as.Real static typed languages can't even do this.
Oh yeah!
asis a really nice addition that Typescript has.Off-topic: Cute Homura pfp
Strong typing can be an advantage.
How would you say it causes a tendency to over-engineer stuff?
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)
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'.
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
However, there are nuances:
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.
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.
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
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.
Because I am interested in using Angular, I have to learn TS.
Yes I totally agree with the typescript handbook lacking.
No rule applies any project. Some projects would fit using Typescript, some wouldn't.
Typescript is for more complex and bigger projects in general.
I agree! I most likely will use TypeScript for team projects and large-scale applications after I'm done practicing it.