But I don't understand how adding types will suddenly make frontend coding more efficient.
It won't. The runtime is not affected. All it does is add meta-data to your program so static analysis gets more information about what your code is doing AKA catch type errors.
Type errors in frontend code are typically rare in comparison to state, timing and synchronization errors for example.
Learning the basics of TS is easy if you know any other typed language. However some of the concepts are fairly "unique" to TS or rather unusual in other typed languages.
Studying TS won't hurt you, you can read more code and interact better in TS codebases. However, if you plan on actually using it I very much recommend you just pick a useful subset of the features. It is already a fairly bloated language which can distract you from doing stuff that matters.
This is true, especially for experienced coders, it's not very common for you to mix up types. Especially if your code is well written; high cohesion, loose coupling. Loose coupling means that you have simple interfaces which accept simple types (e.g. strings, numbers, raw objects without internal state or methods). Simple interfaces make it easy to figure out what arguments to pass to a function... This means you don't rely so much on a type checker.
What I don't like about statically typed languages is that they seem to encourage developers to define methods which accept complex arguments of type such as 'InputController' or 'Logger' or other complex 'live instances' which makes the function interfaces more complex and encourages violation of the separation of concerns principle.
For example, instead of passing a Logger to a component, why not just make the component an EventEmitter (or similar) and it can emit/trigger an 'error' or 'warning' event on itself when it encounters an error... Then this event can be handled and logged at a higher layer in the code. High cohesion means that components should only concern themselves with one thing; if a component also has to handle its own logging, that's already 2 things... IMO, statically typed languages often encourage such types of tight coupling, low cohesion anti-patterns. Just look at what happened to Java. You need to read 5 pages of documentation to get anything done because the interfaces are so complex and rigid. It almost forces developers into anti-patterns.
Comments
It won't. The runtime is not affected. All it does is add meta-data to your program so static analysis gets more information about what your code is doing AKA catch type errors.
Type errors in frontend code are typically rare in comparison to state, timing and synchronization errors for example.
Learning the basics of TS is easy if you know any other typed language. However some of the concepts are fairly "unique" to TS or rather unusual in other typed languages.
Studying TS won't hurt you, you can read more code and interact better in TS codebases. However, if you plan on actually using it I very much recommend you just pick a useful subset of the features. It is already a fairly bloated language which can distract you from doing stuff that matters.
This is true, especially for experienced coders, it's not very common for you to mix up types. Especially if your code is well written; high cohesion, loose coupling. Loose coupling means that you have simple interfaces which accept simple types (e.g. strings, numbers, raw objects without internal state or methods). Simple interfaces make it easy to figure out what arguments to pass to a function... This means you don't rely so much on a type checker.
What I don't like about statically typed languages is that they seem to encourage developers to define methods which accept complex arguments of type such as 'InputController' or 'Logger' or other complex 'live instances' which makes the function interfaces more complex and encourages violation of the separation of concerns principle.
For example, instead of passing a Logger to a component, why not just make the component an EventEmitter (or similar) and it can emit/trigger an 'error' or 'warning' event on itself when it encounters an error... Then this event can be handled and logged at a higher layer in the code. High cohesion means that components should only concern themselves with one thing; if a component also has to handle its own logging, that's already 2 things... IMO, statically typed languages often encourage such types of tight coupling, low cohesion anti-patterns. Just look at what happened to Java. You need to read 5 pages of documentation to get anything done because the interfaces are so complex and rigid. It almost forces developers into anti-patterns.
> Type errors in frontend code are typically rare in comparison to state
I find that this isn't true as soon as you weld Redux, MobX, or any other distributed-logic, central-state mechanism into an application.
If you can avoid that, maybe it's superfluous.
I would not write any new code in plain JavaScript today, though.