Le moment est venu d’adopter une API de templates DOM

 (justinfagnani.com)
1 points par GN⁺ 2025-06-28 | 1 commentaires | Partager sur WhatsApp
  • La plateforme web s’est imposée comme un runtime d’applications dynamiques, mais le DOM standard ne dispose pas d’une API de templates déclarative capable de gérer ensemble les données, les événements, les propriétés, la protection contre les XSS et les mises à jour efficaces
  • Les frameworks modernes comme React, Vue, Angular, Lit, Svelte et SolidJS placent au cœur de leur fonctionnement un système de templates qui associe balisage et données, avec un impact sur la lisibilité, la sécurité, les performances, l’analyse statique et le rendu côté serveur
  • Par le passé, E4X, E4H et la balise littérale de template intégrée html ont aidé à créer du DOM, mais n’ont pas résolu la mise à jour du DOM ; aujourd’hui, les tagged template literals et l’expérience acquise avec les frameworks fournissent une base pour la standardisation
  • Une API fondée sur JavaScript a un périmètre plus réduit qu’une standardisation de JSX ou qu’un template basé sur HTML, et peut devenir une cible de compilation pour les transformations JSX, avant d’ouvrir la voie à des templates HTML et à des custom elements déclaratifs
  • La trajectoire proposée s’articule avec des mécanismes de bas niveau comme DOM Parts, l’identité des templates, les Signals et un scheduler DOM, et pourrait fournir une base commune aux développeurs vanilla, aux utilisateurs de Web Components et aux implémenteurs de frameworks

Une couche de templates déclarative absente du DOM standard

  • La plateforme web est le runtime d’applications le plus réussi de l’histoire, et l’API DOM est à la base de la transformation d’un simple visualiseur de documents statiques en runtime dynamique et expressif
  • Même des applications complexes comme Photoshop existent sous forme d’applications web, et le DOM est une API suffisamment puissante pour que l’interface entière soit construite en Web Components
  • Toutefois, l’API DOM standard actuelle ne propose aucun moyen pratique de traiter en une seule fois les tâches suivantes
    • générer des fragments de nœuds DOM à partir de données
    • ajouter des écouteurs d’événements
    • définir les propriétés des éléments
    • garantir la sécurité face aux attaques XSS
    • mettre à jour efficacement ces fragments DOM avec de nouvelles données

Les frameworks ont déjà démontré la valeur des templates

  • Les frameworks web modernes et les bibliothèques de rendu utilisent comme fonctionnalité centrale des templates qui associent déclarativement balisage et données
    • Cela inclut React, Vue, Angular, Preact, Lit, Svelte, SolidJS, Stencil, Quik, Ember, FAST, Polymer, Marko, etc.
  • Les templates déclaratifs sont plus agréables à écrire et à lire que l’API DOM impérative
    • les interpolations, les écouteurs d’événements et la définition de propriétés restent proches du template, ce qui facilite le maintien de la localité du comportement
  • Les systèmes de templates peuvent échapper automatiquement les valeurs interpolées, ce qui favorise la protection contre les XSS
  • Un bon système de templates peut ne mettre à jour que le DOM qui change, et s’avérer plus rapide que la plupart des implémentations écrites à la main
  • De nombreux systèmes de templates prennent en charge l’analyse statique comme la vérification de types et l’autocomplétion
  • Les définitions de templates déclaratifs peuvent être interprétées hors de l’environnement complet du navigateur, ce qui permet un rendu côté serveur efficace

