Plain Vanilla Web

 (plainvanillaweb.com)
2 points par GN⁺ 2025-05-12 | 1 commentaires | Partager sur WhatsApp
  • Présentation des techniques fondamentales de développement web utilisant uniquement HTML, CSS et JavaScript
  • Introduction aux méthodes permettant de créer des sites et des applications avec les seules technologies web standard, sans outils de build ni framework
  • Aborde les méthodes de structuration et de stylisation à l’aide des Web Components et des fonctionnalités CSS modernes
  • Vise un environnement de développement simple et des bénéfices à long terme, sans la complexité des frameworks ni la charge de maintenance qu’ils impliquent
  • Tutoriel destiné principalement aux développeurs qui maîtrisent déjà les technologies web standard

Aperçu de Plain Vanilla Web

Aperçu des principales techniques pour créer des sites et des applications avec les seules technologies web standard, sans outils de build ni framework

  • Description d’un environnement reposant uniquement sur un éditeur, un navigateur et les standards du web
  • Présentation d’une architecture permettant un déploiement en production sans configuration initiale ni logique côté serveur

Sujets abordés

1. Components

  • Comment utiliser les Web Components pour assembler des éléments de haut niveau avec HTML, JavaScript et CSS uniquement
  • Une manière de remplacer l’approche par composants de frameworks comme React ou Vue

2. Styling

  • Comment exploiter la puissance du CSS moderne pour remplacer les commodités offertes par CSS Modules, PostCSS et SASS
  • Présentation d’une approche plus structurée et modulaire du style, au-delà du CSS classique

3. Sites

  • Comment structurer un projet web sur la base de Web Components et le déployer sans outils de build ni serveur
  • Présentation d’un workflow de déploiement concret et simple

4. Applications

  • Comment créer une application web monopage uniquement avec des techniques vanilla
  • Explication des approches de routage et de gestion d’état

Public recommandé

Destiné aux développeurs qui savent déjà dans une certaine mesure utiliser HTML, CSS et JavaScript

  • Pour les personnes qui débutent dans le développement web, il est recommandé de suivre des parcours d’apprentissage de base comme Odin Project ou MDN

Pourquoi l’approche vanilla

Les frameworks modernes fournissent rapidement une structure et des fonctionnalités puissantes, mais s’accompagnent d’une complexité accrue des outils et des frameworks, ainsi que d’une charge de maintenance continue

  • L’approche Plain Vanilla renonce à une partie de la commodité à court terme en échange d’avantages de long terme : simplicité et maintenance pratiquement nulle
  • Les navigateurs actuels rendent réellement cette approche possible grâce à leur excellent support des standards du web

À lire aussi

