Why we chose TypeScript: a history of developers from Reddit

On the richness of choice and language requirements

1. BuckleScript
   
2. ClojureScript
   
3. CoffeeScript
   
4. Elm
   
5. ElixirScript
   
6. JavaScript 2016 and future language versions
   
7. JavaScript + annotations
   
8. Nim
   
9. Purescript
   
10. Reason
    
11. TypeScript
    

1. It must be a strongly typed language. Types, at the micro level, play the role of documentation. They help, to some extent, ensure the correctness of the code, and, more importantly, simplify refactoring. Another consideration that made us look for a strongly typed language was development speed. We tried to find a strongly typed language, because we wanted to speed up the work. Such an idea runs counter to the typification vision that many programmers have developed. Namely, it is generally accepted that this is an additional burden on the developer, which reduces the speed of work. However, increasing development speed also means increasing the likelihood of errors. We needed typing so that the code contained as few errors as possible, even if they were written quickly. Strong typing is also useful in fast-growing projects.
   
   
2. There must be good supporting tools . Given what we were planning to do (a serious redesign of the site), we did not have time to independently create a significant number of auxiliary tools. It was very important that we could get started quickly using ready-made open source solutions. More specifically, these are the specific tools in question. This is integration with popular build systems (for example, with Webpack), support for the linter, simple integration with test frameworks. If the integration of auxiliary systems for some language was not obvious, we no longer considered this language.
   
   
3. The language was to be used in serious projects . If the language looked good, but in reality was used only in small projects of individual enthusiasts, it could well be inappropriate for our task. In addition, if the language is not used in serious projects, questions arise about how long such a language will last, and how quickly the language developers will respond to messages about errors found in it.
   
   
4. Our developers must learn the language quickly enough . The above list has wonderful languages, the only negative of which is the too long time that developers need in order to master them. Among them, I would like to mention Elm and PureScript. We seriously discussed the issue of their use. However, in the end it turned out that their implementation would mean too much work necessary for the development of new programming concepts by developers who are not familiar with them, for them to reach a level that allows them to work productively on a project.
   
   
5. The language should work on both the client and the server . At Reddit, SEO is very important, so the lack of a universal system for delivering pages ready for display in the browser is a big problem.
   
   
6. Good library support . We were not going to write everything from scratch. There are some tasks that require reliable, time-tested libraries. We wanted us to have the opportunity to choose what we need from existing libraries.

Compilation or annotation?

enum VoteDirection {
  upvoted = 1,
  notvoted = 0,
  downvoted = -1,
};
const voteState: VoteDirection = VoteDirection.upvoted;

const voteDirections = {
  upvoted: 1,
  notvoted: 0,
  downvoted: -1,
};
type VoteDirection = $Keys;
const voteState: VoteDirection = voteDirections.upvoted;

Code Validation

class Animal {}
class Bird extends Animal {}
const foo: Array = [];
foo.push(new Animal());
/*
foo.push(new A);
        ^ A. This type is incompatible with
const foo: Array = [];
                ^ B
*/

class Animal {}
class Bird extends Animal {}
const foo: Array = [];
foo.push(new Animal()); // в typescript всё нормально