Le coût de l’absence de templates

  • La plateforme ne répond toujours pas directement à un besoin central de presque toutes les applications web
    • comme les API d’internationalisation, Temporal, Scheduler ou Sanitizer, les templates méritent d’être traités comme une fonctionnalité standard de la plateforme
  • Les utilisateurs subissent les temps de téléchargement des applications, la surcharge de rendu et les applications peu sûres
    • le code des bibliothèques de templates peut représenter quelques kB au mieux, et plus de 100 kB au pire
    • même quelques kB peuvent peser lourd dans le budget de rendu interactif initial
  • Les développeurs doivent dépendre de bibliothèques, de npm et de CDN même pour des tâches élémentaires
    • l’intérêt des fichiers statiques simples et de DevTools s’en trouve réduit
    • il n’existe pas de savoir de base sur les templates qui soit portable d’une stack à l’autre
    • les API natives de création de DOM comme innerHTML ne sont pas sûres par défaut
  • Les frameworks et bibliothèques de templates doivent faire des compromis difficiles entre ergonomie, vitesse de rendu, vitesse de mise à jour, sécurité et taille du code
  • La plateforme web est en concurrence avec des plateformes natives comme Flutter, SwiftUI et Jetpack Compose
    • ces plateformes intègrent des systèmes proches des templates, utilisent l’installation d’apps et des langages compilés, et sont moins sensibles à quelques kB de bundle en plus

Pourquoi réessayer maintenant

  • Des propositions proches des templates ont déjà existé par le passé
    • E4X a réellement été intégré à Firefox et Flash
    • E4H était une idée simplifiée par Ian Hixie
    • il a aussi existé vers 2012 un prototype de balise littérale de template intégrée html
  • Ces tentatives ont aidé à la création de DOM, mais comme elles ne traitaient pas la mise à jour, elles pouvaient difficilement constituer une solution suffisante
  • Aujourd’hui, les frameworks ont accumulé assez de cas d’usage, et les solutions de templates en espace utilisateur convergent de plus en plus
  • Il existe aussi une demande pour des API pratiques de manipulation du DOM et de réactivité chez les développeurs qui n’utilisent pas de framework ainsi que dans la communauté des Web Components
  • Des propositions de primitives bas niveau pour la mise à jour du DOM, comme DOM Parts, sont en cours
    • une API de templates déclarative de plus haut niveau pourrait réduire la charge d’implémentation pour les frameworks, tout en validant et complétant les propositions d’API bas niveau

Le plus petit dénominateur commun en syntaxe et en sémantique

  • La plupart des systèmes de templates côté client populaires partagent une structure combinant balisage et bindings
    • les délimiteurs d’expression, le contrôle de flux et les marqueurs de type de binding varient un peu, mais les points communs sont plus nombreux
    • on retrouve des similarités entre Vue, Angular et Svelte basés sur HTML, et React, Lit et Solid basés sur JavaScript
  • Dans les API fondées sur JavaScript, un template est généralement une expression, la composition se fait via l’imbrication ou la référence à d’autres expressions de template, et le contrôle de flux est géré par JavaScript
  • Beaucoup de systèmes fondés sur des API JavaScript renvoient une description du DOM depuis l’expression de template, puis l’appliquent via un appel séparé à une fonction render
    • dans la majorité des cas, ce même appel à render sert aussi à mettre à jour le DOM
    • certains évitent cette approche grâce à une réactivité fine
  • E4X et E4H ajoutaient, comme JSX, une nouvelle syntaxe permettant d’insérer du balisage dans JavaScript, mais ils renvoyaient directement des fragments DOM plutôt qu’une description du DOM
    • c’était utile pour la création initiale du DOM, mais la mise à jour restait impérative

Une API exprimable avec le JavaScript d’aujourd’hui

  • JavaScript dispose déjà, pour des DSL embarqués comme HTML, des tagged template literals
  • Il est possible d’exprimer des templates dans l’API DOM sans ajouter de nouvelle syntaxe JavaScript
  • Des bibliothèques populaires montrent que cette approche fonctionne bien
  • Le fait de pouvoir faire avancer la proposition sans nouvelle syntaxe est important pour sa faisabilité en standardisation

