This repository was archived by the owner on Nov 27, 2018. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 9
Typescript
Ibon Tolosana edited this page Feb 13, 2015
·
2 revisions
It may seem strange to bet on Typescript nowadays when Javascript is omni-present and more powerful than ever. From my own experience managing large scale projects with hundred of thousands of LOC I know how important a compiler can be. While writing some several-tens-of-Javascript-LOC projects, I have learnt, mostly the hard way that the runtime is not the desired scenario for error checking. So here are some real-world reasons why we decided to go in Typescript
- First, typescript is currently very mature. Version 1.4 has brought some missing must-be features like union types and typedefs.
- It is very lightweight. The transpilation process, from Typescript to Typescript, takes a couple seconds for an already 25K LOC codebase. The overhead for the generate code is zero, except for the __extends function. Basically, the type information is removed, and your are done.
- You know Javascript, then you know typescript.
- ES6. Brings in many ES6 features which impose a common way of doing platform core code like inheritance.
- For performance reasons, we expect the Javascript VM to do some type inference on our behalf. Typescript enforces this type checking at compile time, not runtime which will prevent de-optimizations, optimization bail outs, and runtime errors.
- Generates Javascript VM-friendly code which will enforce the use of hidden classes and optimized code where available.
- Bonus track: great IDE integration which allows for code refactoring and code semantic structure recognition.
The final outcome of Typescript is that you developers can decide whether to build on Typescript, Javascript, or a mix of both.