The reasons I don't use Typescript

At my first few programming jobs I worked on Java projects. It is here that I first learned to appreciate, but also hate strict typing.

In a short amount of time I was drawn to front-end work and became proficient in JavaScript and really fell in love with the language. It was relatively easy to master, which enabled me to focus more on the user and quality and to work much faster than with Java. When Node.js came out I was thrilled because if it proved itself in large-scale production environments, then I could use it across the stack.

Fast-forward and Angular 2.0 dropped which was exclusively Typescript. A bold move at the time! I had heard about TS prior to that, but ignored it because it came out of Microsoft (Sorry MS! I really had no patience with anything MS back in those days, but things have since improved in Redmond).
My first impression with Typescript was, "Wow, this feels less like an improved version of JavaScript and more like a weird version of Java."

Time went on and Typescript became popular. In fact, it's so popular that some people are simply using it because it seems "everyone uses it". I revisited Typescript (a couple times!) in hopes of being more mentally prepared for the Javaness and seeing past initial hurdles and finding its real value. I was underwhelmed. Here's why I'm not a fan:

Non-standard

Maybe it's a phase, but I really have little interest anymore in the JavaScript fashion trends. I find it all to be too big, too fussy, too much in the way, and too non-revolutionary to justify the cost. If it can be linked to and run natively in the browser I have almost no interest. Typescript is no exception here and more than CoffeeScript ever did it's fragmenting open source.

On the other hand, I do want to learn new features of the web platform, including JavaScript. Efforts should be going here, not to fragmentation. I want to write real JavaScript, minify, and deploy. Anything that complicates that process - no matter how popular - has to demonstrate a net increase in value. Like, game-changing value.

And I don't think I'm alone here. JavaScript's fault-tolerant loosely-typed behavior is not a problem that needs solving, or it's not a big enough source of issues to justify writing non-standard, non-executable, pipeline-dependent source code. If Typescript features make their way into ECMAScript, I'll definitely use some of it once the runtimes have native support.

Typescript begets Typescript

I know technologies can be misused, but I've seen a lot of Typescript written just to comply with the other Typescript that was written. You might be thinking, "Duh! That's the whole point!" and I know that, but what it means in practice is unless your custom types are truly something special (much of what I've seen are meaningless wrappers around the primitives), then those custom types beget more mostly meaningless Typescript code, which renders the exercise pointless.

Not the kind of issues I see

JavaScript does have types and strict type checking and I've found it's quite easy and sufficient to leverage them when I need to, but I don't often need to.

The issues I most often need to deal with can't be solved with Typescript:

• Network and environment-related issues
• API call failures
• AuthN, AuthZ stuff
• CSS not rendering the way I expected
• Events not behaving the way I expected
• Copy/pasted the wrong value, like /foo url instead of /bar url, or foo storage key instead of bar key
• I goofed and used the wrong method, like filter() when I should have map()ed
• Algorithms

I would love to see some good data on non-Typescript projects and their percentage of production issues that would have been prevented with Typescript. Please share if you have a resource.

Also, my IDE is smart enough to do what Typescript enables in regards to intellisense, so there's no benefit there.

Strict is not good for the web

I remember one of my teams was investigating a production issue and eventually found the root cause was their custom type. Yes, a production issue caused by Typescript, not prevented by it.

Their code expected an object that came back from one of our APIs to have everything dictated by the type. Well, the API sent back the object without an optional property and the resulting code from Typescript crashed because heaven forbid the object didn't have all the properties Typescript thought it should have even though the object did have all the properties needed by the application.

Yes, of course you can throw more Typescript solutions at Typescript problems, and eventually pile on enough pseudo-code to make your JavaScript bullet-proof (we hope ) or you can embrace the fault-tolerant nature of the web and wisely use JavaScript's strict type enforcement when actually necessary.

I enjoy the benefits of not having Typescript

Despite the herd mentality that forms around some technologies, Typescript is not 100% bliss. For example, can you share or copy some Typescript, paste, and execute? No. You only have that freedom with JavaScript. Can you debug your source code? No. What you see in dev tools is Chrome's best attempt at unraveling the mess and presenting you with something kind of close to source. You can debug JavaScript at any time, with any tool, and even if it's minified you can usually make sense of it pretty quickly (and the path back to unminified source is direct and results in real debuggable code).

Other benefits you get are:

• less configuration (I've wasted hours doing this for Typescript)
• less false errors ("Sorry Typescript, but it is you who are wrong, not my code. Here, have another @ts-ignore and be quiet.")
• faster builds
• less compatibility issues when using 3rd-party stuff
• smaller payloads

So, is Typescript bad. No.
Is it a must-have that provides tons of value. No.
Should everyone Typescript because [current year]. No.
Should you use it? If you have found a genuine need, yes.