About: Staff Software Engineer at CDON
I believe this is the WRONG QUESTION.
Previously, this topic has been discussed in different shapes here:
And here:
But, these two topic forget one simple thing:
Typescript is just a matter of taste, it's not about you writing better code or them writing an ugly one.
Clean code doesn't abide to language X or Y.
After all, clean code is clean code.
What do you think?
Well said 👌
I really like the way you pointed out what a type check can prevent and the tests vs. types.
A type system like Typescript isn't a magic bullet, any more than BDD or TDD, but it can catch issues you'd miss otherwise.
My experience is more with Flow than Typescript, but I've found that adding explicit types to my Javascript means I have to think more about the type of any arguments I pass to a function or method, and means it's clearer how something will behave. It's also useful for React components in particular to specify what the props passed to the component are using Flow types.
Along similar lines, in the last few years I've begun using type hints more in PHP (both parameter and return types), and enabling strict mode, and it's caught a fair few bugs that would have slipped through otherwise.
As an application gets bigger, it's been my experience that defining explicit types and enforcing them becomes more and more useful, because you can then guarantee you aren't going to get any weird errors due to treating something as the wrong type.
A type system like Typescript isn't a magic bullet, any more than BDD or TDD, but it can catch issues you'd miss otherwise.
As you said, there will be never a magic bullet.
I should try typing for Python soon.
I think it's really situationally dependent, but I feel that way about a lot of language safety features.
I've dealt with a few type errors in JavaScript, but TypeScript would not have caught any of them (they were all cases of runtime values being something other than expected, and thus collapsing to either undefined or NaN, that's quite simply something TS just can't save you from). The only exception to this has been dealing with the difference between for...in and for...of loops, but that's rather hyper-specific and mostly due to my background in Python (where for value in array means you're iterating array values, not array indices).
Beyond that, most of the other arguments aren't all that great for me (I use vanilla Vim for coding, so type checking in the IDE isn't an option for me even if I do use TS, I'm pretty religious about documenting my code properly, so that's not an issue for me either, etc), so I have no real interest in using it.
Exactly, it totally depends.
I use vanilla Vim for coding
Love that you hold onto your preferences!
The main benefit of TypeScript isn't that it catches type errors (though it does do that).
It's that it gives you confidence your understanding of a program is correct.
In a language with no static typing, to determine whether or not, say, a function parameter can be null, you have to audit every caller of that function. 1) you don't know where the callers are, because of dynamic dispatch and use of first class functions. 2) even if you can find all of the callers, you don't know anything about the arguments they pass until you read all of their callers.
This similarly makes it very difficult to refactor JavaScript, because the assumptions that the code makes aren't in the code (and it also makes it nearly impossible for IDEs to help, without messing it all up)
TypeScript means you can write, maintain, and read more complex code while worrying less. Making a change to one part of the code no longer requires reading the entire codebase, since type checking verifies that the boundaries maintain (and explicitly state!) their assumptions.
TLDR: TypeScript is the most effective way to write JavaScript. The code you make will be just as good as if it were written in JavaScript. However, when changing the code it lets you do more with exponentially less effort, because static analysis replaces exhausting manual busywork.
Absolutely right, the big plus about static typing is the refactor factor.
Yes, clean code is clean code. HOWEVER.... I've been a Typescript holdout for a long time, until recently. Type checking is good, yes, but in my opinion the Intellisense is a huge productivity booster. Being able to get quality, correct code hints is vital when coding.
Question for the Typescripters:
How many of you are using no-explicit-any?
I just had a discussion with someone about TS projects we had both worked on and he seemed to have fewer of the issues I had. Turns out he had no-explicit-any off though. I wonder how much that affects the discussion?
The direct answer to the question is no. But it can help you to remove a big number of type-related errors.
The next question is what type-related errors are? It can be as simple as
1 + "!", or we can make the wrong state irrepresentable with the help of types than type checker will help you remove some state errors as well.Type checker can prevent
See this article which compares tests and types.
As well I need to mention that TS isn't sound, so it won't prevent all type errors (sad).
I treat TS as just one more tool in my toolbelt, together with unit tests, integration tests (cypress), screenshot diffing tests etc.