On me pose la question presque chaque semaine, en commentaire ou en MP : « Je veux faire mon premier site, je prends quel framework JavaScript ? » Et à chaque fois, la personne a déjà la tête pleine de noms — React, Vue, Angular, Svelte, Next, Nuxt — sans savoir que la moitié de ces noms ne sont pas des frameworks, et que l'autre moitié est probablement inutile pour son projet.
Alors plutôt que de vous sortir le classement habituel, je vais faire l'inverse : commencer par vous dire quand vous n'avez pas besoin de framework du tout. Parce que c'est la réponse honnête dans une bonne moitié des cas que je vois passer.
Points clés à retenir
- React et Vue sont des bibliothèques, pas des frameworks — la nuance change votre façon d'apprendre.
- Node.js n'est pas un framework : c'est un environnement d'exécution JavaScript côté serveur.
- Pour un site vitrine de 5 pages, HTML/CSS/JS suffit. Vraiment.
- Le vrai prérequis avant tout framework : maîtriser le JavaScript moderne (ES6, DOM, asynchrone).
- Le piège n°1 du débutant n'est pas le mauvais choix, c'est le tooling installé trop tôt.
- Choisir selon le type de projet (SPA, site statique, rendu serveur) plutôt que selon la hype.
Choisir un framework JavaScript pour son premier site : la question à se poser avant toutes les autres
Voici le test que j'aurais aimé qu'on me fasse passer il y a quelques années, quand j'ai monté mon premier projet sérieux avec un bundler que je ne comprenais pas : est-ce que votre site change de contenu sans recharger la page ?
Si la réponse est non — un site vitrine, un portfolio, une page de présentation d'association — vous n'avez pas besoin de framework. Un fichier HTML, une feuille de style, une poignée de lignes de JS pour le menu mobile. Le navigateur fait déjà 90 % du travail.
Le JS « vanilla » est-il vraiment dépassé ?
Non, et c'est probablement l'avis le plus tranché que je vais donner ici : pour un premier site, le vanilla est souvent le meilleur choix pédagogique. Vous allez comprendre ce qu'est le DOM, ce qu'est un événement, comment une requête part et revient. Ces notions, vous les retrouverez partout ensuite.
J'ai fait l'erreur inverse sur mon deuxième projet. J'ai installé React dès le premier jour, copié un boilerplate, et passé une semaine à déboguer une configuration de build dont je ne comprenais pas la moitié. Résultat : zéro ligne de logique métier écrite, et une bonne dose de frustration. Le projet est mort comme ça.
Quand un framework se justifie vraiment
Il devient pertinent quand l'interface a un état qui bouge beaucoup : un panier, un tableau de bord, un formulaire multi-étapes, une liste filtrée en direct. Là, gérer le DOM à la main devient vite pénible, et vous allez réécrire les mêmes fonctions de mise à jour.
Le seuil, dans mon expérience, tourne autour de quelques écrans interactifs. En dessous, framework = surcoût. Au-dessus, framework = soulagement.
Framework ou bibliothèque : la distinction que tout le monde zappe
Cette confusion explique la moitié des questions qu'on me pose. Un framework impose la structure de votre code : il appelle votre code à des moments qu'il décide. Une bibliothèque, c'est l'inverse : vous l'appelez quand vous en avez besoin, et elle ne s'occupe pas du reste.
| Outil | Nature | Ce que ça implique |
|---|---|---|
| React | Bibliothèque d'interface | Vous choisissez le routeur, le state, le build |
| Vue | Framework progressif | Peut s'ajouter à une page existante, ou tout structurer |
| Angular | Framework complet | Structure imposée, opinionné, courbe plus raide |
| Svelte | Compilateur | Le framework disparaît au build, sortie JS minimal |
| Node.js | Environnement d'exécution | Ni framework, ni bibliothèque : il exécute du JS hors navigateur |
Vous voyez le problème ? React ne vous donne pas de routeur. Vous allez devoir en choisir un, puis un outil de state management, puis un bundler. Ce sont trois décisions de plus quand vous débutez. Ce n'est pas rédhibitoire, mais autant le savoir avant de signer.
Les questions qu'on me pose tout le temps
Autant les traiter franchement, parce que derrière chacune se cache une incompréhension qui bloque des débutants pendant des semaines.
Quel est le meilleur framework frontend ?
Il n'y en a pas : il y a celui qui correspond à votre projet et à votre niveau. Pour un premier site, Vue est souvent le meilleur compromis — documentation très pédagogique, adoption progressive possible sans tout réécrire, et un écosystème officiel qui évite de choisir dix outils soi-même. React reste le plus demandé sur le marché de l'emploi, donc si votre objectif est de décrocher un poste, c'est lui qu'il faut viser. Svelte est le plus agréable à écrire, à mon goût, mais l'écosystème est plus restreint.
Est-ce que Node.js est un framework ?
Non. Node.js est un environnement d'exécution : il permet de faire tourner du JavaScript en dehors du navigateur, typiquement sur un serveur. Un framework, lui, viendrait se poser au-dessus de Node pour structurer votre application — Express, Fastify ou NestJS, par exemple. La confusion est courante parce qu'on installe tout avec la même commande et le même gestionnaire de paquets.
Est-ce que React est un framework ?
Non, React est une bibliothèque pour construire des interfaces. C'est même l'équipe React qui le répète : elle ne fournit que la couche « vue », et vous laisse assembler le reste. En pratique, quand on parle de « stack React », on parle d'un assemblage — React plus un routeur, plus un outil de build, plus parfois un méta-framework comme Next.js, qui là joue vraiment le rôle de framework.
Quel langage de programmation pour un site web ?
Du HTML et du CSS pour la structure et l'apparence, puis du JavaScript pour l'interactivité. C'est le socle, et il est non négociable : tout framework JavaScript finit par produire du HTML, du CSS et du JS. Un langage côté serveur (PHP, Python, Node.js) intervient seulement si votre site doit stocker des données, gérer des comptes ou générer des pages dynamiques.
Le parcours que je recommande, étape par étape
Dans l'ordre, sans sauter d'étape. Chacune prend du temps, et c'est normal.
- HTML et CSS — structure, mise en page, responsive. Comptez quelques semaines pour être à l'aise.
- JavaScript de base — variables, fonctions, tableaux, objets, manipulation du DOM.
- JavaScript moderne — modules ES6, fonctions fléchées, promesses et
async/await. C'est le vrai prérequis aux frameworks. - Un petit projet en vanilla, de bout en bout. Une todo-list suffit.
- Un framework, un seul, choisi selon votre objectif : emploi → React ; apprentissage doux → Vue.
Sur la question des outils de build — Vite, dans l'immense majorité des cas aujourd'hui — attendez d'en avoir besoin. Un framework moderne s'installe en une commande et vous fournit un serveur de développement fonctionnel. Si vous vous retrouvez à configurer un bundler à la main pour un site de trois pages, quelque chose s'est mal passé.
Et si je n'utilise aucun framework ?
C'est une option parfaitement valable, et même sous-estimée. Pour un site de contenu, un générateur de site statique produit un résultat rapide, sécurisé et quasi gratuit à héberger. J'ai migré un petit site perso de cette façon : temps de chargement divisé par trois, et plus une seule mise à jour de dépendance à gérer. L'inconvénient, c'est qu'il faut accepter de ne pas avoir d'interactivité riche.
Ce que je dirais à la personne qui m'écrit ce message
Si votre premier site est une vitrine, ne prenez rien. Écrivez du HTML, du CSS, un peu de JS, et soyez fier de l'avoir fait à la main. Si vous voulez apprendre un framework parce que c'est ça qui vous intéresse, prenez Vue et acceptez d'y passer un mois avant de produire quoi que ce soit d'utile.
Ce qui me frappe, avec le recul : les gens qui échouent sur leur premier site ne se trompent presque jamais de framework. Ils se trompent d'ordre — ils apprennent l'outil avant le langage, la structure avant les bases. Le choix compte moins que le moment où vous le faites.
Et si vous hésitez encore entre deux options, posez-vous une seule question : laquelle me permettra d'avoir quelque chose en ligne le plus vite ? Celle-là, très souvent, n'est pas celle dont on parle le plus.
