If we're wild-assed guessing, mine is that TypeScript eventually merges with JavaScript. It is a wisely designed set of optional type constraints that aren't incompatible with JS proper. Seeing as how every conformant TypeScript compiler is also a conformant JavaScript compilers, the split is pretty small and eating one's vegetables is good for you.
(With one nit: TypeScript enums are weird and while they work in JavaScript ways they are weird and might be best off being rethought, even if it's backwards-incompatible.)
If TypeScript becomes natively interpreted (instead of transpiled), I might actually consider using it for my personal projects. In the meantime, I don't use it because I cannot stand the build, bundling step and the problematic debugging experience with source mapping (and difficulty to debug production errors where source maps are not available). If you write code correctly with loose coupling and good tests, static typing only provides marginal benefits.
Your last sentence is writing a very large check that I'm not confident at all you can cash.
Static typing obviates most runtime type checking, which your module boundaries need to be doing (and exercising in tests). Libraries like runtypes deal with the last mile of it by generating runtime type guards that also project back into the static type system. This removes the need for entire classes of tests, as well as many of those handling intra-module transforms. It's telling that the people doing some of the best work in, say, Ruby are in on both tooling like Sorbet and libraries like dry-types/dry-struct -- because the benefits are significant in terms of minimizing engineering risk.
Static typing is also standardized and machine-readable documentation. This can't be understated. Human-written documentation rots with changes. The guarantees at module level from your static types does not.
Particularly when gradually introduced, these are significant force multipliers. If you want to take on the additional risk for your toy projects, more power to you (I sometimes write Ruby when doing something that doesn't matter) but I certainly find those benefits significantly more than "marginal" if anyone else ever has to deal with my code--including future-me.
> Static typing obviates most runtime type checking, which your module boundaries need to be doing
I've heard this argument many times but it's misleading. Well written functional tests will be able to identify type mismatches implicitly. For example if you add 10 + "1", you will get "101" - The test will fail. You don't need to check if the result is a string, you just need the assertion to expect the number 11. Tests will catch type mismatches implicitly. In practice, this applies to pretty much every kind of type mismatch. Type mismatches break functionality; so if the functionality is well tested, then type mismatches will be caught implicitly.
I personally hate everything about the transpilation step; the time it takes (slows down dev-test iteration by a lot), the source mapping aspect, debugging in a live production environment (I hate having to debug transpiled/mangled JavaScript). I hate having to handle multiple permutations of engine versions (too many possible permutations of tsc and node.js version numbers which introduces configuration and setup difficulties; it rarely works out of the box; it's a nightmare for open source projects when you're potentially dealing with a broad range of different operating systems and environments which you have 0 control over; maybe the user needs tsc version x.x.x for some different reason and you cannot force version y.y.y onto them!!! So their tsc version will not work with your tsconfig)... It just adds a ton of bloat, dependencies (security/maintenance burden), setup/compatibility problems and the value it adds is marginal.
Comments
If we're wild-assed guessing, mine is that TypeScript eventually merges with JavaScript. It is a wisely designed set of optional type constraints that aren't incompatible with JS proper. Seeing as how every conformant TypeScript compiler is also a conformant JavaScript compilers, the split is pretty small and eating one's vegetables is good for you.
(With one nit: TypeScript enums are weird and while they work in JavaScript ways they are weird and might be best off being rethought, even if it's backwards-incompatible.)
If TypeScript becomes natively interpreted (instead of transpiled), I might actually consider using it for my personal projects. In the meantime, I don't use it because I cannot stand the build, bundling step and the problematic debugging experience with source mapping (and difficulty to debug production errors where source maps are not available). If you write code correctly with loose coupling and good tests, static typing only provides marginal benefits.
Your last sentence is writing a very large check that I'm not confident at all you can cash.
Static typing obviates most runtime type checking, which your module boundaries need to be doing (and exercising in tests). Libraries like runtypes deal with the last mile of it by generating runtime type guards that also project back into the static type system. This removes the need for entire classes of tests, as well as many of those handling intra-module transforms. It's telling that the people doing some of the best work in, say, Ruby are in on both tooling like Sorbet and libraries like dry-types/dry-struct -- because the benefits are significant in terms of minimizing engineering risk.
Static typing is also standardized and machine-readable documentation. This can't be understated. Human-written documentation rots with changes. The guarantees at module level from your static types does not.
Particularly when gradually introduced, these are significant force multipliers. If you want to take on the additional risk for your toy projects, more power to you (I sometimes write Ruby when doing something that doesn't matter) but I certainly find those benefits significantly more than "marginal" if anyone else ever has to deal with my code--including future-me.
I've heard this argument many times but it's misleading. Well written functional tests will be able to identify type mismatches implicitly. For example if you add 10 + "1", you will get "101" - The test will fail. You don't need to check if the result is a string, you just need the assertion to expect the number 11. Tests will catch type mismatches implicitly. In practice, this applies to pretty much every kind of type mismatch. Type mismatches break functionality; so if the functionality is well tested, then type mismatches will be caught implicitly.
Thats weird, the best ppl in JS seem to be tearing TS out due to compile time/toolchain perf problems.
Do you have any large typescript projects?
I personally hate everything about the transpilation step; the time it takes (slows down dev-test iteration by a lot), the source mapping aspect, debugging in a live production environment (I hate having to debug transpiled/mangled JavaScript). I hate having to handle multiple permutations of engine versions (too many possible permutations of tsc and node.js version numbers which introduces configuration and setup difficulties; it rarely works out of the box; it's a nightmare for open source projects when you're potentially dealing with a broad range of different operating systems and environments which you have 0 control over; maybe the user needs tsc version x.x.x for some different reason and you cannot force version y.y.y onto them!!! So their tsc version will not work with your tsconfig)... It just adds a ton of bloat, dependencies (security/maintenance burden), setup/compatibility problems and the value it adds is marginal.