> - if people enter or leave your team frequently: yes
Interesting, I would put that one as a no, since introducing TS to you project means longer time train new employees. On the other hand it will make sure their commits break something less often, so not so sure about this one
The learning curve on something like TS for people already conversant in JS is pretty shallow. I think the time invested learning it will pay for itself very quickly on any non-trival project.
I wish I had something similar for all the Ruby code I write.
Does it actually do static type checking? Because I don't see anything about types in the documentation. It looks like just a more sophisticated linter, which is very different from what TypeScript and Flow bring to the table.
I started using rubocop earlier this year and I've become a huge fan. It's done a lot to improve the quality of my code and the consistency of code on projects with multiple developers.
Training is not a problem. Anyone who knows the basic of OOP can learn TypeScript in a day.
On the other hand, giving them constraints (because of the type system) ensures their work is not breaking stuff along the way as they learn the ropes of the code base.
From my perspective, setting up a build flow (dependencies, etc) is the biggest problem with TypeScript projects. If you assume that's already done in a given project, then the negative impact is gone and TypeScript only makes it easier.
> since introducing TS to you project means longer time train new employees.
From my experience, even developers who have never used statically typed languages are able top pick up the Flow / TypeScript in a matter of hours. Not everything, but enough to barely have an impact on productivity. The main hurdles in the learning process as far as I can tell have been nullable types (smaller hurdle) and declaring types for external modules (big hurdle, many of them still don't fully grasp it).
I've found Flow to have a much, much lower barrier to entry than TypeScript, and I believe it's because it's quite strict / sound as the author very well pointed out (slide 12 for example).
Learning time of the actual type system is nothing compared to learning/getting in to the code base if it's anything non-trivial.
At the very least type annotations are compiler verified documentation which is a huge time saver, along with better tooling that lets you navigate trough the code more efficiently.
> since introducing TS to you project means longer time train new employees
Does it though? I mean, we're talking about intelligent beings who can drive cars and program computers, how hard can it be for them to spend an hour reading the typescript docs?
I suppose it depends on ones definition of a long time.
Learning TS itself takes minutes. Probably -seconds- if you're familiar with Java/C#.
The real learning curve is in the edge cases, of which there are plenty. Fighting with a 3rd party lib with incorrect type defs, dealing with cases common to JS that are hard to properly type (such as certain functional constructs), dealing with things missing from the TS compiler that are present in ES6/babel, etc.
Those things are quickly going away and may eventually be a non-ssue, but as of today, they're very real. That's in contract with languages that have the type system baked in from the get go, where it wouldn't be an issue.
Interesting, I would put that one as a no, since introducing TS to you project means longer time train new employees. On the other hand it will make sure their commits break something less often, so not so sure about this one