Le CSS-in-JS, c’est une façon d’écrire ton style directement dans ton code JavaScript, sans jamais toucher à un fichier .css séparé. Au lieu d’avoir un fichier styles.css d’un côté et ton composant React de l’autre, tu mets les deux ensemble. Le style vit là où il est utilisé.
Au premier abord, ça semble bizarre. On t’a toujours dit de séparer le HTML, le CSS et le JavaScript. Et là quelqu’un arrive et dit « mets tout dans le même fichier ». Mais il y a de bonnes raisons derrière ça. On va tout t’expliquer simplement.
Pourquoi le CSS classique pose problème dans les grosses applis ?
Dans un petit site, un fichier CSS global ça marche bien. Dans une grosse application avec des dizaines de composants, ça devient vite le chaos.
Imagine : tu travailles sur une appli React avec 50 composants. Tu as un fichier styles.css qui fait 3000 lignes. Tu veux modifier la couleur d’un bouton dans le composant UserCard. Tu cherches la règle CSS. Tu la modifies. Et là… un bouton dans une autre page change aussi de couleur. Pourquoi ? Parce que le CSS est global par défaut.
C’est le problème numéro un du CSS traditionnel : les styles se marchent dessus. Une classe .btn définie quelque part peut écraser une autre classe .btn définie ailleurs. Plus l’appli grandit, plus c’est le bazar.
Le CSS-in-JS règle ce problème à la racine. Chaque composant possède son propre style, isolé du reste. Impossible pour un style d’en écraser un autre par accident.
Comment fonctionne concrètement le CSS-in-JS ?
Le CSS-in-JS utilise JavaScript pour générer du CSS à la volée, souvent avec des classes aléatoires uniques pour garantir l’isolation des styles.
La bibliothèque la plus connue pour ça s’appelle Styled Components. Voilà un exemple très simple :
import styled from 'styled-components';
// On crée un bouton stylisé
const MonBouton = styled.button`
background-color: #00ff88;
color: #000;
padding: 10px 20px;
border: none;
border-radius: 8px;
cursor: pointer;
`;
// On l'utilise comme un composant React normal
function App() {
return <MonBouton>Clique ici</MonBouton>;
}
Ce que fait Styled Components en coulisses : il génère une classe CSS unique du style .sc-abc123 et l’injecte dans le DOM. Impossible qu’elle entre en conflit avec une autre classe.
Et le truc vraiment puissant : tu peux utiliser des variables JavaScript dans ton CSS. Par exemple, changer la couleur d’un bouton selon une prop :
const MonBouton = styled.button`
background-color: ${props => props.primaire ? '#00ff88' : '#333'};
`;
// Utilisation
<MonBouton primaire>Bouton vert</MonBouton>
<MonBouton>Bouton gris</MonBouton>
Avec du CSS classique, tu aurais dû créer deux classes séparées. Là, c’est dynamique et ça vit dans le composant.
Quelles sont les principales bibliothèques CSS-in-JS en 2026 ?
Il existe plusieurs outils pour faire du CSS-in-JS, chacun avec ses forces et son approche. Voilà un comparatif rapide des plus utilisés :
| Bibliothèque | Style d’écriture | Point fort |
|---|---|---|
| Styled Components | Template literals | Très lisible, populaire |
| Emotion | CSS ou objet JS | Flexible, très performant |
| Vanilla Extract | TypeScript pur | Zero runtime, type-safe |
| Stitches | Objet JS avec thème | Système de design intégré |
En 2026, Emotion et Styled Components restent les plus utilisés dans les projets React. Vanilla Extract gagne du terrain pour les projets TypeScript sérieux parce qu’il génère du CSS statique à la compilation, sans code JavaScript au runtime.
Si tu veux aller plus loin côté frameworks, jette un oeil à notre article sur Next.js qui est souvent utilisé avec ces bibliothèques dans les projets pros.
CSS-in-JS vs Tailwind : c’est quoi la différence ?
Tailwind et le CSS-in-JS résolvent le même problème (éviter les conflits de styles) mais avec des approches radicalement différentes.
Avec Tailwind CSS, tu appliques des classes utilitaires prédéfinies directement dans ton HTML :
<button class="bg-green-400 text-black px-5 py-2 rounded-lg">
Clique ici
</button>
Avec le CSS-in-JS (Styled Components par exemple), tu crées un composant stylisé et tu écris du vrai CSS dedans. Le style est encapsulé dans le JavaScript.
Tailwind est plus rapide à écrire au quotidien. Le CSS-in-JS est plus puissant quand tes styles dépendent de logique dynamique. Les deux ont leur place. Beaucoup de projets utilisent même les deux en même temps.
Quels sont les avantages du CSS-in-JS ?
Le CSS-in-JS apporte des bénéfices concrets que tu vas ressentir dès que tu travailles sur un projet avec plusieurs composants.
- Isolation totale des styles : chaque composant a ses styles. Aucun risque de conflit avec le reste de l’appli.
- Styles dynamiques : tu peux changer le style selon les props, le state ou n’importe quelle variable JavaScript.
- Suppression automatique des styles inutilisés : si tu supprimes un composant, son CSS disparaît avec lui. Fini les fichiers CSS qui grossissent pour rien.
- Thèmes faciles : créer un dark mode ou plusieurs thèmes devient simple quand le CSS vit dans JavaScript.
- Co-location : le style et la logique sont au même endroit. Ton code est plus facile à comprendre et à maintenir.
Quels sont les inconvénients du CSS-in-JS ?
Le CSS-in-JS n’est pas parfait. Avant de l’adopter, il faut connaître ses limites.
- Performance runtime : la plupart des bibliothèques génèrent le CSS en JavaScript côté client. Ça prend du temps CPU et peut ralentir le rendu, surtout sur mobile.
- Courbe d’apprentissage : si tu débutes avec React, ajouter une couche CSS-in-JS peut compliquer les choses.
- Compatibilité SSR : faire du CSS-in-JS avec le rendu côté serveur (SSR) demande une configuration supplémentaire. Ce n’est pas automatique.
- Taille du bundle : tu ajoutes une bibliothèque JavaScript de plus. Styled Components fait environ 12 Ko minifié. Ce n’est pas énorme, mais ça s’additionne.
C’est pour ça que des alternatives « zero runtime » comme Vanilla Extract ou Tailwind CSS ont le vent en poupe en 2026. Elles évitent le problème de performance.
Dois-tu apprendre le CSS-in-JS quand tu démarres ?
Non, le CSS-in-JS n’est pas une priorité absolue quand tu apprends le développement web.
Si tu démarres, concentre-toi d’abord sur le CSS classique, puis Flexbox et CSS Grid pour la mise en page. Ce sont des fondations indispensables que tu utiliseras toujours.
Le CSS-in-JS devient pertinent quand tu commences à travailler avec React ou Vue.js sur des projets de taille moyenne à grande. À ce moment-là, tu vas vite sentir la douleur des conflits de classes CSS globales. Et c’est là que Styled Components ou Emotion vont te sauver.
Si tu es développeur freelance ou en équipe, c’est une compétence qui fait la différence. Beaucoup d’offres d’emploi mentionnent Styled Components ou Emotion dans les prérequis pour les postes React.
En résumé : le CSS-in-JS
Le CSS-in-JS, c’est une approche moderne qui consiste à écrire tes styles directement dans JavaScript, au plus près de tes composants. Ça règle le problème classique des styles globaux qui se marchent dessus. Les bibliothèques comme Styled Components ou Emotion sont les plus utilisées. Les alternatives zero runtime comme Vanilla Extract gagnent du terrain pour les performances. Ce n’est pas une techno à apprendre en priorité quand tu démarres, mais c’est indispensable dès que tu travailles sérieusement avec React sur des projets complexes.
Questions fréquentes sur le CSS-in-JS
Le CSS-in-JS est-il fait pour les débutants ?
Pas vraiment au tout début. Si tu apprends le développement web, commence par maîtriser le CSS classique, Flexbox et Grid. Le CSS-in-JS devient utile et pertinent quand tu travailles avec React sur des projets avec plusieurs composants réutilisables.
Styled Components ou Emotion, lequel choisir ?
Les deux sont excellents. Styled Components est légèrement plus lisible et plus populaire dans la communauté. Emotion est un peu plus flexible et légèrement plus performant. Si tu hésites, commence par Styled Components. La syntaxe est très proche et tu pourras passer à Emotion facilement si besoin.
Le CSS-in-JS fonctionne-t-il avec Vue.js ?
Oui, mais c’est moins courant qu’avec React. Vue.js possède déjà son propre système de styles scopés avec les Single File Components (balise <style scoped>). Le résultat est similaire au CSS-in-JS. C’est pourquoi on utilise moins de bibliothèques CSS-in-JS dans l’écosystème Vue.
Est-ce que le CSS-in-JS impacte vraiment les performances ?
Oui, mais c’est nuancé. Les bibliothèques runtime comme Styled Components ajoutent un léger coût en CPU pour générer le CSS à chaque rendu. Sur les petits projets, c’est négligeable. Sur des applis très larges avec des milliers de composants, ça peut se ressentir. C’est pourquoi les solutions zero runtime (Vanilla Extract, Linaria) existent et sont recommandées pour les projets très sensibles à la performance.
Peut-on utiliser le CSS-in-JS avec TypeScript ?
Absolument, et c’est même recommandé. Styled Components et Emotion ont tous les deux un excellent support TypeScript. Tu peux typer tes props de style, ce qui évite les erreurs et améliore l’autocomplétion dans ton éditeur. Vanilla Extract va encore plus loin : il est entièrement conçu autour de TypeScript.
Le CSS-in-JS va-t-il remplacer Tailwind CSS ?
Non, les deux coexistent et répondent à des besoins légèrement différents. Tailwind est très rapide à écrire pour des styles statiques. Le CSS-in-JS excelle quand les styles sont dynamiques et dépendent de la logique de l’application. Beaucoup de projets en 2026 utilisent les deux en parallèle selon les besoins.