So, did TypeScript’s emergence and explosion happen by accident? No. It was inevitable that a statically-typed language like TypeScript would become mainstream. Why?
Let’s start by thinking about the question: what are types?
Types are basic types such as number, boolean, string, and composite types such as Object and Function, which are abstractions of different things provided by a programming language:
Different types of variables occupy different amounts of memory: a boolean variable allocates 4 bytes of memory, while a number variable allocates 8 bytes, and declaring a variable of a different type means that it occupies different amounts of memory.
Different types of variables can do different operations: number type can do addition, subtraction, multiplication, division and other operations, boolean can not, composite types of different types of objects available in different ways, such as Date and RegExp, the type of variable on behalf of the variable can do different operations.
We know what a type is, so it’s natural to think that the type and the operation being done have to match in order for it to work, which is why type checking is done.
If you can guarantee that you will only do the operations on a type that are allowed by that type, this is called . For example, if you do addition, subtraction, multiplication, and division on a boolean, that’s type-unsafe, and if you call the exec method on a Date object, that’s type-unsafe. If you call exec on a Date object, that’s type-unsafe.
So, type checking is for type safety.
Type checking can be done at runtime or at compile time before running. These are two different types; the former is called dynamic type checking and the latter is called static type checking.
There are advantages and disadvantages to both types of checking.The type information is not retained in the source code, so it is permissible to assign any value to a variable and do any operation on it, which makes the code very flexible. However, this also creates hidden dangers of type insecurity, such as multiplying or dividing a string, or calling exec on a Date object, which can only be detected at runtime.
Among them, the most common errors would be “null is not an object”, “undefined is not a function” and so on. When writing code, you don’t realize the type mismatch, and only find it when you run it. When you write the code, you don’t realize the type mismatch, but when you run it, you get a lot of these errors.
So, although dynamic types are easy to write in code, it is easy to hide some hidden dangers of type mismatch in the code.
On the other hand, type information is preserved in the source code, variables are declared to specify the type, and operations done on the variables have to match the type, and there will be a special compiler to do the checking during compilation.
Static types add some difficulty to writing code because you have to think about the type logic in addition to the logic the code is trying to express: what type the variable is, whether it matches, whether you want to do a type conversion, and so on.
However, static typing also eliminates the potential for type insecurity because type checking is done during compilation, so there are no problems with multiplying and dividing strings and calling the exec method of a Date.
So, static types, although the code is a little more complicated to write and consider, eliminate the possibility of type insecurity lurking in the code.
Knowing the difference between dynamic and static type checking, we can naturally conclude that:
Dynamic types are only suitable for simple scenarios, but not so suitable for large projects, because there are too many hidden dangers that can be hidden in the code, and in case a type mismatch error is reported on the line, it can be a big problem.
Static types, on the other hand, increase the cost of writing code, but they better ensure code robustness and reduce the bug rate.
Therefore, large projects are destined to be developed in statically typed languages.
JavaScript was originally designed for browser form validation, so it was designed to be dynamically typed and easier to write code.
But JavaScript also did not expect that it would later be used to develop a variety of projects, such as PC and mobile web pages, React Native cross-end App, applets, Electron desktop, Node.js server, Node.js toolchain and so on.
When developing large-scale projects, the shortcomings of JavaScript’s dynamically-typed language are exposed, the bug rate is too high, and robustness is hard to guarantee. Naturally, there was a strong demand for static typing, and TypeScript was developed.
TypeScript adds a static type system to JavaScript, changing it from a dynamically typed language to a statically typed language that can do type checking during compilation to catch some type safety issues in advance.
And, because of the addition of static types to the code, it’s also possible to work with the editor for better hinting, refactoring, etc., which is an added benefit.
So is the explosion of TypeScript a coincidence? No, I think it was inevitable, because large projects are destined to be developed in statically typed languages.