Plaidoyer pour JavaScript Vanilla plutôt que les Frameworks

La plupart des projets frontend n’ont pas besoin de React. Ils n’ont pas besoin de Vue, Angular, ou de tout autre framework. Ils ont besoin de quelques centaines de lignes de JavaScript et d’un navigateur qui est devenu discrètement bien plus performant qu’il ne l’était il y a dix ans.

Ce n’est pas un argument nostalgique. C’est un rappel que le point de départ par défaut pour de nombreux projets peut encore être la plateforme elle-même.

Ce que signifie réellement « JavaScript Vanilla » en 2026

JavaScript Vanilla aujourd’hui est très différent de ce qu’il signifiait au début des années 2010. Le JavaScript moderne inclut les modules ES pour organiser le code, async/await pour gérer la logique asynchrone, et des fonctionnalités natives du navigateur qui nécessitaient autrefois plusieurs couches d’outillage et de bibliothèques.

Lorsque les développeurs parlent de « passer au vanilla », ils ne suggèrent pas d’abandonner la structure ou les pratiques modernes. Ils veulent dire travailler directement avec les capacités du navigateur au lieu de faire transiter chaque interaction par un runtime de framework.

Dans de nombreux cas, cette approche aboutit à une architecture plus simple, moins de dépendances, et un code qui reste compréhensible des années plus tard.

La plateforme web est plus performante que ce que nécessitent de nombreux projets

L’une des raisons pour lesquelles les frameworks sont devenus dominants est que la plateforme navigateur manquait autrefois de solutions aux problèmes frontend courants. Le routage, l’encapsulation des composants, l’observation du DOM et l’animation nécessitaient souvent des bibliothèques ou des abstractions personnalisées.

Aujourd’hui, le navigateur fournit bien plus nativement.

Les développeurs peuvent organiser le code en utilisant les modules ES et les import maps sans bundlers. Les Web Components permettent des éléments réutilisables et encapsulés qui fonctionnent dans tous les environnements. Des API comme Intersection Observer simplifient des tâches telles que le lazy loading et les comportements basés sur le défilement.

D’autres capacités plus récentes—comme les primitives de navigation modernes et les transitions de vue intégrées—continuent de réduire la quantité d’infrastructure nécessaire pour construire des interfaces interactives.

En d’autres termes, de nombreux problèmes qui justifiaient autrefois de gros frameworks ont désormais des solutions au niveau de la plateforme.

Où le développement sans framework fonctionne le mieux

Le développement frontend sans framework est particulièrement efficace dans les projets où l’interface est relativement simple et la logique applicative facile à comprendre.

Les exemples courants incluent :

• Sites marketing et de documentation — principalement du contenu statique avec des éléments interactifs légers

• Applications rendues côté serveur — où un framework backend produit déjà la majeure partie du HTML

• Widgets embarqués — où minimiser la taille du bundle et les dépendances externes est important

• Tableaux de bord et outils internes — où la simplicité et la maintenabilité l’emportent souvent sur la complexité architecturale

• Projets sensibles aux performances — où chaque kilo-octet de JavaScript affecte le temps de chargement et l’expérience utilisateur

La maintenance est également plus simple dans de nombreux cas. Les API du navigateur ont tendance à rester stables pendant des années, tandis que les écosystèmes de frameworks évoluent rapidement et nécessitent parfois un travail de migration important entre les versions.

Une méthode comme querySelector casse rarement. Les API de framework, en revanche, le font parfois.

Où les frameworks JavaScript ont toujours du sens

Tout cela ne signifie pas que les frameworks sont obsolètes. Ils résolvent de vrais problèmes.

Les applications hautement interactives—éditeurs collaboratifs, tableaux de bord de données complexes, ou grandes applications monopages avec des flux d’état sophistiqués—bénéficient souvent des modèles architecturaux fournis par les frameworks.

Les frameworks aident également les grandes équipes à maintenir la cohérence. Lorsque de nombreux développeurs contribuent à la même base de code, des conventions partagées pour la gestion d’état, la structure des composants et le routage peuvent réduire considérablement les frictions.

Dans ces environnements, la couche d’abstraction n’est pas seulement utile—elle peut être essentielle.

La question clé n’est pas de savoir si les frameworks sont bons ou mauvais. C’est de savoir si l’abstraction simplifie réellement le problème que vous essayez de résoudre.

Une heuristique de décision pratique

Avant d’ajouter une dépendance de framework, considérez la complexité de l’état de l’application.

Si l’interface peut être décrite avec un petit nombre de variables qui changent en réponse aux actions de l’utilisateur, du JavaScript simple et des mises à jour du DOM sont souvent suffisants.

Lorsque l’état devient profondément interconnecté—plusieurs régions de l’interface réagissant aux mêmes données, synchronisation complexe entre composants, ou mises à jour en temps réel à travers l’interface—les abstractions d’un framework commencent à porter leurs fruits.

Commencer avec la plateforme garde vos options ouvertes. Vous pouvez toujours introduire un framework plus tard si la complexité de l’application augmente.

Conclusion

La plateforme web moderne est performante, stable et bien documentée grâce à des ressources comme MDN. Pour de nombreux projets, le navigateur fournit déjà les primitives nécessaires pour construire des interfaces fiables.

Les frameworks restent des outils précieux, mais ils ne sont plus le point de départ automatique pour chaque projet frontend.

Dans un nombre surprenant de cas, une petite quantité de JavaScript bien structuré—et les capacités déjà intégrées dans le navigateur—peuvent vous mener bien plus loin que prévu.

FAQ

Complete picture for complete understanding

Capture every clue your frontend is leaving so you can instantly get to the root cause of any issue with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data.

Check our GitHub repo and join the thousands of developers in our community.