A list of findings after experimenting with TypeScript

TypeScript TypeScript (TS) is a language that promises "JavaScript that scales". After running a number of investigationary projects, TS has been found lacking for a number of reasons that can be summarised in the following categories. 1. Configuration 2. Permissiveness 3. Strict mode 4. Lock-in 5. Progressive inclusion … # Permissiveness Without `strict mode`, TS will allow a large number of type unsafe actions to occur, giving the user the feeling of writing solid code and perhaps forgoing unit tests under the assumption the type system will save them. Examples of what is allowed by the compiler without strict mode include - Implicit `any` - Implicit use of `this` - No checking of `null` or `undefined` - No checking that properties are initialised - No checking on function types. … # Strict mode A strict mode exists to solve all these problems, however it comes with its own problems. It often results in unhelpful error reporting and as it combines type checking with TS Lint passesing, can often waste the developers time in a loop that can only be solved by writing code in an unreasonable way or configuration. … ### Strict mode: Compiler error messages are unhelpful An example using `Styled-Components` is given. When using this library and writing CSS within a template literal, a mistake will force the compiler to fail. … #### Strict mode: Unhelpful tooling The tooling can occasionally fail to watch files, or have conflicts between the TS compiler running the terminal and the linting happening within the editor. Since strict mode requires everything to be in order to compile at all, this can lead to frustations. In addition, the tooling never suggests *how* to type somethng, as ReasonML and Flow often do. This leads to the developer having to hunt down typings for things like React events by herself.