La relation entre JSX et une API de templates native

  • Les tagged template literals sont une fonctionnalité puissante d’ES2015, mais dans les systèmes de composants en espace utilisateur, leur surcharge syntaxique est plus importante que celle de JSX
  • JSX est populaire, mais ce n’est qu’une syntaxe, sans sémantique d’exécution
    • pour le standardiser, il ne suffit pas d’ajouter une nouvelle syntaxe : il faut aussi en définir la sémantique
    • l’approche consistant à le traiter comme des appels à createElement() définis dans le contexte est écartée
    • l’approche qui construit des arbres d’objets peut mélanger parties statiques et dynamiques et empêcher des schémas de mise à jour plus efficaces
  • Si la proposition Records and Tuples avait avancé, JSX aurait pu produire des Records boxés, mais cette proposition est au point mort, notamment sur l’identité des records et la question des boxes
  • Pour vérifier si une syntaxe et une sémantique de type JSX conviennent à des templates DOM complets, il faut un système de templates cible
    • les templates de React ne permettent pas de lier explicitement aux propriétés et événements des éléments DOM, ni d’appliquer des directives à des éléments
  • Comme le JSX non standard actuel est une pure syntaxe sans sémantique d’exécution, il est possible de créer un compilateur qui transforme JSX en tagged template literals
    • il existe déjà des exemples comme JSX-to-Lit
    • une API de templates native peut devenir une cible de compilation permettant aux développeurs de choisir la syntaxe qu’ils préfèrent

Pourquoi commencer par une API JavaScript plutôt que par des templates basés sur HTML

  • De nombreux développeurs web souhaitent un système de templates complet fondé sur HTML
    • il existe une demande dans les communautés des utilisateurs de Web Components, des utilisateurs de frameworks et des développeurs vanilla
    • certains attendaient de <template>, du declarative shadow DOM et des Web Components qu’ils fournissent ce type de fonctionnalité
  • Un template basé sur HTML représente un chantier bien plus vaste qu’une API fondée sur JavaScript
    • syntaxe des bindings
    • langage d’expression
    • syntaxe de contrôle de flux
    • mécanisme de mise à jour des templates
  • Il n’existe pas non plus de moyen natif de charger des définitions de templates HTML
    • les HTML Imports de Web Components v0 ont disparu, et les HTML Modules n’existent pas encore
    • s’il faut de toute façon placer les templates HTML dans des modules JavaScript, il semble alors préférable d’utiliser des expressions JavaScript dans le même scope lexical que les données
  • Polymer 3 a déplacé les templates HTML de Polymer 2 vers JavaScript, ce qui a mené directement à Lit
    • confier à JavaScript ce qui relève d’un script produisait moins de code et une meilleure expérience
  • Une API JavaScript peut être à la fois un sous-ensemble et un tremplin vers une API fondée sur HTML
    • une fois l’API JavaScript adoptée et validée, l’API HTML n’aurait plus qu’à définir les bindings, les expressions, le contrôle de flux et le système de modules

Les options de modèle de réactivité

  • Les premières propositions de templates DOM n’incluaient pas la mise à jour, mais les systèmes en espace utilisateur ont largement exploré les modèles de réactivité et les approches d’implémentation
  • On peut regrouper les grandes approches réactives en trois catégories
    • le VDOM et le diffing de React
    • l’identité des templates de Lit
    • les Signals et la réactivité fine utilisés par Solid, Svelte, Vue, Angular et d’autres
  • Le diffing est simple à comprendre et fonctionne avec n’importe quelles données, mais il est plus lent que d’autres approches
    • les différences entre algorithmes de diffing peuvent être observables
    • il serait difficile de standardiser un seul algorithme de diffing et de faire accepter sa surcharge aux ingénieurs de la plateforme
  • L’identité des templates consiste à mettre à jour le DOM s’il a été rendu avec le template courant, sinon à le remplacer
    • c’est rapide et, dans de nombreux cas d’usage, cela produit des résultats très proches du diffing
    • cela s’accorde bien avec les tagged template literals, les transformations JSX et les templates fondés sur HTML
    • la sémantique est simple, donc plus facile à spécifier
  • Les Signals constituent un modèle susceptible d’être inclus dans une nouvelle API DOM réactive et une API de templates
    • il existe une proposition JavaScript Signals, mais elle n’est pas encore une fonctionnalité native de la plateforme et son adoption n’est pas garantie
    • les systèmes fondés sur les Signals fonctionnent au mieux quand toutes les données sont encapsulées dans des signals
    • comme il existe de nombreuses données non encapsulées et des API de plateforme qui ne produisent pas de signals, le rerendering reste un moyen simple de refléter ces changements
  • L’identité des templates et les Signals peuvent coexister
    • un template auquel on ne passe que des signals dans les bindings peut être mis à jour uniquement via les signals, sans rerendering
    • un template qui peut référencer des données non encapsulées a besoin de rerendering
    • en pratique, ce rerendering est généralement pris en charge automatiquement par une couche composant ou framework, par exemple via des propriétés de composants réactifs

