In flexibility: Typescript > Flow
In strictness + dev time: Flow > Typescript
In an untyped world in dev time : Untyped > Typescript > Flow
Flow may cost the most up front, but having true enforced type checking across the code base will drive out more bugs and reduce dev time significantly.
Typescript is optional, but can achieve the same type checking goal without having to implement it throughout the entire code base. Typescript is just a tool you can integrate throughout your code base. You can optionally run your JavaScript through a TypeScript compiler and it will help you find bugs in the code.
I'm a firm believer that if code is part of your core business, all data types need to be strictly defined. When using Typescript, the use of any or other generic types is frowned upon.
Untyped is the wild west. When you have no guarantees on data types (i.e. ), there are no more guarantees when the owner changes their data types, its consumers will remember to change their code as well. The hidden cost to this is that consumers are not made aware of the breaking change. So they will have to find it runtime with numerous hot fixes for each consumer.
When you run into a data type issue, typically a null reference exception, it can potentially take hours to debug. As that data flows through the systems, its value can be mutated and changed. When it arrives to your system, you have no idea whether it is a collection or primitive by looking at the variable. You have to run it to verify that it is truly a collection or primitive. If the provider of that data changes it, you can setup a shared data contract with your consumers, letting them know when types change or new versions become available.
My firm stance: There must be an agreed upon contract with data types if you are writing enterprise level code.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
In flexibility: Typescript > Flow
In strictness + dev time: Flow > Typescript
In an untyped world in dev time : Untyped > Typescript > Flow
Flow may cost the most up front, but having true enforced type checking across the code base will drive out more bugs and reduce dev time significantly.
Typescript is optional, but can achieve the same type checking goal without having to implement it throughout the entire code base. Typescript is just a tool you can integrate throughout your code base. You can optionally run your JavaScript through a TypeScript compiler and it will help you find bugs in the code.
I'm a firm believer that if code is part of your core business, all data types need to be strictly defined. When using Typescript, the use of any or other generic types is frowned upon.
Untyped is the wild west. When you have no guarantees on data types (i.e. ), there are no more guarantees when the owner changes their data types, its consumers will remember to change their code as well. The hidden cost to this is that consumers are not made aware of the breaking change. So they will have to find it runtime with numerous hot fixes for each consumer.
When you run into a data type issue, typically a null reference exception, it can potentially take hours to debug. As that data flows through the systems, its value can be mutated and changed. When it arrives to your system, you have no idea whether it is a collection or primitive by looking at the variable. You have to run it to verify that it is truly a collection or primitive. If the provider of that data changes it, you can setup a shared data contract with your consumers, letting them know when types change or new versions become available.
My firm stance: There must be an agreed upon contract with data types if you are writing enterprise level code.