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)