Sugar Javascript

What is the difference between JavaScript and TypeScript?

Browsers do not support other languages ​​than JavaScript. Therefore, any language will be compiled into JavaScript. Remember, a few issues back we talked to you about wrappers ? So language is just a more convenient wrapper over some functionality. Different languages ​​offer different possibilities: it often comes down to modularity, typing, or features of other programming paradigms. For example:

• Dart offers us modularity and typing.
• Elm - functional programming and typing too.
• Clojure is just functional programming.
• CoffeeScript , hmmm ...

God forgive, those who invented CoffeeScript, they did not know what they were doing. However, the arrow functions from there in JavaScript still got. But we will not be in the merit of wrapping over classes because the words class and extends were reserved in the language long before the appearance of CoffeeScript.

Now let's see what TypeScript offers us. In TypeScript there is: modularity, typing and some features that were not in JavaScript. Dart offered the same thing, so why didn't he take off? And TypeScript is used in Angular versions 2 and 4, on which half the world is written.

The fact is that TypeScript uses an evolutionary approach. In order to start writing in TypeScript, you do not need to learn a new syntax. The creators of the language generally say that TypeScript is a superset of JavaScript. It turns out that any JavaScript will be a valid typeScript. Even those features that were not in JavaScript, they designed according to the ES2015 standard, with a reserve for the future, so that you do not need to rewrite the code.

How TypeScript became popular - clearly, now let's see what everyone is chasing after this typing, what does it give. The fact is that typing is in all programming languages, another thing is what it is. Typification is strong and weak.

JavaScript uses weak typing. This is when any value can be written in any variable.

 let anyVariable = 'It's a string'; anyVariable = ['No,', 'I've', 'changed', 'my', 'mind']; 

TypeScript uses strong or strong typing. With strong typing, when you create a variable, you must first say what type this variable will be. The same works for function parameters.

 let anyVariable: string = 'It's a string'; anyVariable = ['I', 'can't', 'do', 'this']; // Exception 

Proponents of strong typing cite two arguments in its favor:

1. Firstly, it is more efficient work with memory;
2. And secondly, it is the prevention of errors associated with type conversion.

Effective work with memory in the case of TS is irrelevant, because it will in any case be compiled into weakly typed JavaScript. But from some type conversion errors that occur in runtime, strong typing can really help.

Imagine that you are programming an online calculator. You have a text field, the user enters numbers there, you get a string value and pass the resulting string to a function that substitutes it in a mathematical formula.

 function getMonthlyIncome(val) { return val * 0.055 / 12; }; 

Weakly typed JS will skip this line in any form, even if it is not translated into a number. And as a result of such calculations, the user can get NaN rubles. In TypeScript, you will first have to translate this string into a number yourself, and then transfer it to the function in the proper form. And if you forget to do this, then you will see an error even at the stage of compiling your code.

 function getMonthlyIncome(val: number): number { return val * 0.055 / 12; }; 

It turns out that there are still some advantages in strict typing, but do not forget that TypeScript is not the only solution. In JavaScript itself, at the function level, you can add additional type checks. Yes, your code will be a bit more redundant, but do not forget that other languages ​​compile their type checking at about the same.

Facebook has a typing tool called Flow . It adds a type system similar to the OCaml language system in your JavaScript code. The Google Closure Library uses a clever typing mechanism based on JSDoc comments. In general, writing JSDoc comments, even without compilation and a clever type system, will help you solve some problems. First, you yourself will understand the interface of the functions that you write. And secondly, some editors who support JSDoc will tell you that you are not sending something in the wrong place .

Yes, and other programming languages ​​with strong typing, too. The same Elm - it will suit you much better if you have a functional approach closer to the object-oriented one.

In any case, remember: all these languages ​​and compilers make your project more difficult to maintain and configure, and the code does not become less. It turns out that in their direction you need to look only in the event that overhead costs are really worth it, for example, in large projects. If you make a small one-page landing page, where there is almost no JS and loading speed is important, then extra complexity can only hurt.

Video version

Questions can be asked here .