TypeScript vs JavaScript : différences clés avec exemples

TypeScript, c'est JavaScript avec un système de types statique ajouté par-dessus. Tout programme JavaScript est une syntaxe TypeScript valide ; TypeScript ajoute des annotations de type, un compilateur qui les vérifie avant l'exécution, et une étape de build qui les retire à nouveau. À l'exécution, il n'y a que du JavaScript : toute la différence tient à ce que vous découvrez avant de livrer.

type Product = { name: string; price: number };

function total(products: Product[]): number {
    return products.reduce((sum, p) => sum + p.price, 0);
}

const cart: Product[] = [
    { name: "Keyboard", price: 49 },
    { name: "Mouse", price: 25 },
];

console.log(total(cart)); // 74

En JavaScript, la même fonction est ce code sans type Product = ..., : Product[] ni : number. Les types apportent de l'information au compilateur et à l'éditeur ; ils ne changent pas ce que fait le programme.

TypeScript vs JavaScript en un coup d'œil

Le même code dans les deux langages

Voici une fonction en JavaScript. Rien n'y indique à quoi user doit ressembler :

function greeting(user) {
    return `Hello, ${user.firstName} ${user.lastName}`;
}

greeting({ firstname: "Ada", lastName: "Lovelace" });
// "Hello, undefined Lovelace", no error anywhere

La version TypeScript décrit la forme une seule fois, et la faute de frappe est signalée avant l'exécution :

interface User {
    firstName: string;
    lastName: string;
}

function greeting(user: User): string {
    return `Hello, ${user.firstName} ${user.lastName}`;
}

greeting({ firstname: "Ada", lastName: "Lovelace" });
// error TS2561: Object literal may only specify known properties,
// but 'firstname' does not exist in type 'User'. Did you mean to write 'firstName'?

