Why We Chose Typescript
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&#x27;t easy and I was in a hurry.<p>Fast forward several months and I picked it up again.  I&#x27;ve now been writing <i>everything</i> that I would have done in JS in TypeScript and have built several applications using both Angular and React entirely in TypeScript.  I&#x27;ve also sold my teammates on switching to the language.<p>When I was (stuck) writing JavaScript, the frustration factor was high for me.  I&#x27;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 <i>much</i> 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 <i>still surprised</i> every time I refresh a page that uses code I&#x27;m modifying and <i>it loads</i>.  The reduction in time spent debugging (and swearing) makes me enjoy the language more every day that I use it.  It&#x27;s even left me longing when I am writing code in other languages (mostly Java&#x2F;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]).<p>Since crapping on <i>any</i> language, or feature&#x2F;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&#x27;ve spent considerably less time researching all of the best practices&#x2F;techniques for surviving those cases where I <i>have</i> 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&#x27;s less productive for me.  I&#x27;d imagine that if I went <i>all in</i> 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 &#x27;get off my lawn&#x27; because I&#x27;m unwilling to change[5].  But I&#x27;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 &#x27;huge JavaScript advocates&#x27; was the one who told me to give TypeScript a chance late last year.  Though he would always fight me on the &quot;dynamic vs. static&quot; thing, his argument was that TypeScript&#x27;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 === &#x2F; !== operators[6] should be enough.<p>[0] Often depending on whatever framework I was using, but I&#x27;ve rarely found one that returns an error that results in a really <i>obvious</i> &#x27;oh, I know what I did to cause that&#x27;<p>[1] I like to check that a component renders visually appropriately and often do a quick check before I&#x27;ve written all of the required unit&#x2F;integration tests to make sure it&#x27;s rendering accurately (right data&#x2F;right result).<p>[2] As in, something fails badly enough to stop execution rather than just failing on an assert for an incorrect result.<p>[3] It&#x27;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 &quot;A=B&quot; when &quot;A&quot; has at the properties of &quot;B&quot; results in some subtle bugs that have already bitten me more than once.<p>[4] Though I don&#x27;t buy into TDD (either before writing the code or after) solves most of the issues of dynamic typing.  I&#x27;ve had more than a few tests fail because of a type-related issue...in the test.<p>[5] Except that I <i>love</i> learning new languages and &#x27;keeping up&#x27; and have found that as I&#x27;ve aged, I can pick up new languages far more quickly than I could in my early 20s... [plug]RUST![&#x2F;plug] I&#x27;m also not terribly old, nor terribly sensitive about being called an oldster.<p>[6] I don&#x27;t recall who, but someone was once reading code out-loud and said &quot;if action <i>fuckin&#x27; equals</i> &#x27;ADD&#x27; and payload.Length <i>doesn&#x27;t fuckin&#x27; equal</i> zero&quot;.  Adding in the <i>fuckin&#x27;</i> every time he encountered the &quot;really, really [not] equals&quot; operator.  So that is how I mentally read those.  I&#x27;ll never forgive him (sorry for the swears ... and doubly sorry if you end up reading code like this as a result).