Let's multiply Object by a String and add an Array!
Said no sane developer ever.
Why not leave things as they are?
Once upon a time there was an App
. It was made of common App
building blocks. One of its important foundation stones was a UtilityBeltService
(let's call it Utils
). The Utils
had so many methods that it was hard even for old master App
builders to grab a proper one without a few minutes of reading its code. Many small type inconsistencies lurked in huge codebase. Disaster was only a matter of time…
One of the builders spent some time commenting all those methods with some odd annotations. But it only made Utils
look ugly and did not help too much. The App
said, it wanted to be clean and beautiful, to be developed agilely and smoothly.
The builders decided to send one of them to the dark wastelands of world wide web in search for The Solution. The chosen one spent several working hours in search of salvation and he brought back three magic books. They had to decide. And they decided. App
was to be happy again and not only Utils
would change…
The Solution: Type
What the builders thought they needed was static typing system for JavaScript.
To help them find bugs faster.
To make their code better.
Wait, but JS has types!
Yes. It has. But JS is dynamically typed. And it's dynamically typed with great elasticity - that's really useful in fast prototyping and simple one-job scripts. But when application grows this elasticity becomes real pain in the ass as type bugs come out in runtime or even after several months on production. And no, unit and e2e tests are not enough.
JavaScript uses coercion mechanism to deal with operations on vars of wrong types. For example "a" + 1
(which is adding String to Number) will go smoothly and return "a1"
(as a String). Here Number 1
is implicitly converted to a String to fit the operation. And that's how coertion works. It smoothly hides many little and nasty bugs!
Static Typing
Consider "a" + 1
expression. What if some kind of checker would test it before running application? It would say Hey! I can Add Strings or Add Numbers but I do not know how add a String to a Number? Aaargh…. And sane developer can decide now what he really needs. Maybe he wants to getCharCode("a") + 1
or "a" + String(1)
? The first one returns number 98
, the second one string "a1"
.
I'm sure that you remember all those JS tweaks related to coertion (and not only this). But I'm also sure that everyone makes mistakes. And few such mistakes in a huge codebase can make one spend several hours in chase of The Bug.
I have good news. Static typing can find it for you even without running an application :)
Statically Typed JavaScript
Of course it can be only some kind of fake static typing applied on top of JS in one or other way. Not a real thing.
There are three popular possibilities - jsDoc (with e.g. Google Closure Compiler), Facebook Flow and Microsoft TypeScript. First one uses comment like annotations - does not corrupt pure JS - while next two extend JS so they have to be transpiled. I will compare them briefly in a moment.
Before I start: this article does not touch AtScript as it left the scene in favour of TypeScript. Also I do not want to talk here about completely different languages compiled to JS like Elm, Dart, ScalaJS or anything similar. It's just about static type system for JavaScript (and maybe little more).
JsDoc
JsDoc is annotation-like comment system that brings some standarisation to describing code in comments (based on JavaDoc). It's easy to start, as you do not have to change your builds, tests, etc. - you can just add few comments here, few there and you have an inline documentation. Then it can be easily compiled to human readable docs by jsDoc tools. The most interesting part, is that you can:
define type of variable
define type of function argument
define type of function return
or even define new type
Then you can use proper tools to check code before a build. Or even use data type information about JavaScript variables to provide enhanced optimization with Google Closure Compiler. Nevertheless when using external libraries, you'll have to write definitions for them (see: @external). Also quite an issue is the fact that you have to add a lot of bloat to code - huge blocks of comments. It breaks the flow.
Flow
Facebook Flow is a static type checker, designed to find type errors in JavaScript programs. Actually it's a superset of JavaScript, which means that a valid JavaScript is also a valid Flow annotated JavaScript. But not the reverse. JS file, when annotated with flow, will not run in browser. But its file extension is still .js
. May be quite misleading, right?
What really shines in Flow, is that its type inference is designed in a way that helps a developer to gradually evolve JavaScript code into typed code and to easily mix statically and dynamically typed code. It is so forgiving that it makes transition to Flow almost totally painless. See five simple examples of Flow in action.
It also supports ES6 classes and destructuring, generic types, polymorphic classes, not concrete definitions (interfaces), .jsx
React files… and much more. All it makes Flow a mature static type checker. I'd go further then it's creators and call it a language.
TypeScript
Microsoft TypeScript is a typed superset of JavaScript that compiles to plain JavaScript. As with both previous type checkers, you can start with JavaScript files that you already have. Just change their extension to .ts
. I consider this a good idea, because TS code - same as with Flow - may not be a valid JS.
Converting bigger apps from JS may be a bit painful. TS uses implicit any
type (just like Flow) but its type inference is different (more strict?):
Flow
TypeScript
type is "dynamically" changed on reassignment
less (or none) errors for reassigned variables
painless conversion
variable assignment sets its type forever
more type errors for reassigned variables
safety
TypeScript can add some pain. But this is the cost of strict typing. The cost of safety!
It also supports ES6 classes, destructuring, generators, await, async, modules, ES7 decorators and reflection and also generic types, polymorphic classes, interfaces, enums, abstract classes, .tsx
that can be compiled to .jsx
React files)… …all that Flow does and much more.
All of these makes TypeScript a mature, strictly statically typed… language. Yes, even if it's the superset of JavaScript, it actually became something more than a type checker. It's rather a language - still quite similar to JS - that transpiles to JavaScript.
One more great feature is DefinitelyTyped - the library of interfaces and definitions for commonly used libraries.
Comparison
JsDoc
Pros:
no need to compile/transpile to real JS
the fastest conversion
can be used for optimization (compressing with GCC)
Cons:
more a documenting tool than a type checker
adds a lot of ugly bloat to code
really painful to use with external libraries
Flow
Pros
fast and painless conversion from JS
mature type system
not nullable types
developed by conscious team and community
support for some ES6 features
usable with React's
.jsx
Cons
forgiving type inference
same file extension as plain JS (chaos warning -
.js
-->.js
)painful use with external libraries see
is transpiled to JS
TypeScript
Pros
mature type system
strict type inference
most ES6 features
some ES7 features
different file extension (
.ts
-->.js
)DefinitelyTyped - easy use with most external libraries
possibly easy conversion from JS
support for React (
.tsx
-->.jsx
)
Cons
is transpiled to JS
in huge, complicated codebase conversion may be painful
Microsoft (but it is only emotional)
Conclusion
It's all just a mistification. JavaScript is dynamically typed language. All compared type systems are only a layer applied on top of real code. But that's ok because IT WORKS :)
For our projects at Evojam we have chosen TypeScript. It works fabulously in our environment because we love type safety, good code quality, strict rules and the newest technologies (ES6, ES7).
Angular team's decision to use TypeScript had not influenced us as we started to use TS a month before they announced their move. jsDoc was not even considered - it's too ugly. Flow is less strict and have less features - it may be a good conversion route (to TypeScript) for large systems with a really huge codebase.
The nice part is that Flow and TypeScript teams seem to learn from each other. It can make both of them even better.
Further reading:
some info on JavaScript’s Type System
real life use case: TypeScript vs Flow - investigation
another sane comparison: Statically typed JavaScript