21. “…using Flow or TypeScript
could have prevented
15% of the public bugs
for public projects on GitHub.”
22. “ .
10% , .
, . That’s
shocking. If you could make a change to the way we do development
that would reduce the number of bugs being checked in by 10% or
more overnight, that’s a no-brainer. Unless it doubles development
time or something, we’d do it.”
23. “ .
10% , .
, . That’s
shocking. If you could make a change to the way we do development
that would reduce the number of bugs being checked in by 10% or
more overnight, that’s a no-brainer. Unless it doubles development
time or something, we’d do it.”
24. “ .
10% , .
, . That’s
shocking. If you could make a change to the way we do development
that would reduce the number of bugs being checked in by 10% or
more overnight, that’s a no-brainer. Unless it doubles development
time or something, we’d do it.”
( TypeScript MS )
46. … because JavaScript was not designed
around a type system, Flow sometimes
has to make a tradeoff. When this
happens Flow tends to favor
soundness over completeness,
ensuring that code doesn’t have any
bugs.
(https://flow.org/en/docs/lang/types-and-expressions/#soundness-and-completeness-a-
classtoc-idtoc-soundness-and-completeness-hreftoc-soundness-and-completenessa)
Non-Goals: [...] Apply a sound or
"provably correct" type system.
Instead, strike a balance between
correctness and productivity.
(https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals)
47. Non-Goals: [...] Apply a sound or
"provably correct" type system.
Instead, strike a balance between
correctness and productivity.
(https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals)
“
” .
.
48. … because JavaScript was not designed
around a type system, Flow sometimes
has to make a tradeoff. When this
happens Flow tends to favor
soundness over completeness,
ensuring that code doesn’t have any
bugs.
(https://flow.org/en/docs/lang/types-and-expressions/#soundness-and-completeness-a-
classtoc-idtoc-soundness-and-completeness-hreftoc-soundness-and-completenessa)
.
49. … because JavaScript was not designed
around a type system, Flow sometimes
has to make a tradeoff. When this
happens Flow tends to favor
soundness over completeness,
ensuring that code doesn’t have any
bugs.
(https://flow.org/en/docs/lang/types-and-expressions/#soundness-and-completeness-a-
classtoc-idtoc-soundness-and-completeness-hreftoc-soundness-and-completenessa)
Non-Goals: [...] Apply a sound or
"provably correct" type system.
Instead, strike a balance between
correctness and productivity.
(https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals)
63. [flow] number (This type is incompatible with
an implicitly-returned undefined.)
[ts] Type '"JavaScript"' is not comparable
to type '"TypeScript" | "Flow"'.
129. • To Type or Not to Type: Quantifying Detectable Bugs in JavaScript
• TypeScript Design Goals
• Github Octoverse 2017
• Trade-offs in Control Flow Analysis #9998
• Treat `in` operator as type guard #10485
• Various TypeScript & VS Code release notes
130. • Why We Chose TypeScript
• TypeScript at Lyft
• Flow and TypeScript
• TypeScript vs. Flow
• Flow vs. TypeScript
• Type Systems for JavaScript: Elm, Flow, and TypeScript
