String vs string en TypeScript : lequel choisir pour la performance ?

String vs string : le tueur silencieux des performances de votre code

Vous êtes-vous déjà demandé pourquoi TypeScript vous signale une erreur avec String à un endroit, mais pas avec string à un autre ? Ou peut-être avez-vous vu des développeurs expérimentés grimacer en voyant new String("bonjour") ? Cette question est un véritable phénomène sur Stack Overflow, cumulant des milliers de vues. Et pour cause. La différence entre String et string n'est pas une simple bizarrerie du langage, mais une distinction fondamentale qui impacte la performance, la sécurité et la lisibilité de votre code.

Dans cet article, nous n'allons pas nous contenter d'une définition sèche. Nous allons décortiquer ce qui se cache derrière chacun de ces types, leur comportement à l'exécution et pourquoi un choix judicieux peut accélérer votre application de plusieurs dizaines de pourcents. Accrochez-vous, ça va être passionnant !

Primitifs vs Objets : les bases fondamentales

Pour comprendre la différence, il faut revenir sur la façon dont JavaScript (et donc TypeScript) gère les données. Le langage distingue deux types de valeurs :

\n
• Les primitifs (primitives) : string, number, boolean, null, undefined, symbol, bigint. Ils sont immuables et stockés par valeur.
\n
• Les objets (objects) : Object, Array, Function, ainsi que String (avec une majuscule), Number, Boolean. Ils sont mutables et stockés par référence.
\n

Lorsque vous écrivez let nom: string = "Alice", vous créez un primitif. Lorsque vous écrivez let nom: String = new String("Alice"), vous créez un objet wrapper. Et c'est là que les choses deviennent intéressantes.

Le type string (en minuscule)

C'est le type primitif. Il est utilisé dans 99,9 % des cas. Il est léger, rapide et prévisible. La comparaison de deux primitifs se fait par valeur :

let a: string = "bonjour";\nlet b: string = "bonjour";\nconsole.log(a === b); // true

TypeScript recommande de l'utiliser. C'est le standard de facto pour déclarer des variables de type chaîne, des paramètres de fonctions et des valeurs de retour.

Le type String (avec une majuscule)

C'est le type objet, un constructeur wrapper. Il existe depuis les débuts de JavaScript pour permettre l'utilisation de méthodes sur les chaînes. Cependant, son utilisation directe est généralement considérée comme un anti-pattern, sauf cas très spécifique. La comparaison de deux objets String se fait par référence :

let a: String = new String("bonjour");\nlet b: String = new String("bonjour");\nconsole.log(a === b); // false ! Ce sont deux objets différents en mémoire

Cela peut entraîner des bugs difficiles à détecter. Imaginez vérifier si une chaîne vaut "bonjour" et obtenir false simplement parce que quelqu'un a utilisé new String().

Performance : pourquoi string est le grand gagnant ?

Passons maintenant au cœur du sujet : les chiffres et l'optimisation. Écrivons un simple test de performance (vous pouvez l'exécuter dans votre environnement, par exemple Node.js ou un navigateur).

// Test de performance\nconst iterations = 1_000_000;\n\nconsole.time("string (primitif)");\nlet somme = "";\nfor (let i = 0; i < iterations; i++) {\n    somme += "a";\n}\nconsole.timeEnd("string (primitif)");\n\nconsole.time("String (objet)");\nlet sommeObj = new String("");\nfor (let i = 0; i < iterations; i++) {\n    sommeObj += "a"; // Auto-boxing et unboxing se produisent ici\n}\nconsole.timeEnd("String (objet)");

Le résultat sur une machine standard sera radicalement différent (le primitif est 2 à 5 fois plus rapide). Pourquoi ? Parce que :

\n
• Le primitif string est simplement une séquence de caractères en mémoire. Les opérations sont optimisées au niveau du moteur JavaScript.
\n
• L'objet String nécessite une allocation mémoire supplémentaire et des conversions automatiques (auto-boxing/unboxing) à chaque opération, ce qui ralentit considérablement l'exécution.
\n