#1 – You don't have to upgrade TypeScript versions till you are ready, and newer versions never have breaking changes anyways. The syntax remains strictly compatible with ES6 and beyond. Packages you consume publish compiled JS and aren't dependent on specific TypeScript versions at all.
#2 – If libraries haven't published types, just use them as pure JavaScript (which is what you would have done anyways). Lack of documentation again applies to both JS and TS equally.
#3 – I assume you are talking about compiler errors? I have personally found them to be simple to understand, especially when the exact location is highlighted in your IDE. At runtime there will be no difference since it is all the same JS code under the hood.
#4 – Yes transpilation takes non-zero time. TypeScript has a lot of tooling around incremental compile/watching for changes, so I don't think it should really be that much of a burden during development. I have worked on massive TS projects and don't even notice the compile task running in the background.
I find this post weird because TypeScript does have some real drawbacks – overly complex type system, makes the codebase more verbose, false sense of security (no runtime type mismatch errors), mix of typed and untyped code in codebase etc., but your reasons for disliking it all seem superficial and easy to overcome.
In my personal opinion everyone should be starting new JS projects in strict-mode TypeScript by default unless there is a reason not to.
Regarding #1: this is not true always. Libraries publish types and their type definitions could use new TypeScript features that could force an update.
This is rare (I have never run into it in many years of writing TS code and pulling repos from NPM), and if it does happen you can always ignore the definition and turn it back into a plain JS package.
Not rare. Happens every 12 months or so in my experience as a library maintainer. It really sucks that Typescript, let alone .d.ts files produced by the compiler, don’t follow anything resembling semver.
#3 really depends on how complex your types are. Lots of legacy JS libraries and applications can be quite... esoteric when typed. Then there are the people that love playing with the type system for the sheer joy of it.
The net result is that greenfield TS projects often end up simpler and faster but that’s not very useful for someone buried in an old JS project that enthusiastically abuses the dynamicness allowed.
+1 for the strict mode. I consider it a must-have quality requirement.
I honestly don't understand why it's even optional, as being able to know what is nullable or potentially undefined is extremely important, and not having it can lead to tons of bugs.
Just to add to #4, I've worked on some large codebases where transpilation starts taking a very long time, and I begin to think "wow, this is really straining TSC"... so far, every time it's happened, it's been because some sort of data files weren't being excluded from the build.
Idk if I’m just an idiot but my company’s codebase for the last year has had pretty slow tsc compile times and nobody on my team has been able to make it better. Probably since we have a decent amount of generated code that pushes the amount of source code up considerably, but still no good answers to make that better.
I don't do anything with generated code. But is it necessary to generate that code every time TSC does a build? Could it be independent? I usually use two different ts export indexes, and create two dist JS files for each app. Most of the boilerplate that rarely gets touched (user management, login and signup screens, common UI elements, utility code) is essentially in an outer JS file that loads the inner JS with the business logic and meat of the app, but has no imports from the inner JS whatsoever. They're basically two separate projects. Not that I've noticed much difference with tsc, but it makes webpack or r.js faster if you can create separate webs of dependencies and only need to repack one of them without touching the other...
#2 – If libraries haven't published types, just use them as pure JavaScript (which is what you would have done anyways). Lack of documentation again applies to both JS and TS equally.
#3 – I assume you are talking about compiler errors? I have personally found them to be simple to understand, especially when the exact location is highlighted in your IDE. At runtime there will be no difference since it is all the same JS code under the hood.
#4 – Yes transpilation takes non-zero time. TypeScript has a lot of tooling around incremental compile/watching for changes, so I don't think it should really be that much of a burden during development. I have worked on massive TS projects and don't even notice the compile task running in the background.
I find this post weird because TypeScript does have some real drawbacks – overly complex type system, makes the codebase more verbose, false sense of security (no runtime type mismatch errors), mix of typed and untyped code in codebase etc., but your reasons for disliking it all seem superficial and easy to overcome.
In my personal opinion everyone should be starting new JS projects in strict-mode TypeScript by default unless there is a reason not to.