Yes, I do, and I find it greatly beneficial. I use Typescript, not Flow, so whatever I say might only be relevant to Typescript.
I find that static typing makes it way easier to code in general as it adds more contextual meaning to the code. If I have a function that expects a number, I know it expects a number and not a string or an object or a function. That is very crucial information gleaned by just looking at the function declaration. I do not mean to say that it takes the place of documentation. I say, instead, that the type information is part of the documentation that is integrated into the code itself. In a way it's semantic documentation. Both understandable to the programmer and understandable to the compiler/language. In any case, I find that this makes it very easy for me to read and understand code and as a result makes me more productive. Also the awesome intellisense and refactoring support makes it even more easy to just code fast and securely. Personally I think that JS devs spend way to much time fixing type errors.
One of the greatest strengths of JS static type systems like TypeScript and Flow is that you can break out of the static types whenever you want by using the 'any' type. Whenever the type system becomes too burdensome or complicated and it feels like it's getting in your way, you can simply cast to the 'any' type and all type restrictions go away so you can do whatever you could in plain JS. Most of JS code is implicitly statically typed in that any piece of code expects the data to be a certain type. Only in a few programs, and usually a small section of those programs, benefit from flexibility in types. Using TypeScript and FlowType we can keep those sections dynamically typed but at the same time use type guarantees for the rest of the program. This to me is the best of both worlds.
Another point worth noting is that TypeScript is not Java or C# in JavaScript. The type system is uniquely designed to be a way of describing idiomatic JavaScript with static type annotations instead of making programmers write JS code like Java.
For example, in JS land it's a common practice for a function to expect a certain argument to be either a number or a string. This can be represented in TypeScript as a Union Type:
functionfoo (arg : number | string) {
...
}
The reason I say this is that a lot of people transfer their distaste for classic OOP languages to opinions about TypeScript and FlowType without actually using them. It's not like those languages at all. It feels instead like a natural evolution of JavaScript.
Issues
One problem I faced initially was finding type definitions for third party libraries. But you'll be glad to know that this is not such a big problem anymore, especially for the popular libraries. Today it's just as easy as running an npm command. This is the command for installing the type definitions for express:
npm install @types/express
And there's certainly no harm in using a library without type definitions available. You can use them in your code just the same way as you would in plan JS, just without the type guarantees, i.e, everything will have the 'any' type. This is the same situation you'd be at with plan JS but at least the rest of the code could be more sound.
Nishant Agrwal
Yes, I do, and I find it greatly beneficial. I use Typescript, not Flow, so whatever I say might only be relevant to Typescript.
I find that static typing makes it way easier to code in general as it adds more contextual meaning to the code. If I have a function that expects a number, I know it expects a number and not a string or an object or a function. That is very crucial information gleaned by just looking at the function declaration. I do not mean to say that it takes the place of documentation. I say, instead, that the type information is part of the documentation that is integrated into the code itself. In a way it's semantic documentation. Both understandable to the programmer and understandable to the compiler/language. In any case, I find that this makes it very easy for me to read and understand code and as a result makes me more productive. Also the awesome intellisense and refactoring support makes it even more easy to just code fast and securely. Personally I think that JS devs spend way to much time fixing type errors.
One of the greatest strengths of JS static type systems like TypeScript and Flow is that you can break out of the static types whenever you want by using the 'any' type. Whenever the type system becomes too burdensome or complicated and it feels like it's getting in your way, you can simply cast to the 'any' type and all type restrictions go away so you can do whatever you could in plain JS. Most of JS code is implicitly statically typed in that any piece of code expects the data to be a certain type. Only in a few programs, and usually a small section of those programs, benefit from flexibility in types. Using TypeScript and FlowType we can keep those sections dynamically typed but at the same time use type guarantees for the rest of the program. This to me is the best of both worlds.
Another point worth noting is that TypeScript is not Java or C# in JavaScript. The type system is uniquely designed to be a way of describing idiomatic JavaScript with static type annotations instead of making programmers write JS code like Java.
For example, in JS land it's a common practice for a function to expect a certain argument to be either a number or a string. This can be represented in TypeScript as a Union Type:
function foo (arg : number | string) { ... }The reason I say this is that a lot of people transfer their distaste for classic OOP languages to opinions about TypeScript and FlowType without actually using them. It's not like those languages at all. It feels instead like a natural evolution of JavaScript.
Issues
One problem I faced initially was finding type definitions for third party libraries. But you'll be glad to know that this is not such a big problem anymore, especially for the popular libraries. Today it's just as easy as running an npm command. This is the command for installing the type definitions for express:
npm install @types/expressAnd there's certainly no harm in using a library without type definitions available. You can use them in your code just the same way as you would in plan JS, just without the type guarantees, i.e, everything will have the 'any' type. This is the same situation you'd be at with plan JS but at least the rest of the code could be more sound.
Hope it helps :)