Sugar JavaScript

What is the difference between native JavaScript and TypeScript?

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

• Dart offers us modularity and typification.
• Elm - functional programming and also typing.
• Clojure is just functional programming.
• CoffeeScript , hmm ...

God forgive those who invented CoffeeScript, they did not know what they were doing. However, arrow functions from there did get into JavaScript. But the wrapper will not put their credit on classes, because the words classand extendshave been reserved in the language long before the appearance of CoffeeScript.

Now let's see what TypeScript offers us. TypeScript has: 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, which write half the world.

The fact is that TypeScript uses an evolutionary approach. In order to start writing in TypeScript, you do not need to learn new syntax. The creators of the language generally claim that TypeScript is a superset of JavaScript. It turns out that any JavaScript will be 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 it would not be necessary to rewrite the code.

How TypeScript became popular - it’s clear, now let's figure out why everyone is so chasing this typification, what it gives. The fact is that typing is in all programming languages, which is another matter. Typing is strong and weak.

JavaScript uses weak typing. This is when any value can be written to 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 thing 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 her favor:

1. Firstly, it is more efficient work with memory;
2. And secondly, it is preventing type conversion errors.

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

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

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

A weakly typed JS will skip this string in any form, even if it is not converted to a number. And as a result of such calculations, the user can get NaNrubles. In TypeScript, you have to first translate this string into a number yourself, and then pass 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 function level JavaScript itself, you can add additional type checks. Yes, your code will be a little more redundant, but do not forget that other languages ​​compile their type checks about the same.

Facebook has a typing tool called Flow . It adds a type system similar to the OCaml system to your JavaScript code. The Google Closure Library uses a tricky typing mechanism based on JSDoc comments . In general, writing JSDoc comments, even without a compilation and cunning type system, will help you solve some problems. First, you yourself will understand the interface of those functions that you write. And secondly, some editors that support JSDoc, will suggest to you that you have  something not pass somewhere not there .

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

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

Video version

Questions can be asked here .