Skip to content

Instantly share code, notes, and snippets.

@djedr

djedr/talk--static-types-and-javascript--2017-03-08.md

Last active March 8, 2017 18:03
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save djedr/e3b0a3f9d43fe10705d04620d6e6577b to your computer and use it in GitHub Desktop.
Save djedr/e3b0a3f9d43fe10705d04620d6e6577b to your computer and use it in GitHub Desktop.
Download ZIP
Static types and JavaScript. TypeScript and Flow
Raw
talk--static-types-and-javascript--2017-03-08.md

Static types and JavaScript

2017-03-08

Dariusz Jędrzejczak

http://djedr.github.io

This is a quick overview and comparison of TypeScript and Flow compiled from different sources (see links throughout and at the end of this document).

Outline

  1. Intro
  2. Demo
  3. Comparison
  4. Features in depth

0. Intro

Static types?

  • Static (before run-time) analysis of code for type-correctness
    • Verify if types of variables, values, expressions, etc. abide to formally defined rules
  • A type checker usually a part of language's compiler
  • Gets type info from e.g.
    • Hand-written type annotations (1)
    • Inference (2)

(1)

let x: string;

(2)

let y = 5; // inferred type would be number

Nominal typing

Structural typing

Why use static types in JS?

  • Easier maintenance of large codebases
    • Helping avoid writing read-only code
    • Better IDE support
      • Reliable refactoring (e.g. rename symbol)
      • Jumping to definitions
      • Autocompletion
      • Inline type errors
      • Editor tips
      • Etc.
    • No more writing tests that essentially do type-checking
      • Which are also more error-prone and less exhaustive than a complete type system
  • Documentation with superpowers
    • E.g. constrain which types of arguments a function allows and what types it returns
    • And also statically check code for violating thusly defined constraints
  • Sometimes type information may
    • Improve readability of code
    • Make code easier to reason about
  • Catching common JS bugs before run-time
    • Implicit type conversions
    • null dereferences
    • undefined is not a function
  • Introducing type checking with TypeScript or Flow doesn't require a lot of effort

Why not?

How to decide?

  • http://djcordhose.github.io/flow-vs-typescript/elm-flow-typescript.html#/49
    • If a project is simple and/or short-lived then there's no real benefit in introducing a typechecker
    • Otherwise it might help. Particularly:
      • If there might be a need for refactoring in the future
      • If the project is "very important or even crucial for the success of your company"
      • If "people enter or leave your team frequently"
      • If "you have substantial amount of algorithmic code"

Demo

Comparison

TypeScript

  • By Microsoft
    • Influenced by C#, so familiar also to Java developers
  • Headline: "JavaScript that scales."
  • "A typed superset of JavaScript that compiles to plain JavaScript."
  • "Ease of use and tool support"
  • Can be considered a separate language
    • Based on ES6+
    • Compiles to ES3+
    • The basic tool is compiler
    • Adds features/syntax sugar of its own

Flow

  • By Facebook
  • Headline: "A static type checker for JavaScript"
  • "Soundness, no runtime exceptions as goal"
  • Just a type checker (not a compiler)
    • Used similarly to a linter
  • Designed specially for JavaScript

Common features

  • Optional type annotations
  • Gradual typing
  • Type inference
  • Compatiblility with JS
  • Realtime feedback
  • Control flow analysis
    • Understand loops (for, while, etc.), branching (if, switch), implicit returns, etc.

Similarities

  • Same basic way of working
    • Do type-checking
    • Report errors if any
    • Generate plain JavaScript without type annotations
  • Similar syntax (many constructs the same) and semantics for basic types
  • Both use structural typing
    • TypeScript always
    • Flow mostly, except for classes

Differences

  • Different syntax and semantics for complex types
  • Major difference
    • Flow uses nominal typing for classes
    • TypeScript uses structural typing for classes

Annotations in comments in Flow

  • An interesting feature: obviates the need for transpilation
// @flow
function strlen(x)/*: string*/ {
   return x.length;
}
strlen('Hello, world!');

Integration with JavaScript

IDE Support

  • TypeScript: Visual Studio Code
    • Written in TypeScript and with focus on this language
    • Also has basic typechecking and IDE features for plain JavaScript
    • Can analyze JSDoc type annotations to obtain type info
    • https://code.visualstudio.com/
  • Flow: Atom + Nuclide
  • IntelliJ IDEA / Webstorm 2016.3+
    • Flow: integrated checking and display of messages
    • TypeScript: uses TypeScript compiler's Language Service

See also

In conclusion

  • In general it might be worth it
  • TypeScript seems better

Thank you

  • Questions?

Sources

[pro-typescript-flow-vs-typescript] http://jan.varwig.org/2017/02/15/flow-vs-typescript.html

[pro-flow] https://shinesolutions.com/2017/01/05/typescript-flow-and-the-importance-of-toolchains-over-tools/

[flow-typed] https://flowtype.org/docs/third-party.html

[ts-samples] http://www.typescriptlang.org/samples/index.html

[ts-playground] https://www.typescriptlang.org/play/index.html

[try-flow] https://flowtype.org/try/

[flow-vs-typescript-presentation] http://djcordhose.github.io/flow-vs-typescript/flow-typescript-2.html#/2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment