Why TypeScript exists?
Chapter 1: What is TypeScript
Chapters - Table of contents →
Before digging into how to use TypeScript, let's take a look at why it was created.
The growing complexity of the front-end stack
The complexity of front-ends drastically increased in the last 20 years; we went quickly from widgets to Single Page Applications.
Nowadays, applications deal with a lot of client-side data, hundred of components, and external libraries.
%20(1)%20(1).png)
From widgets to applications
The lack of well-established convention in the JavaScript community (unlike in Rails) and the dynamic typing issues made it hard to work on large-scale projects.
Example of typical "plain JavaScript" issues
The typo issues
Javascript syntax makes it easy to do typos, from the classic mistyped variable name to the missing or misplaced function argument.
Let's take a look at the example below. Can you spot the typo? 🔍
1// example of test data for a unit test
2// the data being an array of 3 elements:
3// 1. an object having a list of items
4// 2. an item id
5// 3. an expected value for the test assertion
6const testData = [
7 [{ items: [{ id: 1, value: 2, itemName: 'test' }, 1, 2] }],
8 [
9 { items: [{ id: 2, value: 2, itemName: 'test 2' }] },
10 1,
11 undefined,
12 ],
13]
14// this data is passed later to `describe.each()`
15In line 6, because of a misplaced comma, the test data item of the array is an array of one element, instead of 3.
Such a typo will make the test fail.
The proper shape of the test data should be the following (without the typo):
1// example of test data for a unit test
2// the data being an array of 3 elements:
3// 1. an object having a list of items
4// 2. an item id
5// 3. an expected value for the test assertion
6const testData = [
7 [
8 { items: [{ id: 1, value: 2, itemName: 'test' }, 1, 2] },
9 1,
10 2
11 ],
12 [
13 { items: [{ id: 2, value: 2, itemName: 'test 2' }] },
14 1,
15 undefined,
16 ],
17]
18// this data is passed later to `describe.each()`
19I faced this issue while writing tests for hours on a codebase in "plain JavaScript."
(In this scenario, TypeScript would have spotted the issue immediately.)
The dynamically typed JavaScript issues
A JavaScript variable can contain any type of data, JavaScript is dynamically typed, which means that the type of a variable is defined by the type of its data at runtime.
Since JavaScript is weakly typed, you can do “whatever you want” in your expression. This means that you don’t need to inform the compiler how to convert your values, for example :
1let a = 1;
2let b = "2";
3let c = a + b; // "12" -> c is a string
4c = a * b; // 2 -> c is a number
5The ECMA specification describes how implementations should behave based on values types during an operation (additive, etc.):
https://tc39.github.io/ecma262/#sec-additive-operators
This might look much simpler or cool than a * (int) b, however, this weak typing can introduce some weird type conversion.
Let's take a look at a - not so - trivial example:
1const sum = (a, b) => a + b;
2
3sum(1, "2") // "12" -> ??!?!?!
4While you might say that, because of its name (sum()), all values passed to this function are expected to be number.
However, such a scenario can quickly occur: example, getting the values to sum from a custom TextField component that stringifies the values.
In JavaScript, for the sake of usage, this issue is solved at the function that has to "protect" itself by adding type guards:
1const sum = (a, b) => parseInt(a, 10) + parseInt(b, 10);
2sum(1, "2") // 3
3Exploration of big projects
Finally, the biggest issue with JavaScript at scale is the exploration/navigation of the code.
Nowadays, any professional React application relies on external libraries exposing hundreds of components and functions and components developed internally for the product.
Big "plain JavaScript" projects require any developer to learn by heart all codebase and reach for the documentation every time it needs the exact signature of a function or component exposed by a required library - that might change often.
You might say that, nowadays, most IDE (ex: Visual Code) can successfully provide autocompletion and "click to definition" on "plain JavaScript codebase.
It is accurate and, at least for VS Code, thanks to TypeScript!
VSCode is relying on TypeScript that can infer type definition from "plain JavaScript" on the fly, helping to get more-or-less accurate autocompletion and "click to definition" for .js/.jsxfiles.
TypeScript at the rescue
All those issues led Microsoft, in 2010, to create a superset of JavaScript called TypeScript.
Publicly released in 2012, TypeScript brought JavaScript to another level of scalability and Developer Experience.
We use cookies to collect statistics through Google Analytics.