1 commentaires

 
GN⁺ 2025-05-12
Avis Hacker News

  • Je ne raisonne plus vraiment en termes de débat « vanilla ou framework », mais plutôt avec la question : « est-ce que ça a vraiment besoin d’être un site web ? »
    Quand on commence à douter qu’une web app — surtout dans le B2B SaaS — soit réellement nécessaire, on découvre qu’on peut faire avancer un business assez loin sans même toucher au navigateur.
    La majeure partie du temps que j’ai passé à créer des sites et des apps était consacrée à des UI/UX d’administration, c’est-à-dire à permettre à un admin de modifier des champs de base de données pour que l’application se comporte comme les clients l’attendent.
    Dans beaucoup de cas, donner simplement à l’entreprise un modèle de configuration (un fichier Excel, par exemple) puis insérer ou fusionner directement le résultat dans des tables SQL est bien plus rapide, plus simple et génère moins de travail inutile.
    Le web n’offre qu’une seule manière de faire de l’UI/UX. L’e-mail ou les fichiers texte brut sont parfois plus flexibles.

    • Je vois souvent des cabinets de conseil digital-first manquer d’agilité en construisant des web apps B2B inutilement sophistiquées.
      Il y a notamment un problème avec les acheteurs — dans le public par exemple — qui ne comprennent pas bien ce qu’ils achètent et paient souvent trop cher.
      Les responsables achats devraient être mieux formés sur ce dont ils ont réellement besoin.
    • Je vends des urnes funéraires en ligne. Mon site n’a qu’un lien e-mail. Pas de panier.
      Un vrai magasin d’urnes n’a pas de panier, alors pourquoi une boutique virtuelle en aurait-elle besoin ?
      Quand j’ai acheté des outils spécialisés de menuiserie en ligne, j’ai simplement rempli un formulaire puis reçu les pièces avec une facture, et ce n’était même pas grave si je ne payais pas tout de suite.
      Il existe toutes sortes de formes de commerce, en ligne comme hors ligne, et si on observe bien les gens qui vivent de façon intéressante, on en trouve partout.
    • Pour des outils internes qui ne vont guère au-delà du CRUD, le web est surtout utile quand un consultant externe doit tout faire d’un coup, ou quand une équipe interne ne pourra pas assurer la maintenance sur la durée.
      Avec un minimum de capacité de maintenance, une combinaison modèle Excel + petit script custom devient beaucoup plus flexible.
      C’est très efficace si les utilisateurs finaux sont de toute façon des gens qui manipulent les données brutes.
    • Dans le B2B, avant le SaaS, tout fonctionnait à 100 % comme ça.
      Et aujourd’hui encore, 99 % du B2B suit ce modèle.

  • Je ne suis pas contre les frameworks. J’ai juste l’impression qu’ils sont souvent inutiles.
    Je me suis toujours demandé pourquoi on devrait ajouter 100 KB de JS avant même d’écrire une seule ligne de code.
    Avec mon équipe, nous avons construit https://restofworld.org sans aucun framework.
    Les retours sur les enquêtes, l’outreach et les e-mails ont tous été très positifs en matière d’utilisabilité et d’expérience de lecture.
    On pourra utiliser un framework plus tard, mais pour l’instant, du simple vanilla JS nous convient parfaitement.

    • Ce commentaire est un bon exemple du décalage qu’on voit toujours dans ce genre de discussion.
      D’un côté, il y a des gens qui construisent de grosses web apps dans des équipes de plus de 30 personnes, et quand on leur dit qu’on fait ça sans framework, ils demandent immédiatement comment on gère toutes les fonctionnalités indispensables à grande échelle.
      Mais la réponse est qu’on n’a tout simplement pas besoin de ces fonctionnalités, parce qu’il s’agit d’un usage de type blog, où un framework n’est pas nécessaire dès le départ.
      À l’inverse, ceux qui n’ont pas d’expérience sur de très grosses web apps se demandent : « pourquoi les gens utilisent-ils des frameworks ? »
      Le web est en réalité un ensemble très varié de logiciels.
      Donc, quand on parle de frameworks, il faut préciser clairement de quel type de logiciel il s’agit.
      Ici, c’est un blog WordPress.
    • La page est excellente et le chargement aussi, mais ça n’a aucun rapport avec l’approche décrite dans le TFA (l’article d’origine).
      Il utilise WordPress, qui est un gros framework, simplement rendu de manière statique.
      Le TFA parle d’une approche sans aucun outil de build, fondée uniquement sur les standards web modernes. Rien que l’éditeur, le navigateur et les standards du web.
    • « Pourquoi ajouter 100 KB de JS avant d’écrire une seule ligne de code ? »
      Dans les apps d’entreprise sur lesquelles j’ai travaillé, personne ne se soucie de 100 KB.
      La plupart étaient de grosses apps conçues par plusieurs équipes, avec React et consorts.
      Dans le Lob/B2B, personne ne se soucie du chargement initial.
      Les utilisateurs s’en servent tous les jours, et les assets statiques sont généralement déjà dans le cache du navigateur.
      Avec un framework intelligent comme Next.js, le contenu est découpé par route en chunks immuables.
      Le rendu initial est en HTML statique, donc du point de vue utilisateur, l’hydratation n’est même pas perceptible.
    • Le site est superbe. J’y ai découvert de très bons articles.
      Mais dans les débats vanilla vs framework, ce type d’exemple est presque toujours un site d’actualités ou d’articles, donc pas une app complexe, ce qui me fait penser : « de toute façon, je n’aurais pas utilisé de framework ici ».
      Au final, il faudrait des exemples réels sur des apps plus interactives.
      Ces temps-ci, je préfère m’en tenir au framework et à des patterns cohérents, tout en minimisant les autres dépendances.
    • Un des avantages de cette architecture, c’est que la navigation arrière/avant du navigateur est extrêmement rapide.
      Sur iPhone, je m’étais habitué au fait que revenir en arrière recharge souvent toute la page.
    • Félicitations ! Pour moi, l’utilisabilité passe avant tout.
      Mais les développeurs s’obsèdent parfois par les écrans de chargement, les composants hydratés, les animations excessives, les modales agaçantes, etc.
    • Je ne sais pas si c’est lié à l’absence de framework, mais lors de la navigation arrière/avant, l’URL change immédiatement alors que la page ne se met pas à jour, ce qui fait qu’on reste sur le même article.
      Et l’infinite scroll est catastrophique pour l’utilisabilité, parce qu’il rend difficile de savoir où l’on se trouve via la position de la barre de défilement.
    • Rest of World fonctionne très vite, même depuis l’Australie, et c’est un fantastique site d’info que je découvre pour la première fois.
      Bravo pour avoir participé à sa construction.
    • C’est l’esthétique d’un site statique généré avec WordPress.
    • La plupart des frameworks n’ont pas besoin de 100 KB de JS.
      Avec Mithril par exemple, on peut avoir toutes les fonctionnalités en 10 KB gzippés.
    • Le problème des exemples vanilla, c’est que les pages sont souvent trop simples et n’offrent qu’une UX minimale.
      Si je pense à construire moi-même une table réactive avec recherche, ou des formulaires avec labels, validation et gestion d’erreurs correctes, pourquoi le ferais-je à la main alors que je peux utiliser une bibliothèque UI Svelte et 25 KB d’overhead pour obtenir un produit bien conçu et éprouvé ?
    • L’image principale fait plus de 200 KB, donc débattre de 100 KB n’a pas beaucoup de sens.
      Et WordPress est aussi un framework.
      Utiliser un framework ne rend pas forcément un site lent, que ce soit WordPress ou autre.
    • C’est un bon exemple du gonflement du web moderne.
      C’est beaucoup trop rapide.
    • Vraiment rapide !
    • J’aime énormément Rest of World.
    • « Pourquoi ajouter 100 KB de JS ? »
      Pour la productivité des développeurs, en théorie.
      En pratique, ça n’aide souvent pas tant que ça.
    • Le site est vraiment très rapide. J’ai déjà vu ce genre de journalisme auparavant.
      Je me demande s’il y a eu des inconvénients marquants avec cette approche.
    • Quoi ? Ce n’est pas possible.
    • Personne ne se soucie de 100 KB.

  • Je développe un système pour environ 2 000 utilisateurs, et ils se moquent complètement d’une UI réactive.
    Le mieux est de faire un monolithe, de ne pas se préoccuper des rechargements de page, et de se concentrer simplement sur le travail à accomplir.

    • En contrepoint, beaucoup d’anciennes applications desktop ont fini par migrer vers le web.
      La motivation n’était pas tant technique que liée au coût trop élevé de la distribution d’apps natives.
      Le web fournit à bas coût un standard de distribution applicative, mais ses technologies UI restent médiocres.
      Il y a déjà eu plusieurs tentatives bancales, comme X11, Java ou Flash, et j’espère qu’un jour on aura une façon plus confortable de développer des web apps.
    • Rien qu’avec le CSS @view-transition, on peut déjà faire des transitions fluides.
      https://developer.mozilla.org/en-US/docs/Web/CSS/@view-transition
    • C’est un avis beaucoup trop blasé pour notre époque.
      La plupart des logiciels sont bien plus lents et moins réactifs que des dispositifs mécaniques vieux de 120 ans.
    • Rien qu’avec CSS et JS, on peut très facilement créer des dynamiques de rafraîchissement ultra simples.
      Pas besoin d’aller chercher des packages npm.
    • La séparation entre React et le serveur est également bancale.
      Le backend est en express/node, tout le code est mélangé, mais en dev le serveur tourne avec le serveur React par défaut, puis en production tout fonctionne différemment ; au final, on se retrouve avec des builds et des opérations de déploiement bizarres qui annulent l’intérêt du confort du serveur de dev (hot reload, etc.).
    • J’ai souvent vu des SPA plus cassées que des MPA.
      Même des SPA de très grandes entreprises comme Reddit ou X (Twitter) étaient trop instables sur mobile.
      À moins d’être au niveau de Twitter, ou d’avoir une plateforme fondée sur des API, je ne vois pas l’intérêt de s’obstiner à faire une SPA.
      Même des entreprises valant des dizaines de milliards n’y arrivent pas correctement ; il ne faut pas se surestimer en pensant qu’on fera mieux.
    • L’avantage de l’approche vanilla, c’est qu’elle permet aussi d’étendre un site SSR existant.
      Pas besoin de tout réécrire en React.
      Les fonctionnalités avancées de type SPA mentionnées par l’auteur d’origine sont optionnelles.
    • Les utilisateurs pragmatiques ne s’en soucient pas, mais ceux qui cliquent un peu dans tous les sens vont appuyer sur le bouton retour au lieu d’attendre de revenir au flux principal, et ce timing peut être plus rapide que le temps nécessaire pour récupérer le framework à jour depuis le CDN.
    • À condition que le rechargement de page soit vraiment rapide, je suis d’accord avec cette opinion.
    • J’aimerais bien savoir comment vous pouvez être sûr que les utilisateurs ne se soucient vraiment pas du rafraîchissement de page.
      Avez-vous aussi étudié ceux qui sont partis ?

  • J’aimerais vivre dans un monde comme ça.
    Je viens d’une époque antérieure aux frameworks, qui était encore immature, et où il était courant de croiser des gens ne connaissant que jQuery.
    Aujourd’hui, j’ai l’impression que les frameworks post-query selector n’offrent plus un rapport coût/bénéfice très convaincant (à l’exception des frameworks de test, que je trouve excellents).
    Nous sommes enfermés dans une prison de frameworks React, et tous les échecs sont le résultat d’une complexité devenue spaghetti.
    Les state machines finissent codées en dur dans le désordre, et les artefacts traduits, minifiés et transpiliés sont illisibles.
    Les source maps ajoutent encore une couche de complexité pour la maintenance.
    Je reconnais pourquoi les frameworks ont été créés, mais j’ai du mal à imaginer qu’il soit plus simple pour un nouvel ingénieur d’apprendre un framework en continu plutôt que du vanilla JS.

    • J’ai connu cette vieille époque moi aussi, et le plus gros problème, c’est qu’on a décidé de construire un écosystème d’applications sur un format de document.
      HTML n’était au départ qu’un balisage destiné à faciliter le rendu du texte, et HTTP était dans le même esprit.
      Autrefois, le ratio texte/balisage devait être élevé, mais aujourd’hui il s’est complètement inversé.
      Et pourtant, on a cru que l’avenir consistait à empiler tout le développement applicatif là-dessus ; même l’intérieur de React n’est qu’une accumulation de combines et d’astuces sur plusieurs décennies.
      À l’époque, faire des applications avec Excel+VB ou avec PDF+PostScript relevait déjà de tentatives absurdes.
      À force de fonctionner ainsi, plusieurs mégaoctets de JS paraissent franchement excessifs.
    • Pour moi, la killer app aujourd’hui, c’est la réactivité.
      Le fait que l’UI réagisse immédiatement aux changements de données : quand il faut gérer ça à la main avec des listeners, des mises à jour différentielles et la désinscription des événements, on a presque l’impression de faire de la gestion mémoire manuelle.
      C’était déjà le cas à l’époque de jQuery, et on y faisait beaucoup d’erreurs.
      Le jour où il sera possible, en vanilla JS, de modulariser la vue de façon déclarative sur une base de composants, j’y reviendrai ; mais pour l’instant, je n’y crois pas du tout.
      Il manque un élément décisif.
    • Moi aussi, je me demande parfois si ce n’est pas juste de la nostalgie imprégnée de principe KISS.
      React et Angular avaient clairement du sens avant ES2015.
      Depuis, je suis lassé des changements permanents dans les frameworks front-end.
      Même dans React, la façon de faire des components et de gérer l’état n’arrête pas de changer.
    • Si l’on sert des centaines de millions de vues, j’imagine qu’en pratique on sera beaucoup plus proche d’un site statique que d’autre chose.

  • Je ne suis toujours pas convaincu par les Web Components.
    Même avec les fonctionnalités récentes comme @scoped ou import {type:css}, je trouve bien plus pertinent de rendre des éléments statiquement puis de les mettre à jour dynamiquement avec du JS moderne.
    Je reste sceptique face à la plupart des approches Web Components, et je pense qu’il faut continuer à innover en dehors des frameworks comme React ou Svelte.
    Je n’ai jamais eu l’impression que les Web Components étaient utiles pour les différents sites que j’exploite.

    • Les Web Components ne résolvent pas mes problèmes ; ils m’en ajoutent de nouveaux.
      On voit des dizaines de discussions par page à propos du Shadow DOM, alors qu’il s’agit souvent de problèmes créés précisément par son adoption.
      Pour mes composants propres à l’application, je n’ai pas ces problèmes de Shadow DOM.
    • « Rendu statique des éléments + mise à jour dynamique avec du JS moderne »
      Je me demande comment les Web Components gèrent ça côté backend.
    • Les Web Components fournissent une frontière d’abstraction claire.
      On peut ajouter des méthodes à ses propres tags et encapsuler la logique de mise à jour à l’intérieur du composant.
    • Je pense qu’il faut revenir à l’Unobtrusive JS.
      Il nous faut des pratiques faciles à écrire soi-même ou reposant sur des bibliothèques légères.
      HTMX a de bonnes idées par endroits, mais continue à fonctionner comme une balise script ; il suffirait que les URL et méthodes restent clairement dans le HTML, et que des choses comme hx-target soient définies côté JS via des attributs data-.
      Je ne veux pas embarquer toutes les fonctionnalités HTMX que je n’utilise pas.

  • Je ne pense pas que les Web Components soient un substitut à ce que les autres frameworks appellent des composants.
    On ne peut pas passer de valeurs complexes (Object, Array, etc.) dans les attributs, il y a beaucoup trop de boilerplate, et il n’y a pas de réactivité.
    J’écris mon code de style vanilla JS avec une approche signals[1].
    Tous les standards du W3C ne sont pas nécessairement la bonne réponse, et il faut se souvenir de l’échec de XHTML.
    [1] https://wrnrlr.github.io/prelude/

  • http://youmightnotneedjs.com

  • Cette approche semble bien convenir à ceux qui font des pages web comme hobby.
    Les frameworks servent à standardiser, à intégrer les bonnes pratiques dans la conception, et à permettre un démarrage de développement rapide.
    Un site web n’a pas de valeur intrinsèque ; ce qui compte, c’est la façon dont son contenu est exposé efficacement, et dont il est développé correctement dans les délais.
    De ce point de vue, les frameworks réduisent les coûts présents et futurs.

    • C’est le « récit officiel », mais ce n’est pas toujours vrai dans la pratique.
      Dans les grandes entreprises, les décisions sont souvent guidées par les modes, les habitudes et un réflexe défensif envers les frameworks populaires ; la baisse de productivité liée à la complexité accrue n’est pas suivie, et au contraire, les mauvaises décisions peuvent très bien s’aligner avec les incitations individuelles ou d’équipe.
      Autrement dit, on ne peut pas justifier le choix d’un framework avec l’argument selon lequel ce serait forcément une décision rationnelle.
    • J’ai aussi vu beaucoup de projets construits avec React et ses frameworks associés qui étaient loin d’être parfaitement maîtrisés.
      Le simple fait d’utiliser un framework ne garantit pas automatiquement le respect des bonnes pratiques ; cela peut au contraire conduire à des systèmes encore plus gonflés et plus lents.

  • Excellente ressource.
    Si l’on fait du web, je pense qu’il faut absolument comprendre les principes des technologies de base et savoir exploiter pleinement la plateforme web.
    Ensuite, utiliser ou non un système de build ou un framework doit rester un choix libre, tant qu’on comprend les compromis.
    Personnellement, j’aime Remix (/React-router v7+) parce qu’il est aligné avec une philosophie des standards du web.
    Autrement dit, il permet de faire plus avec moins de développement (par exemple modifier des données côté serveur via de simples formulaires HTML).
    Je recommande aussi https://every-layout.dev, qui permet d’apprendre toute une série de techniques de layout performantes, accessibles et flexibles en CSS natif du navigateur.
    Je travaille dans le développement web professionnel depuis 1998.

  • La semaine dernière, j’ai réalisé un petit projet entièrement en vanilla, et ça fonctionne très bien.
    C’est un outil web pour écrire de longs threads Mastodon.
    Pendant tout le développement, je me suis demandé : « est-ce que je fais quelque chose de travers en n’utilisant pas de framework ? »
    On a l’impression que tout le monde s’attend désormais à voir un framework.
    Splinter, splinter.almonit.club, pour ceux que ça intéresse.