Patterns.dev

 (patterns.dev)
2 points par GN⁺ 2025-12-12 | 1 commentaires | Partager sur WhatsApp
  • Patterns de conception pour la conception d'applications web et l'optimisation des performances : ressource en ligne gratuite centrée sur des contenus d'apprentissage autour de JavaScript et des frameworks modernes
  • Vanilla JavaScript, React, Vue : patterns de conception dédiés à chaque approche, avec une présentation structurée du rendu, du chargement et des techniques d'amélioration des performances
  • Réutilisation de code, gestion d'état, stratégies de rendu, optimisation des bundles avec des exemples orientés pratique métier, et prise en charge d'exercices via CodeSandbox
  • Les patterns de conception sont des outils de référence plutôt que des règles strictes : ils sont présentés pour aider à comprendre les points communs des solutions à des problèmes récurrents
  • Implémentations incluant la syntaxe ES2017+ la plus récente et React Hooks, avec un focus sur l'évolutivité structurelle et l'amélioration des performances des applications web à grande échelle

Vue d'ensemble

  • Patterns.dev est une ressource en ligne gratuite pour améliorer l'architecture des applications web, structurée autour des patterns de design, de rendu et de performance
  • Des exemples d'implémentation dans des environnements Vanilla JavaScript, React, Vue.js sont fournis, en expliquant l'objectif de chaque pattern et sa manière de l'utiliser
  • Propose un téléchargement eBook ou PDF ainsi qu'une consultation en ligne

Patterns JavaScript

  • Propose une collection de patterns centrés sur JavaScript et Node.js de base
    • Inclut des patterns de conception traditionnels comme Singleton, Proxy, Prototype, Observer, Module, Mixin, Mediator, Flyweight, Factory
  • Recense de nombreux patterns d'optimisation de performance et de chargement
    • Dynamic Import, Route-based Splitting, Tree Shaking, Prefetch, Preload, PRPL, optimisation des tiers et bien d'autres
  • Utilise des fonctionnalités navigateur récentes comme l'API View Transitions pour les animations de transition de page, la virtualisation de listes et la compression de code

Patterns React

  • Propose des patterns structurels et des stratégies de rendu basés sur React et Next.js
    • Container/Presentational, HOC, Render Props, Hooks, Compound, entre autres
  • Comparaison des approches de rendu
    • Client-side, Server-side, Static, Incremental Static Generation, Progressive Hydration, Streaming SSR
  • Fournit des guides sur React Server Components et l'optimisation des Core Web Vitals de Next.js
  • Le document React Stack Patterns (2025/2026) couvre les stacks techniques récentes : framework, outils de build, routing, gestion d'état, intégration IA et plus encore

Patterns Vue

  • Des patterns dédiés à Vue.js centrés sur la structure des composants et la gestion d'état
    • Components, Async Components, Composables, Container/Presentational, Data Provider, Dynamic Components
  • Propose une structure de code moderne via Composition API et <script setup>
  • Inclut des patterns avancés comme Provide/Inject, Renderless Components, Render Functions

Philosophie d'application des patterns

  • Patterns.dev présente les patterns comme des outils de référence, pas comme des normes
    • Ils proposent des solutions communes pour résoudre des problèmes qui se répètent, sans imposer une approche unique à tous les contextes
  • L'objectif des patterns de conception est de rendre compréhensibles les similarités des problèmes de code de façon humaine
  • La plateforme insiste sur l'importance des patterns propres à un langage ou à un framework, en proposant une approche moderne au-delà des patterns GoF

Support d'apprentissage et de pratique

  • Grâce aux exemples de pratique CodeSandbox, il est possible de vérifier l'implémentation réelle de chaque pattern
  • Une pédagogie visuelle basée sur des animations aide à mieux comprendre les concepts
  • Les patterns de performance web y présentent des méthodes pour améliorer l'efficacité du chargement du code et l'expérience utilisateur