Les annotations constituent toute la différence de syntaxe. TypeScript ajoute aussi quelques déclarations qui lui sont propres (interface, type, enum, des génériques comme Array<string>, des modificateurs d'accès comme private), mais les instructions, les opérateurs et les objets intégrés sont ceux de JavaScript.

Ce que TypeScript détecte et JavaScript non

JavaScript convertit les types en silence. Ce bug est fréquent avec les valeurs issues de champs de formulaire, qui sont toujours des chaînes. Exécutez le code pour voir ce que dit le compilateur :

// This does not compile: strings where numbers are expected.
function sum(values: number[]): number {
    return values.reduce((a, b) => a + b, 0);
}

const fromForm = ["10", "20", "5"];
console.log(sum(fromForm));

index.ts(7,17): error TS2345: Argument of type 'string[]' is not assignable to parameter of type 'number[]'.
  Type 'string' is not assignable to type 'number'.

En JavaScript, ce code s'exécute et affiche 010205, car 0 + "10" est une concaténation de chaînes. TypeScript refuse de compiler tant que les chaînes ne sont pas converties, par exemple avec fromForm.map(Number).

L'autre grande catégorie, ce sont les valeurs qui peuvent manquer. Array.prototype.find renvoie undefined quand rien ne correspond, et TypeScript vous oblige à traiter ce cas :

// This does not compile: find() can return undefined.
const users = [
    { id: 1, name: "Ada" },
    { id: 2, name: "Grace" },
];

const user = users.find((u) => u.id === 3);
console.log(user.name.toUpperCase());

index.ts(8,13): error TS18048: 'user' is possibly 'undefined'.

La version en JavaScript pur plante à l'exécution avec TypeError: Cannot read properties of undefined (reading 'name'). En TypeScript, la correction consiste à traiter le cas signalé par le compilateur :

const users = [
    { id: 1, name: "Ada" },
    { id: 2, name: "Grace" },
];

for (const id of [2, 3]) {
    const user = users.find((u) => u.id === id);
    if (user) {
        console.log(user.name.toUpperCase()); // user is narrowed to the object type here
    } else {
        console.log(`no user with id ${id}`);
    }
}

Sortie :

GRACE
no user with id 3

Ce que TypeScript ne détecte pas : les erreurs de logique (une formule fausse a le bon type), et tout ce qui concerne les données qui entrent dans le programme à l'exécution. Une réponse d'API typée User n'est correcte que si le serveur qui l'a envoyée l'est, car les types ont disparu une fois le code lancé. Vérifiez ces données avec du code exécuté à l'exécution.

Utiliser des bibliothèques JavaScript en TypeScript

Tous les paquets npm fonctionnent depuis TypeScript, puisque le résultat est de toute façon du JavaScript. Les types d'un paquet viennent de l'un de ces trois endroits :

• Le paquet fournit ses propres fichiers .d.ts. La plupart des paquets activement maintenus le font, et vous n'installez rien de plus.
• Un paquet @types séparé issu du projet communautaire DefinitelyTyped : npm install --save-dev @types/lodash ajoute les types de lodash.
• Nulle part. Dans ce cas, avec strict activé, l'import lui-même est une erreur :

error TS7016: Could not find a declaration file for module 'lodash'. '/project/node_modules/lodash/lodash.js' implicitly has an 'any' type.
  Try `npm i --save-dev @types/lodash` if it exists or add a new declaration (.d.ts) file containing `declare module 'lodash';`

La solution est d'installer le paquet @types s'il existe, ou de décrire vous-même le module dans un fichier .d.ts ; la page sur les fichiers de déclaration montre comment faire.

L'étape de build

Les navigateurs et Node.js ne vérifient pas les types, TypeScript a donc besoin d'une étape entre votre code source et le code exécuté. Il existe trois configurations courantes :

• tsc compile tout. Il vérifie les types et écrit les fichiers .js, en général dans un dossier dist. C'est simple, et c'est le standard pour les bibliothèques.
• Un bundler ou un serveur de développement retire les types, et tsc --noEmit les vérifie. Vite et esbuild retirent les types sans les vérifier, ce qui garde les rechargements rapides ; l'éditeur et une étape de CI lancent le vérificateur de types.
• Le runtime retire les types. Les versions actuelles de Node.js, Deno et Bun exécutent directement les fichiers .ts. Aucun d'eux ne vérifie les types pendant l'exécution, donc tsc --noEmit (ou deno check) reste le moyen de trouver les erreurs de type.

JavaScript n'a besoin de rien de tout cela, et c'est son plus grand avantage pratique pour les petits scripts. Le coût de l'étape TypeScript tient surtout à la configuration, un tsconfig.json et une dépendance de développement typescript, et au temps de compilation ; le compilateur natif de TypeScript 7 a divisé ce temps par environ dix sur les gros projets.

Courbe d'apprentissage

Tout ce que vous savez de JavaScript reste valable, car l'exécution de TypeScript, c'est JavaScript. La nouveauté est le système de types, qui s'apprend par couches :

1. Les annotations sur les variables, les paramètres et les valeurs de retour (: string, : number[]).
2. Les types objet avec interface et type, les propriétés optionnelles, les unions comme string | number.
3. Le narrowing : vérifier une valeur avec typeof, in ou === pour que le compilateur sache dans quel cas vous êtes.
4. Les génériques, les types utilitaires comme Partial<T> et Pick<T, K>, et les types avancés pour les auteurs de bibliothèques.

Les deux premières couches couvrent l'essentiel du code applicatif. Une grande partie du typage est inférée, si bien que beaucoup de code TypeScript ressemble à du JavaScript avec des annotations uniquement sur les signatures de fonctions.

Quand choisir TypeScript ou JavaScript

TypeScript est-il meilleur que JavaScript ? Pour du code maintenu par plusieurs personnes ou qui vit pendant des années, généralement oui, et l'industrie a pris cette direction : d'après le décompte des contributeurs mensuels de GitHub, TypeScript a dépassé JavaScript et Python en août 2025 pour devenir le langage le plus utilisé sur GitHub. Pour les petits scripts, JavaScript pur reste souvent le meilleur outil.

Choisissez TypeScript quand :

• Plus d'une personne travaille sur le code, ou qu'il sera maintenu pendant des mois ou des années.
• La base de code est assez grande pour que vous ne puissiez pas garder chaque signature de fonction en tête.
• Vous refactorez souvent : renommer une propriété met à jour chaque utilisation, et le compilateur liste ce qui reste.
• Vous publiez une bibliothèque : les fichiers .d.ts offrent à ses utilisateurs l'autocomplétion et les vérifications.
• Le framework l'attend. Les applications Angular sont écrites en TypeScript, Next.js et Astro génèrent les nouveaux projets en TypeScript par défaut, et les templates React, Vue et Svelte de Vite existent chacun en variante TypeScript.

Choisissez JavaScript quand :

• Le programme est un petit script, une expérience ponctuelle ou un extrait de code dans la console du navigateur.
• Vous apprenez la programmation pour la première fois et voulez moins de notions à la fois.
• Il n'y a pas d'étape de build et vous n'en voulez pas. Même dans ce cas, // @ts-check avec JSDoc vous apporte une part de vérification dans un simple fichier .js.

Migrer un projet JavaScript vers TypeScript

Une migration n'a pas besoin de se faire d'un coup. Le compilateur accepte JavaScript à côté de TypeScript :

{
    "compilerOptions": {
        "allowJs": true,
        "checkJs": false,
        "outDir": "dist",
        "rootDir": "src"
    },
    "include": ["src"]
}

Avec allowJs, les fichiers .js se compilent et peuvent importer depuis des fichiers .ts, et inversement. Convertissez ensuite progressivement :

1. Renommez un fichier de .js en .ts et corrigez les erreurs que le compilateur y signale.
2. Commencez par les feuilles (modules utilitaires avec peu d'imports), puis avancez vers le centre.
3. Activez checkJs, ou ajoutez // @ts-check en haut de certains fichiers .js, pour vérifier les types des fichiers que vous n'avez pas encore renommés.

Dans les fichiers JavaScript vérifiés, ce sont les commentaires JSDoc qui fournissent les types :

// @ts-check

/**
 * @param {number} price
 * @param {number} qty
 * @returns {number}
 */
function lineTotal(price, qty) {
    return price * qty;
}

lineTotal("3", 2);
// error TS2345: Argument of type 'string' is not assignable to parameter of type 'number'.

Certaines équipes s'arrêtent là : des fichiers JavaScript avec des types JSDoc, vérifiés par tsc, et aucune étape de build pour le code lui-même. D'autres vont jusqu'au .ts. Si vous activez strict dans un projet existant, attendez-vous à beaucoup d'erreurs au début ; la page sur le mode strict liste ce que vérifie chaque option pour que vous puissiez les activer une par une.