I. Background
2010 – Microsoft team starts development
2012 – First public version released (TypeScript 0.8)
2013 – TypeScript 0.9 released, supports generics
2014 – TypeScript 1.0 released, Visual Studio 2013 supports TypeScript by default. At the same time, source code migrated from CodePlex to Github
2017 – TypeScript 2.1 released
2018 – TypeScript 3.2 released
TypeScript was originally a Microsoft internal project, called Strada, dedicated to improving the reliability and maintainability of large JS projects (internal requirements at the time were Bing Maps, Office Web Apps and even Windows 8 apps). Development started in 2010, first open source version released in October 2012, continuously iterated to this day
II. Goals
Application scale JavaScript development is hard.
JavaScript was originally designed as a scripting language, lacking some basic features necessary for building large applications, such as:
-
Static types
-
Structuring mechanisms (classes, modules, interfaces, etc.)
Type defects cause many errors to be exposed only at runtime, on the other hand, lack of static types is also the main reason for poor JS editing experience, intelligent hints, auto-completion and other modern editing experiences all started from Visual Studio:
-
Type inference based intelligent hints
-
JSDoc based intelligent hints
-
TypeScript declaration file based intelligent hints
(Excerpted from JavaScript IntelliSense)
Application scale JavaScript development is hard, TypeScript makes it easier.
TypeScript expects to fill these defects through source code transpilation, add OOP support (Class, Interface, etc.) to JavaScript, and optional static type system, establish foundation for developing large JavaScript applications in ES5 era (2010)
In addition, TypeScript also brings an important thing to JavaScript, d.ts declaration files:
Working with existing JavaScript libraries, declaration file can be written and maintained separately.
Through independent declaration files let existing JavaScript libraries also have TypeScript's type advantages, took a big step forward in improving JavaScript editing experience
III. Positioning
TypeScript is a typed superset of JavaScript that compiles to plain JavaScript.
There are 3 key points:
-
typed: Typed. Added (optional) static types to JS
-
superset of JavaScript: Superset. Compatible with JS, supports mixing, existing JavaScript libraries can be used directly
-
compiles to plain JavaScript: Compiles to native JS. Starts from JavaScript, ends with JavaScript
Specifically:
-
Starts from JavaScript: Superset means all JavaScript code is TypeScript, syntax and semantics are consistent with JavaScript, copy and paste to get started
-
Provides optional static types, classes and modules: Types not only enable JavaScript development to use efficient development tools and practices (such as static checking and code refactoring), but also don't bring runtime performance overhead (static types only exist at compile time)
-
Ends with JavaScript: TypeScript compilation produces idiomatic native JavaScript, thus supports cutting-edge JavaScript features, and can run in any host environment supporting ES3+
Can consider TypeScript is syntactic sugar for JavaScript:
TypeScript is a syntactic sugar for JavaScript. TypeScript syntax is a superset of ECMAScript 2015 (ES2015) syntax. Every JavaScript program is also a TypeScript program.
(Excerpted from Introduction | TypeScript Language Specification)
Like type patches, can perfectly integrate with JavaScript world, this is where TypeScript's vitality lies:
Starts and ends with JavaScript, and optional static types, classes, modules.
And, this point hasn't changed from TypeScript public release (end of 2012) to present (early 2019)
IV. Design Principles
Pursues:
-
Statically identify parts that might be wrong
-
Provide structuring mechanisms for large code segments
-
Don't add runtime overhead to compiled products
-
Output clean, idiomatic, readable JavaScript code
-
Implement a composable, easy to reason about language
-
Always stay consistent with ES specifications
-
Preserve runtime behavior of all JavaScript code
-
Avoid adding expression-level syntax features
-
Consistent, completely erasable structural type system
-
Become cross-platform development tool
-
Don't introduce major breaking changes from TypeScript 1.0 onwards
Rejects:
-
Completely imitate existing language designs, should use JavaScript behavior and developer intentions as language design guide
-
Optimize program runtime performance, should faithfully output native JavaScript code, without deliberate optimization
-
Perfect or "provably correct" type system, should balance between correctness and productivity
-
Provide end-to-end (closed) build pipeline, should make system extensible, let compiler apply to more complex build workflows
-
Add or depend on runtime type information, or generate different code based on type system results, should encourage programming patterns that don't depend on run-time metadata
-
Provide additional runtime functionality or libraries, should use TypeScript to describe existing libraries
-
Introduce behaviors that might surprise users, should appropriately consider patterns adopted by other commonly used languages
V. Features
Type System
-
Is formalization of JavaScript types: Static representation of JavaScript type dynamic system
-
Provides type inference and structural typing: Actually don't need to annotate all types (type inference can solve part of it)
-
Can work with existing JavaScript libraries: Declaration files can be written and maintained independently
-
Is not provably type safe: Types only reflect intentions, don't provide guarantees
Most importantly, static types only exist at compile time:
In the JavaScript output, all type annotations have been erased.
For example:
// TypeScript
function f(s: string) {
return s;
}
// Compiled JavaScript, type annotations all erased
function f(s) {
return s;
}
Additionally, although TypeScript provides static type system, and strictly checks at compile time, but not provable, reasonable like [Haskell type system](/articles/类型-haskell 笔记 3/). Therefore, TypeScript type system is more like just a static type patch for JavaScript, like comments reflecting "intentions", doesn't guarantee safety
Even compilation errors don't block code generation, type check errors are just reminders that there might be problems here:
You can use TypeScript even if there are errors in your code. But in this case, TypeScript is warning that your code will likely not run as expected.
Classes and Modules
-
Scalable application structuring mechanism: Classes, modules and interfaces support defining clear connections between components
-
Follows latest standards: Classes, modules and arrow function syntax are all consistent with ES6 standards
-
Also supports industry mainstream module systems: Such as CommonJS and AMD modules
Note, module syntax rules are consistent with ES standards, but there are differences in loading mechanisms, see Module Resolution for details
VI. Ecosystem
-
(Open source) Compiler: typescript
-
Tools: IDE support (VS, VSCode, Sublime, WebStorm, Vim, etc.), Playground
-
Type libraries: DefinitelyTyped
-
Specifications: TypeScript Language Specification
-
Boilerplate projects: Samples, Community Samples
-
Cases: GitHub TypeScript Projects (including Angular, ant-design, etc.)
References
-
Anders Hejlsberg: Introducing TypeScript: TypeScript public release speech
-
TypeScript: PPT corresponding to above speech
No comments yet. Be the first to share your thoughts.