TypeScript v. JavaScript

Chris Smith's article about What to Know Before Debating Type Systems is still a good read and pretty insightful even years later. His repeated points about implicit type annotations remind me of my (current) opinion about experimenting with TypeScript vs. straight ES6 / ES20015.

In fact, this is a very interesting place to conduct an experiment of sorts, since TypeScript is semantically very similar to JavaScript, a superset with compile-time types.

Costs and Caveats:

• Zero Cost: (1) If I am writing JavaScript code and must run it through some build process before running and testing it anyway (BabelScript, JSX preprocessor, webpack, or some combination) then the difference in cost between TypeScript and JavaScript is zero.
• Low to No Cost: (2) If most of the JavaScript code I write can be type-checked as TypeScript with very few or even zero type annotations (because of type inference), or the annotations are easy to add when they are needed (expr becomes expr: any).
• Low Cost (in my opinion): (3) If TypeScript stays a strict superset of EcmaScript 20XX so all new JavaScript features can be used in TypeScript as they are introduced. (I do not see this as a legitimate risk, especially on a small project, although others may disagree on whether they think Microsoft may break this commitment in the future.)
• Rare but High (Truly Annoying) Cost: (4) If very few correct-as-JavaScript programs are rejected by the TypeScript compiler, then TypeScript is not a burden over and above straight JavaScript.

Potential Benefits:

• Low but Positive Benefit (5) If I get tooling benefits (admittedly fewer than just jslint of jshint would already give, but still, VS Code support for TypeScript is pretty great on Mac, Windows, and Linux).
• Nice (Fairly Small) Benefit: (6) If I get documentation (and IntelliSense tooling) benefits from having the types around (infinitely better than comments that could be out of date since the compiler makes sure the programmer keeps this form of documentation in sync at all times).
• Biggest Benefit but How Rare is It? (7) If some or many incorrect programs are rejected before I even run them (especially common errors like missing object key or field names, variable names, etc. -- but I hear jslint/jshint can do this too, to some degree).
• Corollary Medium Size Benefit, Common for Me (8) If I lean on types for doing Nearly-Provably-Equivalent code refactors, the way that fits my style for C# coding -- when I want to change something in one place, have it break in 17 other places, and then fix every place knowing that it is every possible occurrence of the change (and I get a clickable list in the IDE).

If each condition is met, then there is a case (for me) for playing with TypeScript. I'm not arguing that it is good for every project, just that there are conditions where the benefits can outweigh the costs (especially when the costs are very low and the quality of the tools is so high).

Just to be clear: to be a fair comparison I would have to try using jslint/hint in a good IDE and see if using it with ES6 delivers 90% of the benefit of TypeScript.

Another caveat is if you are publishing a package on NPM, it is one extra (large) dependency to require TypeScript instead of straight JavaScript. If you want more people to use your package in more places, TypeScript may add a little extra hesitancy or "use more virtual paper and kill more virtual trees" each time people install your package.