A well written article — but I think you are a bit on the wrong track. I’ve seen this happen a lot in my career as a software developer: People feeling real problems living in a variegated world with lots and lots of things you can choose from. I’ve written about it in the past. There really is a state of mind in which people are incapable to accept the existence of choice. When confronted with choice, they feel pain and the only thing which seems to help is to eradicate any other option they decided against.

So your choice was Typescript. That’s definitely no wrong or bad choice. A lot of people use it and feel empowered through it — particularly through its influence on tooling. Typescript is a strong tool to make tools smarter. Better and more focused autocomplete, parameter information and error reporting for simple type errors.

What I think you’re wrong with is, that you think there are really no better options to TypeScript. You mentioned the type system. Actually Facebooks Flow offers a stronger type system with much (!) better type inference and in many ways better suited to typical JavaScript programs. Flow is not presented as another language — it is just a type checker. It even works on unannotated ES5 JavaScript, but you can add types either in comments or in a syntax like the one used in TypeScript. Flow also offers support for autocomplete or parameter information — but it really shines with its capability to detect type errors in JavaScript. One example is its default of non-nullable types which detects e.g. unguarded method calls on bindings which can be null references. Typescript is incapable to detect this very very common error situation in JavaScript code.

Does this mean that Flow is the winner? No! Definitely not! This are all options with their particular pros and cons and no single one can fulfill any need.

To me personally — TypeScript is not the right tool because it tries to be to much. It wants to be a static Typechecker for JavaScript. It wants to be a ES2015 transpiler. It wants to be an IDE toolkit. It even marks itself as a language while at the same time distancing from that idea. If Typescript would be three projects — that would be a much more compelling situation. To some degree this even is the case:

You can use TypeScript-Definition-Files (d.ts) to extend IDEs like WebStorm to provide better autocompletion (the tooling aspect). You can use the Typescript compiler as a mere ES2015 transpiler. And yes – you can use it as a type checker. These are all separate concerns and it is important to understand this. Uncertain people feel comforted by so called “all-in-one” solutions. Be careful with that urge and don’t end up with your next lock in situation!

So instead of blindly adopting “Typescript” as a solution for anything — think about cherry picking what really helps and don’t forget other options (like Flow and Babel!). You can e.g. use d.ts-Files in Webstorm, transpile ES2015/ES2017 with Babel and let your code type check using Flow. The winner takes it all. ;)

Developer — Author — Photographer — Guitarist

Developer — Author — Photographer — Guitarist