He probably did not use it in a large project yet.
The benefits drown in the downsides:
- Write types for 3rd party APIs? Fun!
- You are lucky if you find type definitions for 2 out of 10 libs you use.
- The Polymorphic nature of javascript: you WILL add more loc to satisfy the type system.
- It does not replace the need for schemas. You will have to write validators for side-effects anyway and flow/ts will not understand them (yet).
- let and const came into flow not too long ago. Typescript does not have object-spread and is just about to get async funcs in a few weeks/months. So forget about your favorite ES7 feature.
- IDE's - not exciting. atom/nuclide is slow as hell and drove me nuts.
- 90% of all types are string or number.
The only real benefit is IDE auto completion. It did not find any serious errors. Mostly false positives because of polymorphism or incorrect definitions.
In case of TypeScript:
I think it can be nice if you are either developing a library with not many dependencies or you are working in a ecosystem which embraces types (like angular2).
In all other cases I agree with @igl that it adds too much noise to your project.
Regarding bugs, it's already been shown to be less than true that static typing prevents more bugs than the time it takes[0]. IMHO with clean modules, pure functions, attention to detail and good organization following a functionally minded paradigm, static types add *very* little, other than some level of documentation.
Personally, I've rarely seen the point, and I've worked with statically typed languages for well over a decade of my career. JS happens to be a favorite language of mine... I like that JS makes it easy to continue working as opposed to breaking the world apart. I think the biggest issue is that the two things that should be first and foremost in defining a project tend to get punted until later...
The first being error handling. I'm working on a project right now, that swallows errors left and right, always returning a happy path. Internal node modules with only positive callbacks, and no error handling in sight. One must define errors as a top-level concern. When I design APIs, the return type is always Errorable<t> instead of X : IErrorable... in this way, there are a few properties on a wrapper object, { code, error, data:T } code should match the HTTP response code, error (nullable) will contain an error object with at *least* a "message" property and data will be the expected successful data. In this way the client can always check if response.error, quickly, cleanly. From there, a given client should have several error states, temporary/retry, permanent/no-retry and fatal (stop the world). The handling of these conditions should be in place before *any* other features... Error handling/display is a *critical* feature that should not be deferred/burried.
The second being proper handling of users/authentication/roles. This is a far second in terms of importance but is often done nearly as badly as consistent error handling.
Even though I mention types/interfaces wrt errors, that doesn't mean they have to be typed in code, just consistently implemented. Likewise, I don't like classical structure outside of UI bound contexts. There's no need for it. Functional flows and composition will almost always be cleaner and less buggy. The issues at play are more about diligence, testing, structure and review than they are typed or not. All the typing in the world won't prevent a buggy implementation, which is where *most* problems lay.
[0] https://medium.com/javascript-scene/the-shocking-secret-about-static-types-514d39bf30a3#.iypvaf25w
(copied from my comment in TFA)
Regarding bugs, it's already been shown to be less than true that static typing prevents more bugs than the time it takes[0]. IMHO with clean modules, pure functions, attention to detail and good organization following a functionally minded paradigm, static types add *very* little, other than some level of documentation. Personally, I've rarely seen the point, and I've worked with statically typed languages for well over a decade of my career. JS happens to be a favorite language of mine... I like that JS makes it easy to continue working as opposed to breaking the world apart. I think the biggest issue is that the two things that should be first and foremost in defining a project tend to get punted until later... The first being error handling. I'm working on a project right now, that swallows errors left and right, always returning a happy path. Internal node modules with only positive callbacks, and no error handling in sight. One must define errors as a top-level concern. When I design APIs, the return type is always Errorable<t> instead of X : IErrorable... in this way, there are a few properties on a wrapper object, { code, error, data:T } code should match the HTTP response code, error (nullable) will contain an error object with at *least* a "message" property and data will be the expected successful data. In this way the client can always check if response.error, quickly, cleanly. From there, a given client should have several error states, temporary/retry, permanent/no-retry and fatal (stop the world). The handling of these conditions should be in place before *any* other features... Error handling/display is a *critical* feature that should not be deferred/burried. The second being proper handling of users/authentication/roles. This is a far second in terms of importance but is often done nearly as badly as consistent error handling. Even though I mention types/interfaces wrt errors, that doesn't mean they have to be typed in code, just consistently implemented. Likewise, I don't like classical structure outside of UI bound contexts. There's no need for it. Functional flows and composition will almost always be cleaner and less buggy. The issues at play are more about diligence, testing, structure and review than they are typed or not. All the typing in the world won't prevent a buggy implementation, which is where *most* problems lay. [0] https://medium.com/javascript-scene/the-shocking-secret-about-static-types-514d39bf30a3#.iypvaf25w (copied from my comment in TFA)