> Development time? Types reduce mental overhead and abstraction for the developer, speeding up development.
React has proptypes that make contract guarantees -- ones that don't disappear at compile time. Most stuff is local to a single file. If your imports and shared objects are so poorly named and poorly understood that types become the major blocker, you have bigger issues.
> Run time? Variables with types that stay static execute faster in JS engines.
The biggest issue in JS engines is making functions monomorphic. Typescript is perfectly happy with every single function in your system being a slow, megamorphic call.
As to changing variables, judicious use of `const` is the real answer here.
There is definitely something to be said for enforcing object structure though. Adding and removing properties to an object is a significant issue. The non-type solution here is the addition of records and tuples to the system. Since they cannot be modified, the general performance will go up.
I like the idea of types, but dislike typescript. Most importantly, it is not a sound type system and the illusion of sound types is worse than dynamic types IMO. If I ever adopt a type system into my current project, it will undoubtedly be F# (fable) or ReasonML (ocaml) where I can gain sound types and better syntax without giving up the practical need for mutation (like with Elm where lots of garbage and poor interactions with JS libraries are the result).
React has proptypes that make contract guarantees -- ones that don't disappear at compile time. Most stuff is local to a single file. If your imports and shared objects are so poorly named and poorly understood that types become the major blocker, you have bigger issues.
> Run time? Variables with types that stay static execute faster in JS engines.
The biggest issue in JS engines is making functions monomorphic. Typescript is perfectly happy with every single function in your system being a slow, megamorphic call.
As to changing variables, judicious use of `const` is the real answer here.
There is definitely something to be said for enforcing object structure though. Adding and removing properties to an object is a significant issue. The non-type solution here is the addition of records and tuples to the system. Since they cannot be modified, the general performance will go up.
https://github.com/tc39/proposal-record-tuple
I like the idea of types, but dislike typescript. Most importantly, it is not a sound type system and the illusion of sound types is worse than dynamic types IMO. If I ever adopt a type system into my current project, it will undoubtedly be F# (fable) or ReasonML (ocaml) where I can gain sound types and better syntax without giving up the practical need for mutation (like with Elm where lots of garbage and poor interactions with JS libraries are the result).