Points clés à retenir

  • Implémentations optimisées pour les environnements JavaScript modernes grâce à la syntaxe ES2017+
  • Accent mis sur l'optimisation pour les développeurs React et l'amélioration des performances web
  • Interprétation moderne des patterns de conception mettant l'accent sur le pragmatisme plutôt que sur la complexité
  • Fournit des guides applicables en production pour l'évolutivité et la performance des grandes applications web

À lire aussi

1 commentaires

 
GN⁺ 2025-12-12
Avis sur Hacker News

  • Quand je développais des applications d’entreprise .NET dans mon ancien poste, les design patterns étaient vraiment utiles
    Comme plusieurs équipes utilisaient les mêmes patterns, le code était familier et les nouveaux projets avaient aussi une structure cohérente
    Mais aujourd’hui je travaille sur une application JS vieille de plus de 10 ans, et l’abus de getter/setter à la Java EE ainsi que des structures de factory complexes sont au contraire nuisibles
    Quand on abuse des patterns sans comprendre pourquoi on les utilise, on obtient un résultat bien pire qu’un code simplement lisible (ça rappelle le principe YAGNI)

    • Je pense que les patterns ne se « créent » pas, ils se « découvrent »
      En tant que développeur, on finit naturellement par imaginer des structures comme Adapter, Builder, Iterator
      La vraie valeur des design patterns, c’est de donner un langage commun à ces patterns découverts pour permettre de communiquer facilement entre nous
    • Beaucoup de patterns n’ont vraiment de sens que dans des langages très contraints comme C# ou Java
      Dans des langages simples comme C, Go ou JavaScript, on peut résoudre les choses beaucoup plus simplement
    • Je vois souvent des développeurs issus d’environnements d’entreprise essayer d’imposer de force les mêmes patterns OOP en JS
      Ça ne correspond pas à la philosophie du langage
    • Moi aussi, avec de bonnes intentions, j’ai déjà appliqué des patterns pour finalement créer un cauchemar de maintenance
      Au début ça paraît propre, mais avec le temps la logique se disperse, et dès qu’une nouvelle exigence arrive le pattern se casse facilement
      On finit par regretter un simple switch
    • Parmi ceux qui disent que les patterns ne servent à rien, beaucoup n’ont jamais connu de systèmes à grande échelle
      C’est un peu la différence de point de vue entre quelqu’un qui ne construit que de petites applications et quelqu’un qui bâtit un gratte-ciel

  • Il existait autrefois la Yahoo Design Pattern Library
    C’était centré sur les patterns UX, avec une bonne collection d’exemples montrant comment guider le comportement des utilisateurs (par ex. attribuer une note)
    Lien d’origine / archive web

    • Il existe un projet open source similaire, The Component Gallery
      C’est un dépôt qui regroupe des composants UI issus de plus de 90 design systems, très utile aussi pour apprendre les recommandations a11y/ARIA
      component.gallery
    • Des termes comme « accordion » ou « carousel » se sont standardisés grâce à cette bibliothèque
      Ce langage commun a amélioré la productivité
    • Ça dégage une vraie ambiance du vieux web, avec une certaine nostalgie
    • YUI aussi était en avance sur son temps
    • L’ingénierie chez Yahoo était vraiment excellente, et c’est dommage que tout se soit écroulé à cause de l’échec du management

  • C’est une bonne collection de ressources, je l’ai ajoutée à mes favoris
    Je partage aussi des sites similaires

  • Plus l’expérience s’accumule, moins on dépend des design patterns
    Les juniors pensent souvent qu’apprendre des patterns est un raccourci pour progresser, mais cela augmente souvent la complexité
    Ce qui compte vraiment, c’est de comprendre la nature du problème et la structure des données
    Par exemple, pour trouver les éléments communs entre deux tableaux, un simple schéma utilisant une HashMap pour descendre à O(n) est bien plus utile
    Ça n’a pas forcément de nom, mais dans la pratique c’est un pattern essentiel utilisé tous les jours
    Au final, ce qui compte, ce sont les principes et le contexte, pas la forme scolaire

    • Les patterns ont de la valeur comme langage commun
      Si on dit « j’ai créé un singleton », tout le monde comprend immédiatement
      Mais idolâtrer l’outil, c’est là le problème
    • L’utilisation de la HashMap évoquée plus haut s’appelle un hash join dans le monde des bases de données
      On le voit aussi dans le query planner de Postgres
    • Il n’y a rien de honteux à employer des termes comme « factory »
      En revanche, quand on nomme du code, mieux vaut rester descriptif
    • L’optimisation via HashMap peut aussi être vue comme une forme de programmation dynamique
      C’est utile à connaître pour s’entraîner sur Leetcode
    • Plus que les design patterns eux-mêmes, c’est le pattern d’application des patterns qui compte
      Pour un livre qui traite non seulement des patterns techniques mais aussi des patterns organisationnels, je recommande
      Organisational Patterns (James Coplien, Neil Harrison)
      lien vers un résumé

  • À l’université, j’ai eu la chance de suivre par hasard un cours sur les patterns directement enseigné par Ralph Johnson,
    et ça a été l’un des cours les plus utiles de ma vie
    Wiki de Ralph Johnson

  • Il existe cette phrase : « Design Patterns are a sign of missing language features »
    Autrement dit, si le langage avait été suffisamment expressif, on n’aurait peut-être pas eu besoin de ces patterns
    Ressources liées : C2 Wiki, article de Norvig, article Medium

  • Ce site est une collection de tutoriels bien organisée, mais c’est dommage qu’il ne montre pas, comme A Pattern Language de Christopher Alexander,
    la structure de connexions hiérarchiques entre les patterns
    À l’origine, un pattern prend son sens dans une relation entre niveaux supérieur et inférieur, mais ce contexte disparaît souvent dans les livres techniques
    Ce serait encore mieux si chaque pattern indiquait plus clairement quel problème il résout

    • Quand on regarde les exemples de A Pattern Language, chaque pattern est organiquement lié aux autres patterns
      Par exemple, « Short Passages » est relié à « Flow Through Rooms », « Building Thoroughfare », etc.
      C’est cette structure qui fait la vraie force d’un langage de patterns

  • Quand on abuse des patterns, on obtient un code lent et difficile à maintenir

    • Les patterns sont les plus efficaces lorsqu’ils sont découverts naturellement au cours de la résolution d’un problème
      Vouloir résoudre à l’avance un problème qui n’existe pas encore ne fait qu’ajouter de la complexité
    • Au final, ils ne brillent que lorsqu’ils sont utilisés à bon escient

  • Du point de vue de POSD (Principles of Software Design), les patterns utiles sont les suivants

    • Module Pattern
    • Factory Pattern (factory functions)
    • Mediator/Middleware Pattern (sous forme de pipeline de fonctions)
    • Hooks Pattern
    • Container/Presentational Pattern
      En revanche, Singleton, Mixin, Observer, etc. demandent de la prudence, car ils peuvent entraîner une hausse de la complexité ou une dépendance à l’état global
    • Un commentaire demandait ce que signifiait POSD

  • Ce site privilégie plus la largeur que la profondeur, ce qui lui donne un côté 2017
    Ce qui compte vraiment, c’est d’acquérir de bonnes bases pour manipuler les immutable data
    S’exercer à écrire du code uniquement avec des méthodes de tableau, sans boucle for, aide énormément

    • J’ai déjà utilisé ClojureScript, et c’était très bien pour travailler avec des données immuables
      En JS, Object.freeze a ses limites, et une approche qui retourne de nouveaux objets comme ramdajs est plus réaliste
      Grâce à la syntaxe moderne de JS, seules certaines fonctions de ramdajs restent vraiment utiles
    • En lisant ce post, j’ai eu envie de commencer à documenter mes propres patterns