Gotta comment ... I dove into TypeScript about a year ago and dropped it. I saw the value but because of a large number of libraries and custom components of my own, switching purely to TypeScript wasn't easy and I was in a hurry.
Fast forward several months and I picked it up again. I've now been writing everything that I would have done in JS in TypeScript and have built several applications using both Angular and React entirely in TypeScript. I've also sold my teammates on switching to the language.
When I was (stuck) writing JavaScript, the frustration factor was high for me. I'd get nebulous errors[0], hunt around the line it referenced, swear a little, and trace the code back to the cause. I would wildly estimate that one out of ten attempts at blindly running my code would succeed[1]. Even on unit tests, which had a higher degree of success since they were testing much less, still had a much higher fall-over[2] rate than I get in typed languages that I enjoy. The addition of types, which adds a little overhead, flipped that over. I am still surprised every time I refresh a page that uses code I'm modifying and it loads. The reduction in time spent debugging (and swearing) makes me enjoy the language more every day that I use it. It's even left me longing when I am writing code in other languages (mostly Java/C# these days) and features I have come to really enjoy (union types, intersection types and to a lesser extent the duck-typing nature of the language[3]).
Since crapping on any language, or feature/lack of feature of a language tends to become a religious war fought with verbal violence, allow me to admit a few points: Traditionally, I avoided JavaScript and jobs related to it. Personally, I hate the language. This means I've spent considerably less time researching all of the best practices/techniques for surviving those cases where I have to write JavaScript. I started in C and Pascal and prior to a few months ago spent 99% of my time in typed languages. I am an advocate for unit testing[4], but I find test-driven development requires me to work backward and it's less productive for me. I'd imagine that if I went all in with TDD, I might see fewer of these problems, but many of the best practices for JS development are best practices in the languages I am more proficient in and despite following these practices, JS design led to these practices being less effective at reducing bug frequency. Yes, I could just be a yelling 'get off my lawn' because I'm unwilling to change[5]. But I've also worked closely with highly-skilled JS developers who could rapidly produce incredible things as a result of its flexible, dynamic typing. Incredibly, though, one of those 'huge JavaScript advocates' was the one who told me to give TypeScript a chance late last year. Though he would always fight me on the "dynamic vs. static" thing, his argument was that TypeScript's type system was light-weight enough to keep out of his way while strict enough to lower the frequency of self-inflicted foot bullet-holes (paraphrased). Really, though, ... two nulls, asinine boolean implicit conversions necessitating code like double-bang and === / !== operators[6] should be enough.
[0] Often depending on whatever framework I was using, but I've rarely found one that returns an error that results in a really obvious 'oh, I know what I did to cause that'
[1] I like to check that a component renders visually appropriately and often do a quick check before I've written all of the required unit/integration tests to make sure it's rendering accurately (right data/right result).
[2] As in, something fails badly enough to stop execution rather than just failing on an assert for an incorrect result.
[3] It's a love-hate thing for me -- the result is being able to reduce boilerplate making mostly-compatible types interact, but the down-side is that the compiler giving a pass to "A=B" when "A" has at the properties of "B" results in some subtle bugs that have already bitten me more than once.
[4] Though I don't buy into TDD (either before writing the code or after) solves most of the issues of dynamic typing. I've had more than a few tests fail because of a type-related issue...in the test.
[5] Except that I love learning new languages and 'keeping up' and have found that as I've aged, I can pick up new languages far more quickly than I could in my early 20s... [plug]RUST![/plug] I'm also not terribly old, nor terribly sensitive about being called an oldster.
[6] I don't recall who, but someone was once reading code out-loud and said "if action fuckin' equals 'ADD' and payload.Length doesn't fuckin' equal zero". Adding in the fuckin' every time he encountered the "really, really [not] equals" operator. So that is how I mentally read those. I'll never forgive him (sorry for the swears ... and doubly sorry if you end up reading code like this as a result).
Fast forward several months and I picked it up again. I've now been writing everything that I would have done in JS in TypeScript and have built several applications using both Angular and React entirely in TypeScript. I've also sold my teammates on switching to the language.
When I was (stuck) writing JavaScript, the frustration factor was high for me. I'd get nebulous errors[0], hunt around the line it referenced, swear a little, and trace the code back to the cause. I would wildly estimate that one out of ten attempts at blindly running my code would succeed[1]. Even on unit tests, which had a higher degree of success since they were testing much less, still had a much higher fall-over[2] rate than I get in typed languages that I enjoy. The addition of types, which adds a little overhead, flipped that over. I am still surprised every time I refresh a page that uses code I'm modifying and it loads. The reduction in time spent debugging (and swearing) makes me enjoy the language more every day that I use it. It's even left me longing when I am writing code in other languages (mostly Java/C# these days) and features I have come to really enjoy (union types, intersection types and to a lesser extent the duck-typing nature of the language[3]).
Since crapping on any language, or feature/lack of feature of a language tends to become a religious war fought with verbal violence, allow me to admit a few points: Traditionally, I avoided JavaScript and jobs related to it. Personally, I hate the language. This means I've spent considerably less time researching all of the best practices/techniques for surviving those cases where I have to write JavaScript. I started in C and Pascal and prior to a few months ago spent 99% of my time in typed languages. I am an advocate for unit testing[4], but I find test-driven development requires me to work backward and it's less productive for me. I'd imagine that if I went all in with TDD, I might see fewer of these problems, but many of the best practices for JS development are best practices in the languages I am more proficient in and despite following these practices, JS design led to these practices being less effective at reducing bug frequency. Yes, I could just be a yelling 'get off my lawn' because I'm unwilling to change[5]. But I've also worked closely with highly-skilled JS developers who could rapidly produce incredible things as a result of its flexible, dynamic typing. Incredibly, though, one of those 'huge JavaScript advocates' was the one who told me to give TypeScript a chance late last year. Though he would always fight me on the "dynamic vs. static" thing, his argument was that TypeScript's type system was light-weight enough to keep out of his way while strict enough to lower the frequency of self-inflicted foot bullet-holes (paraphrased). Really, though, ... two nulls, asinine boolean implicit conversions necessitating code like double-bang and === / !== operators[6] should be enough.
[0] Often depending on whatever framework I was using, but I've rarely found one that returns an error that results in a really obvious 'oh, I know what I did to cause that'
[1] I like to check that a component renders visually appropriately and often do a quick check before I've written all of the required unit/integration tests to make sure it's rendering accurately (right data/right result).
[2] As in, something fails badly enough to stop execution rather than just failing on an assert for an incorrect result.
[3] It's a love-hate thing for me -- the result is being able to reduce boilerplate making mostly-compatible types interact, but the down-side is that the compiler giving a pass to "A=B" when "A" has at the properties of "B" results in some subtle bugs that have already bitten me more than once.
[4] Though I don't buy into TDD (either before writing the code or after) solves most of the issues of dynamic typing. I've had more than a few tests fail because of a type-related issue...in the test.
[5] Except that I love learning new languages and 'keeping up' and have found that as I've aged, I can pick up new languages far more quickly than I could in my early 20s... [plug]RUST![/plug] I'm also not terribly old, nor terribly sensitive about being called an oldster.
[6] I don't recall who, but someone was once reading code out-loud and said "if action fuckin' equals 'ADD' and payload.Length doesn't fuckin' equal zero". Adding in the fuckin' every time he encountered the "really, really [not] equals" operator. So that is how I mentally read those. I'll never forgive him (sorry for the swears ... and doubly sorry if you end up reading code like this as a result).