Discussion de standardisation et questions restantes

  • La discussion autour d’une API native de templates JavaScript déclarative a commencé dans WICG webcomponents#1069
  • Cette API pourrait constituer la prochaine étape logique des API de création de DOM
    • elle fournirait aux développeurs web vanilla une primitive de création de DOM sûre et agréable à écrire
    • elle serait immédiatement utile à des bibliothèques Web Components existantes comme Lit, FAST et HyperElement
    • elle serait utile aux utilisateurs des API Web Components brutes, et servirait de tremplin vers une API plus complète de définition de composants réactifs
    • de nouveaux frameworks pourraient être construits sur cette base
    • les frameworks existants pourraient l’utiliser comme cible de compilation, backend d’exécution ou cible de support direct
    • elle serait utile aussi bien aux techniques de rerendering qu’aux Signals
    • elle servirait de tremplin vers des templates HTML déclaratifs et des custom elements déclaratifs
    • la surface d’API à mettre d’accord et à spécifier resterait relativement réduite
    • elle aiderait à définir la sémantique des templates
  • Ce travail est lié à l’aboutissement de la proposition DOM Parts
    • il contribuerait aussi à définir DOM Parts et à démontrer son utilité
  • Si l’API de surface et la syntaxe sont limitées, l’espace des comportements et l’API DOM Parts sous-jacente sont vastes
  • Une scheduler DOM sera également nécessaire pour la réactivité fine
  • Il reste de nombreux points à trancher, à faire converger, à spécifier et à tester, ce qui nécessitera de la collaboration
  • Les développeurs intéressés peuvent commenter sur webcomponents#1069 ou contacter l’auteur via Bluesky

À lire aussi

