I'm afraid I was careless. This is a good explanation. You can think of TypeScript as a programming language. The first thing to understand about TypeScript is that it is the work of anders hejlsberg. Anders is a first-class programming language designer and a first-class compiler implementer. As the father of Object Pascal and C#, Anders still adopted the previous approach this time: he designed a new language and implemented a compiler for this language to improve an existing language. But this time is different. Previously, the object codes compiled by Object Pascal and C# were all machine codes, and the object code of TypeScript was JavaScript. Of course, it is not necessary to regard the browser as a virtual machine and JavaScript as the object code running on this virtual machine. In a word, the source code written in TypeScript needs to be compiled by TypeScript compiler, and the generated target code is standard JavaScript. But this is not what makes TypeScript special in language design. There are two special things. TypeScript supports instant compilation, that is, you can get the corresponding JavaScript code immediately by writing a TypeScript, which is similar to CoffeeScript. But it supports stronger context deduction than CoffeeScript, and can generate corresponding and incomplete JavaScript code without complete statement writing. TypeScript is a superset of JavaScript. "Any legal JavaScript is a legal TypeScript." This design obviously draws lessons from the practice adopted by C++ in extending C, and its decision to be compatible with existing JavaScript codes paves a solid first step for many JavaScript programmers to transform into TypeScript-they can start from their existing codes and realize the benefits brought by TypeScript through bit by bit changes, and at the same time, they always reserve the right to say "enough" and then stop. It was not until the TypeScript technology was fully mastered that the code was written in TypeScript, and only the compiled results were used. In fact, the statement that "any legal JavaScript is a legal type script" is not accurate. The accurate statement is that "any legal ECMAScript 6 is a legal type script". Of course, ECMAScript 6 is still a language specification being revised, and any object code generated by TypeScript at this stage that may cause new features of ECMAScript 6 will adopt the backward-compatible ECMAScript 5 specification as the criterion. However, TypeScript does not guarantee to support every browser's extension of JavaScript. Introduction to TypeScript Features As mentioned earlier, TypeScript is designed as a superset of JavaScript or ECMAScript 6. In other words, just as the original goal of C++ is to be a "better C", TypeScript can also be regarded as a "better JavaScript", so what's so good about it? In fact, it is quite appropriate to use the relationship between C++ and C for analogy. TypeScript makes full use of the original object model of JavaScript and extends it, adding strict type checking mechanism, module support and API export ability. Compared with JavaScript, TypeScript provides more support at the language level, which enables programmers to express semantic constraints with more standardized syntax, thus reducing the probability of program errors. TypeScript also makes code organization and reuse more orderly, which makes a set of standard methods for developing large-scale Web applications. Extension of object model JavaScript supports a wide range of object models. Except null and undefined, almost all other entities can be regarded as objects. Even numeric values, character strings and Boolean types can use their corresponding wrappers implicitly, and can be directly used as objects in general occasions. Functions and arrays that are not regarded as objects in other programming languages are also regarded as "first-class objects" in JavaScript. In addition to using the entity itself, such as using numerical indexes or calling function bodies, you can also add properties and methods as ordinary objects. JavaScript objects can dynamically add properties and methods at any time, and modify and extend built-in objects. In a word, JavaScript provides a lot of facilities and practical tools for object operation, which constitutes a rich and flexible object model of JavaScript. TypeScript mainly extends the JavaScript object model from two aspects: one is the core language, and the other is the modeling of class concepts. Declarative semantics generally do not encounter problems when writing JavaScript code involving DOM objects in TypeScript. But this is not because TypeScript language knows something about DOM objects, but because TypeScript loads a declaration file named lib.d.ts by default, which contains all declarations of DOM objects by default. In other words, when you write this statement:, the compiler has actually implicitly added a sentence at the beginning: this statement is called an environment statement. TypeScript will try to analyze and deduce the type information of the object from the source of the declaration (such as the declaration library) when encountering the environmental declaration. If it cannot find any source, its default object type is any. However, the environment declaration will not add any statements to the generated JavaScript. In fact, all TypeScript declarations will not generate corresponding JavaScript statements, because the declarations in the JavaScript object model are optional. It can also be seen that TypeScript follows the philosophy of "Don't generate redundant statements unless necessary". However, in TypeScript, declarations not only play an important role in providing type information in advance, but also the compiler can complete powerful type deduction and accurate static type checking according to this information. The data in the data semantic type script needs a clear type. If it is set to a type, but an illegal value in that type is assigned to it, the static type checking mechanism will mark such a statement as an error. You can use the interface keyword to define the naming structure type, which is similar to defining JavaScript objects with literal quantity in JavaScript. The difference is that each component must specify the type in TypeScript, but the component can be optional, and the optional component can not be provided when the literal object is actually provided. Similarly, the data type definition of the interface and any static type declaration specified for the data in TypeScript will not be reflected in generating any JavaScript object code. For example, the JavaScript object code generated by the above code is only that the type of the function object is mainly determined by its signature, including the name, type and return value type of each parameter. It is worth noting that the return value of the function object can be void, which is the only place where the void type can appear, and its only possible value is undefined. The function in function semantics TypeScript not only adds static type checking to the function object model of JavaScript, reflecting the data aspect of the function, but also adds many new features to the nature of the function itself, such as the default parameter value of the function: it will generate the following JavaScript object code accordingly, from which it can be clearly seen that the logic of generating the code is carried out by judging whether the parameters are defined: TypeScript supports limited function overloading, why is it limited? Because general function overloading is based on the difference of function signature, when the function is actually called, it will be bound to a specific overloaded function according to the type of argument. The implementation mechanism behind it is mostly the so-called name mangling. But function overloading in TypeScript can't do this. It only supports overloading based on * * * *. No matter how many functions with the same name and different signatures are declared, it can only have one implementation, and this implementation must be meaningful to all overloaded versions. It may be puzzling to say so. Let's take an example: just look at the JavaScript object code generated by the TypeScript code above, and you will understand most of it. The reason is that TypeScript does not use the name recombination mechanism when implementing overloading, and JavaScript does not support overloading, so it can only make such a very big compromise. One of the most striking features of the function object in TypeScript is that it supports the so-called "arrow symbol", that is, Lamda expression. For example, the following three functions are equivalent: but the most important use of the arrow symbol is when a callback function is needed. One of the most common mistakes at this time is that the scope of this is not reserved in the local scope of the called function, but becomes the scope of the function caller. Let's look at it through an example: at this time, clicking on the page will pop up a warning box with the value of "NAN", which is obviously problematic. The problem here is that this refers to the scope of the function caller, and it has become a global scope, and the result is naturally wrong. At this time, as long as the arrow symbol is used, the problem is solved: this symbol was introduced by ECMAScript 6. Looking at the object code generated by TypeScript, we can see that it adopts a roundabout way to achieve the effect, while maintaining downward compatibility. The most important extension of TypeScript to JavaScript object model is naturally that it complements the concept of "class" that has not been introduced in JavaScript. Yes, there are no classes in JavaScript, only objects. To realize the so-called "classic operations", such as encapsulation and polymorphism, it needs to be completed through several infrastructures such as prototypes and constructors. These tasks may be possible for programmers who are very familiar with JavaScript, but they are difficult for novices. Moreover, even an expert can easily forget and make mistakes if he doesn't write relevant codes for a period of time. However, TypeScript provides a standard mechanism to map common class concepts familiar to ordinary programmers and commonly used in C++ and C# into JavaScript, which greatly reduces the difficulty of class operation in JavaScript. Because the related concepts are not difficult to understand, but there are many technical contents, so here are only a few key points. Firstly, the core semantics of class in TypeScript is summarized in one sentence: all classes are immediate functions, all data members are attributes of this function instance, all methods are attributes of this function prototype, and all static members are attributes of this function constructor. Take your positions. You can't go wrong. Just look at the JavaScript object code generated by this class. Suppose there is a Human class defined according to calculate length's salary as follows: The generated JavaScript object code is as follows: It is worth noting that TypeScript supports the so-called "accessor". Using accessors, functions can be encapsulated and exposed in the form of data attributes. For example, you can add an accessor to the above class to get the salary amount: the corresponding JavaScript code is complicated, and the browser needs to support ECMAScript 5 to run; The concept of module is introduced into code organization and refactoring type scripts, which is similar to namespaces in C++. It can encapsulate declarations, data, functions and classes in a module and export them with the export keyword for code outside the module to access. The reason why it is similar to namespace is that modules with the same name can be merged automatically and even stored in multiple files respectively. Second, because the names of modules can be divided into different levels, simplified aliases can be used when there are many levels. However, no matter how the modules are organized, the final generated JavaScript code is standard and can be accessed directly. With its modular and pluggable structure, TypeScript can provide complete support for widely used libraries such as jQuery, CommonJS and Node.js while maintaining a small language core. Because TypeScript does not use the rough way of string matching to export the names of variables and functions, the reconstruction of TypeScript code names is as easy as other programming languages of Microsoft. Just select the entity to be renamed and type a new name, without worrying that other entities with the same name but different meanings will be renamed at the same time. Summary TypeScript is the only fully compatible solution, and it is the superset of all the improvements in JavaScript today. In addition, TypeScript improves almost all aspects of the JavaScript object model. This paper only introduces some important technologies, and there are many details that readers need to explore themselves. Now the latest version of TypeScript is 0.8. 1, and the source code is all open. Interestingly, TypeScript itself is realized by TypeScript, and this recursive structure is also one of the favorite ways of compiler Daniel, because bjarne stroustrup also used C++ itself to write the C++ compiler. Familiarity with TypeScript source code and specifications will not only enable us to master this new language faster, but also give us a deeper understanding of how to use it to solve some more complicated problems, such as how to extend it to support JavaScript features provided by some specific browsers. In a word, TypeScript can be said to be one of the most promising JavaScript extensions or even alternatives, and friends interested in front-end technology should be familiar with it as soon as possible.