1 commentaires

 
GN⁺ 2025-06-28
Avis de Hacker News

  • Dire « on sait à quoi ressemble une bonne syntaxe de template » me fait franchement rire. À mon avis, on n’en sait encore rien. Un bon template relève presque certainement davantage d’un outil visuel que d’une syntaxe symbolique, et c’est pour cela que des outils comme Dreamweaver ont eu du succès autrefois, et que les designers apprennent avec des outils comme Photoshop
    J’ai aussi l’impression qu’on essaie de recréer XSLT, ce qui est dommage. Quelqu’un finira forcément par vouloir mettre en template des fragments qui ne sont pas well-formed pris séparément, mais qui le deviennent une fois assemblés. Même chose pour des entités reliées entre elles dans une page sans appartenir au même arbre. Un exemple simple, en balisage ordinaire, est label et for
    Si possible, j’aimerais qu’on voie moins de tentatives de faire entrer de force tous les templates dans cette machine de Rube Goldberg qu’est la mise en page documentaire standard du balisage. Les gens empruntent des chemins absurdement compliqués pour reproduire quelque chose qui fonctionne assez bien quand on utilise prudemment le positionnement absolu. Il peut certes falloir des calculs pour l’ajustement, mais je ne vois pas pourquoi on devrait forcer la machine à répéter sans cesse ces calculs pour les mêmes données

    • Je n’ai jamais vraiment aimé XML, mais XSLT était, et reste selon moi, la killer feature qui pouvait sauver cet écosystème. Il est encore largement pris en charge dans les navigateurs
      C’est dommage que XML ait été à la mode dans des domaines inadaptés comme la configuration ou la communication inter-processus, mais se soit essoufflé là où il aurait pu briller comme langage de balisage doté d’une excellente capacité de transformation avec XSLT
      À mon avis, le point où XSLT a échoué, c’est qu’il s’agissait d’un vrai DSL, et même d’un DSL déclaratif, pur et fonctionnel. Les gens encensent les DSL en paroles, mais dans les faits, ils se limitent souvent à de simples jeux de syntaxe qui n’abstraient pas la sémantique procédurale d’un langage hôte populaire. Quand ils rencontrent un DSL bien conçu qui rend triviales des choses difficiles, ils ne veulent pas l’apprendre
    • Je ne sais pas comment tu arrives à cette conclusion. Ce dont tu parles ressemble davantage à une critique générale de HTML+CSS qu’à une façon de générer des templates
      Et je ne comprends pas non plus pourquoi le positionnement absolu entre dans la discussion. Je vois ce genre de propos revenir régulièrement sur HN ; bien sûr, le positionnement absolu a ses usages et il est nécessaire dans de nombreux cas
      Mais utilisé pour la mise en page d’une page ou d’une application, d’après mon expérience, c’était le plus souvent un cauchemar qui s’écroulait au moindre changement de contenu ou de taille d’écran. Même la mise en page d’un journal imprimé ne peut pas fonctionner ainsi, tant la typographie y est imbriquée
      À l’époque où je faisais beaucoup de CSS, quand je reprenais un layout « presque terminé » que quelqu’un avait réalisé avec du positionnement absolu, il fallait un temps fou pour le corriger, et il était toujours plus rapide de le refaire avec flex ou le flux normal. Utiliser le positionnement absolu comme principal outil de mise en page rendait les problèmes pratiquement impossibles à corriger
      Il existe peut-être des techniques sensées avec calc() et les unités de viewport, mais d’après mon expérience, hors contenu totalement statique et taille de viewport fixe, le positionnement absolu n’est pas adapté à la mise en page
    • Sur le web, on exige qu’un document ait une bonne apparence quels que soient la taille, le ratio, l’orientation et les capacités de l’appareil. Les applications classiques, par exemple les applications Windows, n’ont pas cette exigence, et les applications mobiles ont quelques tailles standardisées. Seul le web a les deux
    • Je pense qu’il n’y a que des ressemblances superficielles entre React et Svelte. Tous deux utilisent une syntaxe fortement basée sur HTML, mais leur fonctionnement est très différent
      React est à peu près le seul grand framework qui fonctionne en faisant retourner par des fonctions JavaScript ordinaires une représentation différée de balisage sous forme de JSX. React n’a pas de concept de boucle ou de rendu conditionnel au niveau du template ; c’est géré avec du JavaScript ordinaire
    • Se moquer de quelqu’un qui plaide pour les progrès de la plateforme web n’est pas une très bonne attitude. Ces progrès profitent à tout le monde
      Et je pense qu’aujourd’hui, on sait à quoi ressemble une bonne syntaxe de template. En gros, c’est JSX. Je peux le dire même sans particulièrement aimer React. JSX a déferlé sur tout le web, a été adapté à de nombreux frameworks, et il est difficile de nier que les systèmes de templates JavaScript ont convergé vers des propriétés communes : traiter les templates comme des expressions, les composer par imbrication, et gérer le flux de contrôle avec JavaScript lui-même plutôt qu’avec une syntaxe de template spécifique

  • La leçon de base apprise à répétition, c’est que les API/ABI ne sont pas un état final. Les besoins des applications ne sont pas satisfaits pour toujours par une seule API stable, et on ne peut pas non plus renvoyer tous les problèmes futurs au niveau applicatif
    Cette proposition illustre bien le processus par lequel un problème commun de la plateforme est d’abord résolu dans une couche supérieure comme React, puis redescend finalement quand il est reconnu comme un vrai problème. Les polyfills en sont un autre exemple
    Quand ce genre de proposition réussit, elle attire brièvement l’attention, mais pendant l’essentiel de sa durée de vie utile, elle devient une vieille chose que les gens cherchent à contourner. C’est ce qui est arrivé aux API DOM, aux versions d’ECMA, aux anciens navigateurs, et à toutes les technologies utiles impossibles à toucher parce qu’elles font partie du système
    Ne pourrait-on pas considérer l’entropie, l’extension et la rétrocompatibilité comme des cas d’usage majeurs ?

    • Chaque fonctionnalité des standards du Web est du code supplémentaire à maintenir soigneusement, et aussi du code supplémentaire que quiconque veut créer un navigateur conforme aux standards doit implémenter. J’aimerais que des projets comme https://servo.org/ aient une chance de rattraper leur retard avec le temps, pas qu’ils soient condamnés à poursuivre un périmètre qui ne cesse de s’étendre
      Je veux que la plateforme Web dispose de toutes les capacités possibles des plateformes natives. Bien sûr, en respectant les contraintes de protection de la vie privée et de sandboxing. Et je veux aussi que l’expérience de développement des développeurs Web soit excellente
      Mais cela doit être équilibré avec les conséquences de l’augmentation de la complexité. Dans ce cas, je ne suis pas convaincu que les templates natifs améliorent vraiment l’expérience de développement. Je n’ai pas l’impression que le bénéfice dépasse le coût
    • getElementById est probablement stable depuis environ 25 ans. Dire « il n’existe pas d’API stable » est quelque chose que disent des gens qui n’ont pas la capacité, ou pas la volonté, de créer des interfaces durables. Ce n’est pas une loi de l’univers, plutôt une forme de résignation personnelle. Les contre-exemples sont très nombreux
      Les besoins des applications sont infinis, comme les autres besoins. On les satisfait non pas en cassant les API qui fonctionnent, mais en ajoutant de nouvelles API
    • Sur le Web, les API/ABI sont bel et bien un état final. Une fois exposées sur le Web, quelqu’un dépendra pour toujours de cette forme exacte
      C’est pour cela que certaines API se retrouvent encore prises dans des affaires comme smooshgate à cause de décisions prises il y a 20 ans : https://developer.chrome.com/blog/smooshgate
    • Dans ce processus, les fonctionnalités de base montent encore d’un cran. Le simple fait que les besoins en espace utilisateur trouveront toujours de nouvelles lacunes, de nouveaux cas d’usage et de nouvelles zones d’ombre ne rend pas les mises à jour incrémentales sans valeur
    • C’est justement pour cela qu’on versionne, qu’on maintient la rétrocompatibilité avec les anciennes versions et qu’on ne modifie pas les interfaces « anciennes », non ?

  • Le Web a vraiment besoin de templates natifs, de réactivité et de liaison de données. On n’imagine même pas la quantité de CPU et de bande passante gaspillée par des milliards d’utilisateurs qui téléchargent, parsènt et exécutent des choses comme React

    • Maintenant qu’on a les LLM et les cryptomonnaies, ce gaspillage paraît minuscule
    • La proposition TC39 Signals fait avancer une partie de cela
    • Une liaison de données bidirectionnelle et une sorte de clone de JSX suffiraient en fait à la plupart des gens
    • React peut difficilement être considéré comme un template, non ?

  • La partie sur Signals en dit long, et montre bien que l’idée est excellente mais difficile en pratique
    Je comprends pourquoi l’auteur aime Signals. Tout projet suffisamment gros finit avec un arbre de calcul en DAG à moitié bricolé, et il est logique qu’un langage en standardise un
    Mais ce genre d’abstraction a un coût cognitif et un coût d’implémentation élevés
    Comme souvent en ingénierie, le problème est celui du compromis. Le modèle React met à jour l’état global et rerend tout, donc il est lent, mais facile à comprendre. Le modèle Signals est rapide, mais demande beaucoup trop d’efforts
    La plupart des apps n’ont pas besoin d’être follement rapides, et les gens choisiront React parce qu’il est plus simple
    Mais Signals n’a pas grand-chose à voir avec les templates, non ? Alors pourquoi faudrait-il choisir ? Ne peut-on pas avoir les templates et Signals séparément ?
    Quand on réfléchit aux templates, on finit par avoir besoin d’un moyen d’indiquer où insérer les nœuds de template dans le DOM, et comment les mettre à jour quand ils changent. C’est précisément là que ce type de proposition échoue
    L’API doit ici choisir un camp. Techniquement, elle pourrait permettre les deux, mais ce serait horrible. Les développeurs ne se mettront jamais d’accord sur la bonne approche
    Le grand problème de l’UI a toujours été non pas comment la définir, mais comment la mettre à jour. Microsoft a essayé de définir de nombreux modèles, MVC, MVP, MVVM, etc., a échoué, et tous étaient pénibles. Puis imgui a dit : « et si l’UI n’avait pas d’état du tout ? », et c’est plutôt bien, mais lourd pour le CPU
    Peut-être que l’une des grandes raisons du succès des apps Web est justement que le DOM n’imposait pas de manière de lier les données à la vue. C’est peut-être pour cela qu’il nous est difficile d’échapper à l’enfer des frameworks

    • Il existe maintenant plusieurs frameworks qui savent faire une différence fine sans dépendre de Signals, de proxys ou d’autres primitives réactives. C’est fondamentalement le modèle React descendant, mais beaucoup plus rapide, et sans concepts étranges comme les hooks ou les tableaux de dépendances manuels et gaspilleurs
      Mon préféré personnellement est ivi-js : https://github.com/localvoid/ivi
      Il n’est que 8 % plus lent que le JavaScript vanilla le plus rapide, le plus laid, impératif et impossible à maintenir auquel on puisse parvenir en visant uniquement la victoire dans les benchmarks
      https://krausest.github.io/js-framework-benchmark/2025/table...
    • Microsoft a bien utilisé ces modèles à différentes époques, mais le seul qu’elle ait défini elle-même est MVVM. MVC vient de Xerox PARC, MVP de Taligent
    • Même du point de vue du développeur, je choisirais volontiers l’option plus douce pour le matériel, la bande passante et la planète, même si elle demande un peu plus d’effort à l’esprit du développeur
      Plutôt que de dire que la plupart des apps n’ont pas besoin d’être follement rapides, j’aimerais qu’on reconnaisse davantage qu’une app doit être légère
      Je suis d’accord pour dire que les gens choisissent React parce qu’il est plus simple, mais c’est précisément pour cette raison que je ne l’aime pas

  • Plutôt que d’adopter JSX, j’aimerais quelque chose de plus proche de ce que Kotlin fait en fournissant une syntaxe généralisée pour les DSL via les récepteurs et les builders, une syntaxe qui convient aussi très bien à la représentation de hiérarchies de composants
    Ce serait largement utile non seulement pour les templates HTML, mais aussi pour exprimer de la configuration et divers types de structures
    La sémantique réelle des templates et du data binding pourrait être laissée à un ensemble standard de fonctions utilisant ce type de fonctionnalité syntaxique, comme on le voit avec Jetpack Compose

    • Il n’en faut même pas beaucoup. Des boucles, des conditions sur les attributs et des conditions sur les nœuds suffiraient. En fait, ce niveau-là pourrait même être fourni comme fonctionnalité commune entre langages

  • Il est aussi important de noter que cet article est écrit par l’une des personnes les plus expérimentées dans ce domaine. C’est l’un des principaux auteurs de Lit / Polymer, quelqu’un qui a travaillé sur les Web Components chez Google et contribué à des spécifications DOM clés devenues partie intégrante de la plateforme web

    • Je le vois plutôt comme l’une des personnes qui, en poussant imprudemment des spécifications à moitié mûres, ont créé bien plus de problèmes qu’elles n’en ont résolu. Il a promu une « solution » exigeant plus de 20 nouvelles spécifications web pour à peine reproduire ce que l’espace utilisateur faisait déjà, tout en ignorant ou en faisant du gaslighting envers ceux qui n’étaient pas d’accord à 100 %
      Safari soutenait déjà il y a 15 ans qu’il fallait une approche déclarative ici

  • Je me demande si d’autres ont aussi l’impression que les templates déclaratifs sont en fait pires que jQuery. J’utilise React depuis presque dix ans, mais plus une SPA devient complexe, plus j’ai envie de contrôler directement le DOM de manière impérative
    La raison est que le DOM est une abstraction qui fuit, et qu’à un certain niveau, le modèle où la dernière écriture gagne me semble préférable
    Je sais que les templates déclaratifs essaient de gérer cela, mais dès qu’on commence à partager un état mutable entre composants, cette approche s’effondre très vite

    • Les gens côté React ont tendance à considérer les appels directs à l’API DOM comme un péché capital. Parfois, prendre une ref et, osons le dire, trouver un composant par son id pour le manipuler directement, c’est très bien. En pratique, c’est ce que font des bibliothèques « rapides » avec peu de rerendering, par exemple des bibliothèques de formulaires
    • Je n’aime pas particulièrement React, mais je ne partage pas ce ressenti. D’abord, on peut déjà sortir du DOM déclaratif et faire ce qu’on veut avec innerHTML et les ref
      Ensuite, je ne vois pas vraiment quelles tâches deviennent moins pénibles en contrôlant le DOM de manière impérative plutôt que déclarative. Je pense seulement à quelques méthodes spécifiques comme attachShadow() ou showModal(), et même celles-ci peuvent être enveloppées dans un composant de 10 lignes pour devenir déclaratives
    • Entièrement d’accord. Je n’ai encore jamais vu un exemple qui me convainque que quelque chose comme React est ne serait-ce qu’un peu meilleur qu’un HTML séparé avec jQuery

  • À ma connaissance, Ryan Carniato et Solid JS explorent encore ce qu’il est possible de faire avec les Signals. Je ne pense pas que l’exploration côté utilisateur dans ce domaine soit complètement terminée, et des innovations supplémentaires restent peut-être possibles

    • En dehors de la bulle du développement web aussi, il existe beaucoup de recherches intéressantes sur le domaine du calcul incrémental, et le calcul auto-ajustable — c’est-à-dire même les Signals — n’est pas un axe particulièrement passionnant

  • J’aime bien la direction, mais avant cela, je pense qu’il faudrait d’abord intégrer au navigateur quelques API de plus bas niveau
    Il sera presque impossible que tout le monde se mette d’accord sur un système de templates standard. En revanche, ce que le navigateur peut faire, c’est fournir une API de bas niveau qui applique efficacement et nativement des différences au DOM
    Ce serait vraiment bien d’avoir quelque chose comme ça en natif dans le navigateur
    element.applyDiff(DocumentFragment | string, { method: 'innerHTML' | 'outerHTML' })
    Cette approche permettrait d’appliquer les différences de façon peu intrusive, en préservant le focus des éléments, les valeurs de saisie, l’état des lecteurs audio/vidéo, tout en modifiant les attributs, etc. Des bibliothèques JavaScript comme Idiomorph font ce genre de choses, mais une solution native pourrait être beaucoup plus rapide

    • L’article contient un lien vers la proposition DOM part, qui pourrait devenir une API de bas niveau utile. Elle ne conviendrait probablement pas aux frameworks basés sur un VDOM, mais dans d’autres frameworks, elle pourrait simplifier le fonctionnement et ouvrir davantage de possibilités d’optimisation
      Elle serait aussi utile aux projets sans framework, et le serait encore plus si la proposition Signals était également adoptée

  • La proposition Records and Tuples n’est pas simplement en pause, elle a été retirée. https://github.com/tc39/proposal-record-tuple/issues/394
    Elle a été remplacée par https://github.com/tc39/proposal-composites